[M3devel] Release engineering
Jay
jay.krell at cornell.edu
Sat May 9 21:08:27 CEST 2009
> From: wagner
> I've been thinking today about using the .M3SHIP files for
> installation purposes. Curently, the paths they contain are all
> resolved like this:
>
> install_file(".M3EXPORTS", "/usr/local/cm3/pkg/test/FreeBSD4", "0644")
>
> If we use the variables defined in the cm3 config file, we can
> defer path resolution to installation time:
>
> install_file(".M3EXPORTS", PKG_INSTALL & "/test/FreeBSD4", "0644")
I think:
This is an ok idea.
Like if you want merge cminstall functionality into cm3.
I think the SRC releases pretty much worked this way, with the advantage
that cm3 was implemented in C and could be built at install time.
Heck, cm3 -ship could try to do diskspace checking. :)
But I don't think this solves a problem anyone has yet brought up.
The two solutions are, to the problem I think brought up:
- link at ship time -- which you'd combine with this idea
- use $ORIGIN
I think most systems support that now.
One exception is NetBSD 4.0. 5.0 supports it.
MacOSX has something different. They added stuff in 10.5 and I think 10.4,
and I think the 10.4 feature suffices.
I'd still like to switch to hard links here so that $ORIGIN
use is just $ORIGIN/../lib for all shared objects and executables,
and "hidden" executables will ship to (hard link to) lib.
$ORIGIN/../lib seemed to already work on Linux but that was surprising
and it didn't work on other systems (I think Solaris?)
Ok, hm, I tell you what this can help though.
It can help bootstrapping.
It can help "large" distributing bootstrap archives.
The advantage of distributing bootstrap archives is that
"FreeBSD" can resolve at install time to 4.x, 5.x, 6.x, 7.x, whatever.
There'd still be, like, my Makefile for building cm3 on the target.
But then cm3 can ship everything else into place.
This, like, saves me from writing Python to convert the .m3ship files
into a makefile or sh or such. Also not difficult.
Normally I just bootstrap cm3 and then build everything else on the target.
However for distribution purposes, for building something that is a
hybrid between "precompiled binary package for install speed" and
"source that is more portable to various systems"..this is not a bad idea.
There's still the sticking point as to when cm3cg is built and/or if
the user has to wait for it to be built. You'd end up being able
to run all the Modula-3 stuff, but can't build anything until you
first build cm3cg. Maybe not a terrible idea. It doesn't take TOO long
except on cygwin or old machines. Maybe we can use the system's gmp/mpfr
if they exist, that saves a lot.
This makes me wonder also if "distribution builders" should
do cross builds targeting older releases, like FreeBSD 5.x, Linux whatever, etc.
It's a bit of a pain though. And only viable where cc/ld are open source,
and even then probably only where they are both GNU (even if Apple and Sun
are also open source).
- Jay
More information about the M3devel
mailing list