port should not complain about +universal, CFLAGS/LDFLAGS, configure.universal_cflags-append/configure.universal_ldflags-append

[Elias Pipping]

On Mar 23, 2007, at 11:21 AM, Ryan Schmidt wrote:

>
> On Mar 18, 2007, at 05:52, Elias Pipping wrote:
>
>> Let's wait for official support of +universal with that...
>
> Well, how will we get official support of +universal unless we push  
> for it? Now that I have an Intel Mac, it no longer takes forever  
> for me to compile things, so I'm trying to build as many things  
> universal as I can. And I will continue to bring to the list's  
> attention all problems I encounter in this endeavor. And we should  
> all try our best to fix the problems.
>
> When will we get +universal anyway? Right now, I'm running MacPorts  
> compiled from trunk, a.k.a. 1.500, because the 1.4rc2 release  
> doesn't appear to contain the default +universal variant. The  
> messages that have been inserted into some portfiles suggest that  
> the default +universal variant should have been in MacPorts 1.400.  
> So what's up?

that was done before the version of the trunk was bumped to 1.5. -  
it's malinformation now

>> eventually the whole if clause will be gone anyway.
>
> I understand that the if clause in the portfiles testing for the  
> universal functionality will go away, once that functionality is  
> generally available. That does not fix the problem that the port  
> system will still print a warning that the port might fail to build  
> universally, when in fact it will not. I stand by my original  
> statement that the port system should not print the warning about  
> the CFLAGS or LDFLAGS if the portfile uses the  
> configure.universal_cflags-append or configure.universal_ldflags- 
> append options.

that was unrelated to the issue you described, indeed.

>> I mean really, there's worse problems than obsolete warnings
>
> I think inaccurate warnings are almost worse than no warnings. If I  
> try to install something universal, and it says "warning! this may  
> not work!" then I will stop the build and examine the portfile to  
> see what I think. Then I find the configure.universal_cflags-append  
> bit or whatever which means it most likely will work because  
> someone has gone out of their way to add that specifically for  
> universal support. So then I get annoyed that I was made to check  
> the portfile source.
>
> Maybe this is all a moot point if the "universal_ok" flag is  
> implemented as I described in the other thread. Then portfiles  
> known to build universally can include "universal_ok yes", and the  
> port system can then check just for that variable and not bother  
> checking for CFLAGS, LDFLAGS or anything else.

sounds good - and a port that doesn't have that flag shouldn't  
display 'universal' as a variant.


>
>> especially with gettext. e.g. gettext +universal is somehow  
>> incomplete: all the libasprintf-related files are missing  
>> completely. diff the results of port contents with and without  
>> +universal and see for yourself (ideas, patches appreciated)
>
> Hmm. I wasn't aware of that. But I have no idea what libasprintf is  
> or why I would want it, and I don't know what to do about its  
> absence either.
>

I've fixed it in a recent commit[1]. the problems was simply that  
gettext is written in C++, hence g++ needs the same flags as gcc (the  
isysroot and the arch flags). gettext +universal is now stable[2].

[1] http://trac.macports.org/projects/macports/changeset/23028
[2] http://trac.macports.org/projects/macports/wiki/ 
Universal#gettext0.16.1_0

Regards,

Elias