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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
