[27018] trunk/base/src/port1.0/portconfigure.tcl

Anders F Björklund afb at macports.org
Sun Jul 15 16:50:55 PDT 2007


Ryan Schmidt wrote:

> Initially of course this could simply replace the explicit 
> configure.env setting that we're doing in some portfiles.
>
> I hope though that this is also intended to take care of the situation 
> where many portfiles explicitly use the system's gcc4 on darwin 8, 
> which I don't understand because that should be the default anyway. 
> This has bugged me for a long time. Even some of my portfiles do it, 
> because they were like that when I took over maintenance of them and I 
> don't want to remove those lines until I understand why they were 
> added in the first place. It seems like it only guards against users 
> who have used gcc_select to select a different default compiler. Users 
> should not do that, of course... but now that we have this 
> configure.compiler option, we could make "gcc-4.0" the default on 
> darwin 8 and "gcc-3.3" the default on darwin 7. Wouldn't that be the 
> best idea? Then we could remove the darwin 8 variants from so many 
> ports.

This was the idea behind why I mentioned it, at least. (I was looking 
at the x86 thing and wondered why there were so many occurrences of the 
darwin_8 variant in particular - and it was mostly use of 
configure.env)

Somehow getting rid of the +universal variant would be nice too, but 
that can come later - at least after the various Summer of Code is 
over. But universal isn't really a "variant", it's an arch - just like 
noarch...

Or actually it's an arch (or two really but) *and* a Platform SDK, but 
that's another (long) story.


But ideally it would be awesome if this could be expanded into allowing 
say building for PowerPC on an Intel box (by using arch flags) or 
building for Panther on a Tiger machine (by using a SDK).

That does require a whole cross-compiling setup though, and could get 
somewhat complex so better get the +universal working first. Probably 
raises some interesting prefix-for-each-SDK questions too.

--anders




More information about the macports-dev mailing list