Hi Phil, The short answer is that I already deal with enough "smart" compilation tools and I'm afraid that I will be finding corner case after corner case in this one. The mechanism needs to be as dumb as possible.
There is a commercial software package for seismic data acquisition and processing that I support at my site, called Antelope [1]. This package lives in it's own little tree under /opt/antelope, largely independent of system software. The major exception to the self-contained nature of Antelope is the contributed code library[2], which has dependencies on a lot of open source projects - things like ImageMagick, RRDTool, Python, etc. My site makes heavy use of "antelope_contrib" because almost all of my users are Power Users and many are authors of items in antelope_contrib. Maintaining the products generated by compiling the antelope_contrib tree unfortunately is where most of my time seems to go because of the third-party and open source dependencies. There are a number of eccentricities with the build process for the antelope_contrib code, and the end result is that I have to battle with several "smart" tools that set and tweak various environment variables. I had a bit of a masochistic laugh when I read your response [3] to me on maintainers that used a command called "compile" to perform the auto-switch - that is EXACTLY the name of the goofy macro/wrapper that this commercial package uses to abstract between SPRO and GCC on Solaris. I think the AntelopeMake Makefile actually sets "CC" to "compile" during the build phase. I'd really prefer to set and forget using the alternatives mechanism, rather than have a tool try to guess my intentions through three or more layers of abstraction. Using something like the alternatives mechanism, I can force my build process to look at the "right" auto-configure tool for a package like Python or Ruby or RRDtool. [1] http://brtt.com [2] http://github.com/antelopeusersgroup/antelope_contrib [3] http://lists.opencsw.org/pipermail/maintainers/2011-March/014365.html On Mar 21, 2011, at 1:36 PM, Philip Brown wrote: > Hello there, > I'm keeping an eye on the polling thing :) and I'm curious, why you chose > "site wide, fixed configuration" > rather than having the tool auto-switch based on value of CC? > > I'm having difficulty understanding why, in cases where the tool can > easily suport both, and it will default to (something reasonable) if > CC is not set... why you would not prefer it to be auto-switching? _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
