checking for gcc

[Thomas De Contes]

Le 3 mai 09 à 00:32, Rainer Müller a écrit :

> On 2009-05-02 17:01, Thomas De Contes wrote:
>> Le 2 mai 09 à 16:09, Rainer Müller a écrit :
>>>> but when i put an other compiler which knows ada in my path, i get
>>>> configure: error: Could not locate a working Objective-C runtime.
>>>> so it would be nice to do it, so i won't have to change my path  
>>>> every
>>>> time :-)
>>> Please file a ticket against the port for which this happens. It
>>> has to
>>> be patched to adhere CC from the environment (or configure call)
>>> instead
>>> of calling gcc directly.
>>
>> it *is* MacPorts, not a Port
>
> So it is your task to point it to a working compiler with Objective-C
> support in the environment or pass it to configure.

see below

>
>> rsync -azv rsync://rsync.macports.org/release/base/ macports/
>> cd macports/
>> ./configure --enable-readline --prefix=/Users/thomas/Documents/prgm/
>> bin/autoinstall/macports --with-install-user=thomas --with-install-
>> group=thomas
>>
>> curiously, the problem doesn't happen when i do
>> port selfupdate
>
> port probably removed the path to the non-working compiler from  
> PATH by
> applying its own binpath.

ok, thank you :-)

>
>> [...]
>
>>> MacPorts just requires any C compiler to compile and does not limit
>>> this
>>> to /usr/bin/gcc-4.0. I don't see a reason to do so.
>>
>> i think it's bad, i explained why
>
> It works fine with the default on both Tiger and Leopard. If you make
> customizations I assume you would also have the knowledge to get
> MacPorts compiling with your custom settings.

well, regarding what Ryan Schmidt wrote ...



Le 26 avr. 09 à 22:27, Ryan Schmidt a écrit :

>>> We do not want to increase the testing burden even further by  
>>> allowing users to compile ports with a different compiler than  
>>> the one the port author tested with. For this reason, MacPorts  
>>> instructs ports to ignore what the user has gcc_selected'ed and  
>>> instead to use a specific compiler on specific OS versions (3.3  
>>> on Panther, 4.0 on Tiger and Leopard). Individual ports can  
>>> override this if it's necessary for those ports, but users are  
>>> not supposed to override this.
>>
>> i fully (i think) understand this :-)
>>
>> and i see 2 options :
>>
>> 1
>> don't constraint anyone to use /usr/bin/gcc-4.0 and nothing else
>> of course, you support only /usr/bin/gcc-4.0 and nothing else, and  
>> port authors don't have any more test to make
>> just, you don't restrict it "physically" :-)
>> and you could write a big big warning at time of building MacPorts  
>> itself
>>
>> 2
>> once i've understood "the mechanism", i was surprised that  
>> building MacPorts itself worked fine, without even a warning !
>> i would expect that MacPorts refuse to build, saying it need /usr/ 
>> bin/gcc-4.0 (even if it doesn't need it for itself, regarding to  
>> the default settings for ports)
>>
>>
>> the 1 is the best from my point of view (it's the most  
>> "adaptable"), but there is probably a lot of changes to do, for  
>> not enough advantages
>> but i think that the 2 is realist, what do you think about it ? :-)
>
> I do not want (1). I do not want users to change the compiler. I  
> can see no reason to do so. It can only cause problems -- problems  
> which some users will inevitably write to the list for help with,  
> thus increasing our burden to help people and reducing the time we  
> have available to help with other problems.
>
> Regarding (2), MacPorts base does not complain about gcc 3.3 simply  
> because nobody has added code to do so. Actually, it should not  
> complain;  should just use /usr/bin/gcc-4.0 (on Tiger and Leopard)  
> regardless of what has been gcc_select'ed, but again nobody has yet  
> added code to do so. I do not know if there is any real problem  
> with compiling MacPorts base with gcc 3.3 on Tiger or Leopard.  
> Certainly, MacPorts base has to be compiled with gcc 3.3 on Panther  
> and it works there.



... i don't understand why you prefer (1) for MacPorts itself

since Ryan Schmidt uses (2) for ports, i don't see what kind of  
avantage you get using (1) for MacPorts itself


i fully understand Ryan's choice, and finally I agree with him
what aren't you agreement in what he said with ?


and anyway, i find that it's better to have MacPorts homogeneous,  
between itself and its ports, don't you think ?



-- 
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/