Let's first see what exactly we have to deal with:
1) We need to ensure that all the C++ code on a system is compiled with the same version of GCC, either 3.1 or 3.3. (exceptions can be made for C++ code which is completely self contained, i.e. which doesn't use any external C++ shared libraries, and which doesn't provide .dylibs).
2) Migration of systems built around 3.1 to 3.3 (as that will be the Panther compiler).
Problem 2 is probably "easiest" to solve: we have to recompile (or reinstall via bindist) all the affected packages using GCC 3.3. I hope that fix-fink could be extended to do this (how exactly it detects 3.1 code, whether by looking at the .info file or some other means, is a minor detail in this regard, I think).
The really biggy is 1), of course. We could just be "lazy" and force everybody to update to 3.3 immediately, and relay on step 2 alone. I am not exactly happy with that solution, but it *is* a possibility (just not a really nice one, we'd have to force all our users to get those funky new "developer tools", for one thing).
And in any case: it doesn't handle the case when the user does a "gcc_select". In fact, AFAIK we don't handle that situation at all right now (I don't even want to think what happens if somebody does that during an ongoing compilation <shudder>). Granted, this will be an uncommon scenario, I figure only a tiny percentage of users will ever user gcc_select (or even know about :-), but one we should keep in mind.
So, one possible approach would be that for a given Fink installation, Fink somewhere (in fink.conf?) stores the information which GCC was used for the installation. We probably would determine that setting at bootstrap time for new installation (check the currently active GCC, or ask the user, or use the latest available GCC, or so); for existing installations, we'd have to be a bit more clever (we could assume 3.1 for 10.2 and 3.3 for 10.3). Changing that setting from 3.1 to 3.3 would be done by fix-fink when performing the step 2 mentioned above.
Now, to ensure that really the correct GCC is used, we could insert our own symlinks for gcc into the $PATH during the compile phase - a bit like the /sw/bin/cc symlinks cctools-extra installs. In particular, that symlink would point to either /usr/bin/gcc2, /usr/bin/gcc3 or /usr/bin/gcc-3.3. Of course we'd have to make sure cctools still works, if installed, which complicates things a bit more. And of course we have to inserts lots of error checking code etc. (we could even go so far and first "ask" gcc for its version to deal with unknown GCC versions etc.)
A bit cleaner would be to just provide proper default values of CC/CXX etc. environment / make variables. Alas, I am not confident that this will have any effect in general, so it probably isn't generic enough for our needs.
With this approach, we'd effectively guarantee that exactly the GCC version we want is used for compilations, no matter what the user does with gcc_select. We can also easily switch to gcc 3.3, if desired, again w/o having to force the user to do a gcc_select.
OK, so I just made this up on the spot. I am sure others thought of similar approaches. I know there are plenty of rough spots in this, consider it a sketch. Also I am sure there are lots of flaws in my thoughts, so I am now waiting for your guys to rip it apart, point out the obvious problems I missed, and make alternate suggestions :-)
Cheers,
Max
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
