[csw-maintainers] auto-switching thing
gadavis at opencsw.org
Mon Mar 21 23:03:41 CET 2011
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 . 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, 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  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.
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?
More information about the maintainers