> 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
