apr binary package misconfigured?

Blair Zajac blair at orcaware.com
Mon Oct 15 07:24:35 PDT 2012



Regards,
Blair

On Oct 15, 2012, at 7:09 AM, "Daniel J. Luke" <dluke at geeklair.net> wrote:

> On Oct 15, 2012, at 9:56 AM, Joshua Root <jmr at macports.org> wrote:
>> On 2012-10-16 00:27 , Ryan Schmidt wrote:
>>> I just don't understand for what purpose apr installs a program that offers information about what compiler was used. It's not apr's business to do that. Or I would say no other program should care what compiler apr was compiled with.
>> 
>> It is apr's business to offer information about how to build, including
>> a usable compiler. Remembering the compiler used to build apr itself is
>> a simple but unrobust approach, given that it doesn't work in the
>> general case. Even when building everything locally, a user could still
>> build apr with Xcode 3.2, then install Xcode 4.2. And in more general
>> binary distribution scenarios, it seems like you wouldn't be able to
>> rely on any particular compiler being present.
> 
> 
> presumably, the apr maintainers also don't want to be in the business of testing binary compatibility between every possible compiler combination...

They are not in this business and this is a problem we put on ourselves by wanting to swap compilers.  Thankfully, Apple does a really good job ensuring that compiling with any of their compilers works when it's all linked together.

> 
> Have we decided on which approach we want to take for this (in what I think is decreasing order of likelihood)?
> 
> - We can change the compiler on activate, but that still can break if the user upgrades xcode at some point while it's installed

This is definitely the easiest to implement on a per-port basis.

> - We could provide our own cc/ld/whatever as scripts that always point to the 'correct' compiler
> - we could provide our own cc/ld/whatever that might also fix other issues (ie, that won't link with thinks in /usr/local)

Keeping the links correct when Xcode is updated would be the only issues.  We may need a macports-xcode-select style program to update symlinks.

Blair

> 
> something else?
> --
> Daniel J. Luke                                                                   
> +========================================================+
> | *---------------- dluke at geeklair.net ----------------* |                          
> | *-------------- http://www.geeklair.net -------------* |                          
> +========================================================+
> |   Opinions expressed are mine and do not necessarily   |                          
> |          reflect the opinions of my employer.          |                          
> +========================================================+
> 
> 
> 
> _______________________________________________
> 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