svn commit: r249484 - head/lib

[Juli Mallett]

On Tue, Apr 16, 2013 at 11:00 PM, Tim Kientzle <kientzle at freebsd.org> wrote:
>
> 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.)

If you're doing a freestanding compile...shouldn't you also be
specifying both include and library paths explicitly?  I just feel
more confused by this explanation.  Why not just specify
-I/usr/include?  (Or even better, if you're doing a freestanding
compile, but want the default include paths, get the compiler to dump
the default include paths and process that.)  /usr/lib/include is just
badly and plainly wrong unless it's absolutely, absolutely necessary.

> 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
>