On Oct 15, 2012, at 9:56 AM, Joshua Root <j...@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...
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
- 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)
something else?
--
Daniel J. Luke
+========================================================+
| *---------------- dl...@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@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
