Re: [Boost-build] Language specific include paths

Subject: Re: [Boost-build] Language specific include paths
From: Daniel James (dnljms_at_[hidden])
Date: 2018-02-14 16:39:15

On 14 February 2018 at 16:18, Steven Watanabe via Boost-build
<boost-build_at_[hidden]> wrote:
> AMDG
>
> On 02/14/2018 09:02 AM, Daniel James via Boost-build wrote:
>> On 14 February 2018 at 15:40, Steven Watanabe via Boost-build
>> <boost-build_at_[hidden]> wrote:
>>> On 02/14/2018 06:23 AM, Daniel James via Boost-build wrote:
>>>> When building quickbook in boost, there's an include path to boost
>>>> root. I think that's because the 'project' in Jamroot has
>>>> 'requirements <include>.' which gets picked up by quickbook. This
>>>> isn't really a problem here as there aren't many quickbook files
>>>> hanging around in boost root, but it's not ideal. So is it possible to
>>>> make the include requirement only apply to C/C++ builds?
>>>
>>> That's what <include> ought to mean in the first place.
>>
>> Maybe it should have, but that horse bolted long ago.
>>
>
>   That's its documented behavior as well.
> http://www.boost.org/build/doc/html/bbv2/overview/builtins/features.html
> "include: Specifies an additional include path that is to be passed to C
> and C++ compilers. "

That isn't its behaviour though.

>>>> I think it's
>>>> a bit late to change the quickbook toolset so that it doesn't use
>>>> <include>,
>>>>
>>>
>>>   Sorry, but that's the only reasonable fix.
>>> If you insist on using <include>, then you
>>> will get C/C++ include paths from various
>>> sources (including the command line and library
>>> usage-requirements)
>>
>> I don't use <include>, let alone insist on it.
>
>   Then do you have any complaints if I nuke the
> use of include and replace it with a separate feature?

It'll break other people's builds.

>> This is entirely due to
>> boost build's design.
>>
>
>   It's only the quickbook toolset that's a problem.
> Abusing include is just plain wrong.

The quickbook toolset is part of boost build, not quickbook. It also
looks like asciidoctor, sass and rc do the same thing, maybe more. I'm
not sure, but the zlib and libjpeg toolsets might pick up include
paths that they're not meant to.