[28325] trunk/dports/graphics/wxWidgets-devel/Portfile

Ryan Schmidt ryandesign at macports.org
Sat Sep 1 13:45:54 PDT 2007

On Sep 1, 2007, at 06:20, Weissmann Markus wrote:

> On 31.08.2007, at 16:21, N_Ox wrote:
>> Le 30 août 07 à 19:40, Anders F Björklund a écrit :
>>> Ryan Schmidt wrote:
>>>> Why do we keep repeating these lines in so many portfiles? Why  
>>>> isn't "configure.compiler gcc-4.0" the default on darwin 8, and  
>>>> similarly, "configure.compiler gcc-3.3" the default on darwin 7?
>>> +1
>>> If nothing else, it keeps those pesky "+darwin_8" variants  
>>> alive. :-(
>> I don't even understand why there is a default compiler hard  
>> written in ports.
>> gcc-4 is the default on Tiger, users who change this behaviour  
>> surely know some things may break.
> The problem is that a user can use 'gcc_select' and you have no  
> idea what 'gcc' .. executes on 10.4; if you know that your port is  
> happy with any of the two, dont use a platform statement. If you  
> dont want or dont can (e. g. on x86) to test your port with both  
> compilers, state explicitly which one you know it compiles with.

(I'm speaking of Tiger users here, which should be most of us:) I  
really don't think that any port authors, for every update of every  
port that they maintain, try it once with gcc 4 and once with gcc  
3.3. Rather, I think they probably just try it with the default  
compiler selected on their machine, which would hopefully be gcc 4.  
By your logic, then, every such port should have gcc 4 listed in the  
darwin 8 section, to show that that's what it's been tested with. So,  
instead of that, it would be much better to do it globally at the  
MacPorts level, since it's reasonable to assume that ports on Tiger  
have been tested with Tiger's default compiler. Only ports that  
deviate from this (for example, the rare port that still requires gcc  
3.3 on Tiger) should have to indicate this.

> I have no idea what will happen to every single port if we tell  
> port to automatically select a compiler if none is requested  
> explicitly (though we can have a try).

Let's work through some scenarios then. Let us assume that the ports  
about which we're talking currently compile correctly and work. (If  
they don't, then the ports need to be updated anyway.)

Assume there is a port that does not indicate what compiler it  
requires. On a standard Tiger system where gcc 4 is selected, it will  
currently use gcc 4. If we now change MacPorts so that gcc 4 is used  
on Tiger in preference to whatever gcc_select says, nothing changes.  
The port continues to use gcc 4 and continues to work.

Using the same port, let's assume some user has used gcc_select to  
select gcc 3.3 without understanding the implications. They build  
this port. It happens to work. Great, no problem. If we change  
MacPorts so that gcc 4 is the default, the port continues to work.  

Using the same port and the same user who selected gcc 3.3, let's  
assume the port fails to build under gcc 3.3. In this case, with  
current MacPorts, the port fails and the user complains. If we change  
MacPorts to use gcc 4 as the default, the port would instead work,  
and the user would be happy. So this is a reason to change MacPorts  
as I indicated.

Let's move on to a different port, one that explicitly lists gcc 4  
for Tiger. In all scenarios, there is no change. Whether the user has  
gcc 4 or gcc 3.3 selected, the port works, because it explicitly asks  
for gcc 4. Great.

And let's look at yet another port, one that explicitly lists gcc 3.3  
for Tiger. In all scenarios, there is no change. Whether the user has  
gcc 4 or gcc 3.3 selected, the port works, because it explicitly asks  
for gcc 3.3.

To sum up: if we make gcc 4 the default for ports on Tiger, nothing  
changes for ports that explicitly request a different compiler.  
Nothing changes for users who already have gcc 4 selected, which  
should be most people. The only thing that changes is that users who  
have for some reason selected gcc 3.3, and for ports that do not  
specify a compiler, these ports will use gcc 4 instead of gcc 3.3.  
And this is a good thing, because gcc 4 is probably what the port  
author tested with. And so the port has a greater chance of working  
correctly for the user.

And then we can also remove the "gcc 4" selections from the darwin 8  
variants of all ports where that occurs, since that's redundant, and  
it's good to remove redundancy.

More information about the macports-dev mailing list