On Apr 16, 2013, at 6:41 AM, Tijl Coosemans wrote: > On 2013-04-14 21:13, Tim Kientzle wrote: >> Author: kientzle >> Date: Sun Apr 14 19:13:51 2013 >> New Revision: 249484 >> URL: http://svnweb.freebsd.org/changeset/base/249484 >> >> Log: >> Install a symlink >> /usr/lib/include ==> /usr/include >> >> This fixes -print-file-name=include in clang (and is >> arguably a better way to fix the same issue in GCC than >> the change I made in r231336). >> >> MFC after: 1 week >> >> Modified: >> head/lib/Makefile >> >> Modified: head/lib/Makefile >> ============================================================================== >> --- head/lib/Makefile Sun Apr 14 18:36:30 2013 (r249483) >> +++ head/lib/Makefile Sun Apr 14 19:13:51 2013 (r249484) >> @@ -252,4 +252,7 @@ _libusbhid= libusbhid >> _libusb= libusb >> .endif >> >> +afterinstall: >> + ln -fs ../include ${DESTDIR}/usr/lib/include >> + >> .include <bsd.subdir.mk> > > This breaks with -DNO_CLEAN defined, because then > ${DESTDIR}/usr/lib/include/include is created.
That's a good point. Would this work better?
afterinstall:
if [ ! -e $(DESTDIR)/usr/lib/include ]; then
ln -fs ../include $(DESTDIR)/usr/lib/include
fi
> I'm not that fond of this patch by the way, but I don't fully
> understand the problem it's trying to solve so I won't object.
> It just looks too much like a hack to me
It's a subtle issue and I'm not surprised that it raised some
eyebrows. I spent a long time looking for a better solution.
In short, both GCC and Clang make some assumptions
about the layout of headers used for freestanding compiles.
(My earlier commit said these assumptions were "undocumented",
but that's not quite true, they're just rather obscure.)
This symlink is the simplest way I've found to reconcile those
assumptions with the FreeBSD directory layout. I'm happy to
consider alternatives.
Tim
signature.asc
Description: Message signed with OpenPGP using GPGMail
