On Thu, Apr 15, 2010 at 03:55:07PM -0400, Alexander Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 4/15/10 3:44 PM, Jack Howarth wrote:
> > On Thu, Apr 15, 2010 at 01:26:03PM -0400, Alexander Hansen wrote:
> > On 4/15/10 11:58 AM, Jack Howarth wrote:
> >>>> I was pondering if the following might be
> >>>> possible under fink. Since there will be a lot
> >>>> of interesting improvements with dragon-egg
> >>>> and llvm in trunk svn, it would be neat to
> >>>> create a set of llvm-svn/llvm-gcc42-svn/
> >>>> dragon-egg-svn packages that would automatically
> >>>> download whatever the current svn was
> >>>> and build a package with the revision. This
> >>>> seems easy enough when svn is present on the
> >>>> machine. The tricky bit would be to tether
> >>>> the packages together by the same svn revision.
> >>>> In other words, I would like to have the llvm
> >>>> package build whatever the current svn revision
> >>>> is when invoked, but the llvm-gcc-42 and
> >>>> dragon-egg packages latch onto the same svn
> >>>> revision. In theory this shouldn't be impossible
> >>>> since llvm must be installed for llvm-gcc42
> >>>> or dragon-egg to build. So all I need is a
> >>>> dynamic version or revision number in those
> >>>> packages that is set to the same value as
> >>>> that of the installed llvm (which is being used
> >>>> for the build). Any comments?
> >>>> Jack
> >>>>
> >
> > Installing fink from a CVS checkouts does something similar--it
> > generates a .info file, which is revision tagged to the time in which
> > the installation is started, and a source tarball which only carries the
> > current version assigned to CVS checkouts (0.29.99.cvs currently).
> >
> > I could see creating a wrapper package with a script that a user would
> > run to do the svn updates, stash tarballs in %p/src to allow rebuilds if
> > needed, and generate package description files with dynamic versioning
> > or revisioning.
> >
> > If we were to decide to give fink the ability to do checkouts from
> > repositories, from a support standpoint a scheme that uses the current
> > pull svn will be harder to debug than a scheme which checks out a
> > defined revision number. In the latter case, a developer can just try
> > to build/install a package as usual to confirm a problem, and I don't
> > see that as particularly easy if packages build against current svn.
> >
> >> Alexander,
> >> It would be extremely useful to have the same feature as MacPorts
> >> to allow a build to download the svn at a particular revision dynamically
> >> during the build. I resorted to that for the pymol MacPorts package using
> >> the syntax...
> >
> >> fetch.type svn
> >> svn.url
> >> https://pymol.svn.sourceforge.net/svnroot/pymol/trunk/pymol
> >> svn.revision 3866
> >
> >> This was essential for pymol since they don't distribute tarballs of the
> >> releases.
> >> Jack
> >
> >
> >
>
> That's along the lines of what I was thinking, then--if the svn revision
> were hardcoded into the .info file to guarantee that everybody's
> building against the same revision, then we're replacing the operations:
>
> maintainer pulls from e.g. svn at some revision
> maintainer generates a snapshot tarball from the svn pull
> maintainer puts tarball online
> maintainer updates package description
> at build time, fink downloads the snapshot tarball
> ...
>
> with:
>
> maintainer updates package description
> at build time, fink does the svn pull at the svn revision dictated in
> the .info file
> ...
>
> That seems like a reasonable extension of fink's operations to me.
Alexander,
This would be the typical use. What I was considering was a
bleeding edge package for folks who wanted to track close to
the svn for particular projects like llvm and dragon-egg but be
automated. Currently MacPorts does this by constantly updating
their upcoming gcc4x package (gcc46 now) to the latest snapshot.
I was thinking of doing this in a completely automated fashion
were the current svn revision at any particular moment could be
used (and likely no one would end up with the same exact package).
Again it is just a convenience for working with the svn but through
fink packages.
Jack
> - --
> Alexander Hansen
> Fink User Liaison
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvHbxsACgkQB8UpO3rKjQ/yLgCfRSQ7hLHN5Cj2UlXnncvxm65r
> k0EAn2STtJMG851MFdqMygU+Oz7LL+iA
> =lfRr
> -----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
