ports need to indicate whether they work with +universal (was: Re: Newbie ncursesw problem - can't install apache2 | Re: port should not complain about +universal, CFLAGS/LDFLAGS, configure.universal_cflags-append/configure.universal_ldflags-append)

Elias Pipping pipping at macports.org
Fri Mar 23 07:38:19 PDT 2007 

I'm merging these two threads to create a new one, because

  * they (now) deal with the same topic
  * their names are too long and unrelated to the current topic

so please

  * reply to this email instead
  * leave off the (was: ...) part

Regards,

Elias

Begin forwarded message:

> From: Elias Pipping <pipping at macports.org>
> Date: March 23, 2007 3:24:25 PM GMT+01:00
> To: Ryan Schmidt <ryandesign at macports.org>
> Cc: Macports dev <macports-dev at lists.macosforge.org>
> Subject: Re: port should not complain about +universal, CFLAGS/ 
> LDFLAGS, configure.universal_cflags-append/ 
> configure.universal_ldflags-append
>
> 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
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev
Begin forwarded message:

> From: Elias Pipping <pipping at macports.org>
> Date: March 23, 2007 3:33:38 PM GMT+01:00
> To: Ryan Schmidt <ryandesign at macports.org>
> Cc: Macports Dev <macports-dev at lists.macosforge.org>
> Subject: Re: Newbie ncursesw problem - can't install apache2
>
> On Mar 23, 2007, at 11:10 AM, Ryan Schmidt wrote:
>
>> On Mar 20, 2007, at 10:57, Elias Pipping wrote:
>>
>>> This is a serious problem btw. That "oh there's a universal  
>>> variant, it'll surely work" thought, which is perfectly natural  
>>> but doesn't work in this case. That's why
>>>
>>>     http://trac.macosforge.org/projects/macports/wiki/Universal
>>>
>>> needs to be extended and made aware of. (alternatively, a port  
>>> could be required to hold some keyword in order to allow for  
>>> building with +universal. like 'build_universal yes' or something.
>>
>> I think your wiki list is perhaps helpful right now, but not a  
>> viable long-term solution. I would want a solution that's  
>> completely contained within the MacPorts software.
>
> It wasn't meant to be a standalone solution. A start rather. I'd  
> like an infrastructure like the guys over at gentoo have it.[1]  
> (without the wait for something to become stable, though, at least  
> at first)
>
>> I would prefer a variable named something like "universal_works"  
>> or "universal_ok" which could be set to "yes" or "no". The default  
>> would be neither, more of an "I don't know" or "maybe" state.  
>> Ports where the maintainer has tried the +universal variant and  
>> believes it to work should have "universal_ok yes" added. Ports  
>> that have been tested and found not to work universally should be  
>> marked with "universal_ok no" (that's assuming they cannot be  
>> easily fixed to work universally). Anyone who tries to build a  
>> port that has neither marking would get a warning that the  
>> universal build is untested, and that they should let us know if  
>> they find that it works or doesn't work.
>
> That's good for now, but it's only a short term solution as well,  
> because it only says something about the universal variant whereas  
> we need information about what works for every package on every  
> supported platform with every variant (the variants will be ugly).
>
> [1] http://packages.gentoo.org/search/?sstring=bash
>
> Regards,
>
> Elias
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev

More information about the macports-dev mailing list