Alexander,
If we are seriously going to deprecate the usage of the /usr/X11
and /usr/X11R6 symlinks, a better and more automated approach would be
implementing this directly in fink. Detection of a BuildDepends
x11-dev would be used as a trigger for appending -I/usr/X11/include
(for 10.7/10.8) and -I/opt/X11 Ifor 10.9 and later) to CPPFLAGS.
Likewise, -L/usr/X11 (for 10.7/10.8) and -L/opt/X11 (for 10.9 or
later) would be appended to LDFLAGS when a BuildDepends on x11-dev is
detected.
Considering how often --x-includes= and --x-libraries= is
fully or partially broken, the above approach will make configure less
like to fail to detect X11 support.
Jack
On Tue, Feb 10, 2015 at 1:26 AM, Alexander Hansen
<alexanderk.han...@gmail.com> wrote:
>
>> On Feb 9, 2015, at 10:11 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>>
>> On Tue, Feb 10, 2015 at 12:46 AM, Alexander Hansen
>> <alexanderk.han...@gmail.com> wrote:
>>>
>>> On Feb 9, 2015, at 8:52 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>>>
>>> Alexander,
>>> So we are taking the position that users shouldn't be expected to
>>> reinstall Xquartz after OS X reinstalls?
>>> Jack
>>>
>>>>
>>>
>>> Do they need to? If only the convenience symlink is missing, then that’s
>>> idiotic.
>>
>> Alexander,
>> We should at least be consistent. If we aren't going to
>> provide maintainers with an expectation that /usr/X11 and/or /usr/X11R
>> will always exist, how can be rationally allow packages to pass...
>>
>> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
>>
>> on ConfigureParams which then effectively lies to configure about
>> those locations? Also, how can the nonexistence of /usr/X11 and/or
>> /usr/X11R not break the many package whose builds currently set
>> -I/usr/X11/include or -I/usr/X11R6/include on CPPFLAGS, CFLAGS and/or
>> CXXFLAGS as well as -L/usr/X11/lib or -L/usr/X11R6/lib on LDFLAGS.
>> Never mind those instances in the cmake builds where CMAKE flags are
>> passing those paths for the X11 headers and libs.
>> Jack
>>
>
>
> Those should be updated. The existence of the symlinks historically was
> enforced half-assedly in fink, where some virtual packages looked for items
> only in /usr/X11R6, and some allowed /usr/X11.
>
> The only legitimate reason to have /usr/X11R6 in the mix was so that packages
> could maintain compatibility with 10.4 so that maintainers didn’t have to
> bother to diff between .infos in different trees. That hasn’t been
> supported for a long time now, and I didn’t think that going back into the
> X11 configuration of the past was a good idea for the future. /usr/X11 is
> still necessary for 10.7 compatibility, of course, so we can’t really get rid
> of that until we ditch 10.7 finally.
>
> I’d argue that we maybe could get some use out of either an enhancement to
> one of our build helper packages (like fink-buildenv-modules) or a new
> package. We could have that set some environment variables like
> X11_INCLUDES, X11_LIBS based on the real supported X11 tree of the OS version
> in question, and other packages could use those.
>
> Also, I’d argue that packages which link to X11 should have been
> revision-separated between 10.7 and 10.8, because in the former case they
> link X11 libraries with install_names containing /usr/X11 and in the latter
> those contain /opt/X11, because that’s a supported upgrade path, and without
> the symlinks the potential for runtime breakage exists.
>
> On the other hand, going between 10.9 and 10.10 losing the symlinks produces
> no runtime breakage, because the library install_names all contain /opt/X11.
>
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
