On Thu, Jul 04, 2002 at 04:13:10PM -0400, Charles Wilson wrote: >The two best candidates right now are probably the cross-tool at >lilypond, or cgf's mknetrel. Unfortunately, BOTH will require work -- >lilypond's needs to "play better" on native platforms (as does mknetrel, >but mknetrel is closer).
The last I heard, mknetrel worked fine natively. I removed all of the linux dependencies that I heard of. There should be no special dependencies for things like "readlink" or "getopt" anymore. >BOTH need to be heavily documented. True, mknetrel certainly isn't documented. >Mknetrel combines stuff at "runtime"; there is no "build script" per se. > However, the 'stuff' -- shell script fragments and default-overrides >for each individual package -- are all buried within the mknetrel >hierarchy, NOT separated out into your build area. So, cvs co mknetrel >will give you a whole bunch of shell fragments in the extra/ >subdirectory -- one for each of the packages that cgf maintains. Well, >we probably don't want a "central repository" of shell fragments -- >those fragments should be federated in the -src tarballs for the >individual packages. There's probably some way to make that work -- but >(a) mknetrel works for what cgf wants (b) he has explicitly said it is >UNsupported for general use. I have been accepting suggestions and incorporating patches in mknetrel. There's no reason why the stuff in "extra" couldn't also reside in the source directory although there is sometimes a chicken-egg problem when the functions in extra change things like the package name which is used to find the source directory. But those cases are the exception. I'm pretty happy with the mknetrel functionality. It allows me to build most packages without actually modifying anything. If people want to try it, I'll entertain modifications, i.e., I'll consider it supported. cgf