Language specific include paths

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Language specific include paths

Boost - Build mailing list
Hi,

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? I think it's
a bit late to change the quickbook toolset so that it doesn't use
<include>,

thanks,

Daniel
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
AMDG

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.

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

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
On 14 February 2018 at 15:40, Steven Watanabe via Boost-build
<[hidden email]> wrote:

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

>> 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. This is entirely due to
boost build's design.
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
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
> <[hidden email]> 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. "

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

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

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
On 14 February 2018 at 16:18, Steven Watanabe via Boost-build
<[hidden email]> 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
>> <[hidden email]> 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.
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
AMDG

On 02/14/2018 09:39 AM, Daniel James via Boost-build wrote:

> On 14 February 2018 at 16:18, Steven Watanabe via Boost-build
> <[hidden email]> wrote:
>> <snip>
>>> 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

  asciidoctor and sass were both recently added
and appear to be copying quickbook's brokenness
here.  (include doesn't even work in asciidoctor,
because -I means something different.)  I will
fix these right now regardless of breakage.

> and rc do the same thing,

  It's the right thing for rc, as rc is expected
to find C/C++ headers.

> maybe more. I'm
> not sure, but the zlib and libjpeg toolsets might pick up include
> paths that they're not meant to.
>

  I don't think so.  The include paths from depending on
/zlib//zlib will be added to whatever other include paths
the target has, but that's unavoidable.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
On 2/14/2018 11:04 AM, Steven Watanabe via Boost-build wrote:

> AMDG
>
> On 02/14/2018 09:39 AM, Daniel James via Boost-build wrote:
>> On 14 February 2018 at 16:18, Steven Watanabe via Boost-build
>> <[hidden email]> wrote:
>>> <snip>
>>>> 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
>
>    asciidoctor and sass were both recently added
> and appear to be copying quickbook's brokenness
> here.  (include doesn't even work in asciidoctor,
> because -I means something different.)  I will
> fix these right now regardless of breakage.
>
>> and rc do the same thing,
>
>    It's the right thing for rc, as rc is expected
> to find C/C++ headers.
>
>> maybe more. I'm
>> not sure, but the zlib and libjpeg toolsets might pick up include
>> paths that they're not meant to.
>>
>
>    I don't think so.  The include paths from depending on
> /zlib//zlib will be added to whatever other include paths
> the target has, but that's unavoidable.

I would like to add that in order for zlib to successfully be part of
the build, I have to use option "-s" on the b2 invocation:

-s ZLIB_SOURCE="E:\ZLibSource\zlib-1.2.11" -s
ZLIB_INCLUDE="E:\ZLibSource\zlib-1.2.11"

Whether I can now build with zlib via user-config.jam, I have not tested
it since roughly Boost 1.62.  Keep in mind that I construct Boost for
two different Windows compilers on Windows 8.1 Pro, x64 (e.g. Microsoft
and Intel C++).

--Robert

>
> In Christ,
> Steven Watanabe
> _______________________________________________
> Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
>

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
AMDG

On 02/19/2018 11:03 AM, Robert via Boost-build wrote:
>
> I would like to add that in order for zlib to successfully be part of
> the build, I have to use option "-s" on the b2 invocation:
>
> -s ZLIB_SOURCE="E:\ZLibSource\zlib-1.2.11" -s
> ZLIB_INCLUDE="E:\ZLibSource\zlib-1.2.11"
>

ZLIB_SOURCE is enough.  ZLIB_INCLUDE is actually
ignored if you pass ZLIB_SOURCE.

> Whether I can now build with zlib via user-config.jam, I have not tested
> it since roughly Boost 1.62.  Keep in mind that I construct Boost for
> two different Windows compilers on Windows 8.1 Pro, x64 (e.g. Microsoft
> and Intel C++).
>

The problem is that the library name is not mangled, right?
This can be worked around by setting a <tag> rule that
does the mangling (with -s, it's added implicitly by
Boost.IOStreams).

I just tried:

import boostcpp ;
using zlib : : <source>C:/path/to/zlib <tag>@boostcpp.tag ;

but that breaks because boostcpp.jam has bugs that
prevent it from being imported outside of Boost's
Jamroot.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Language specific include paths

Boost - Build mailing list
On 2/19/2018 12:39 PM, Steven Watanabe via Boost-build wrote:

> AMDG
>
> On 02/19/2018 11:03 AM, Robert via Boost-build wrote:
>>
>> I would like to add that in order for zlib to successfully be part of
>> the build, I have to use option "-s" on the b2 invocation:
>>
>> -s ZLIB_SOURCE="E:\ZLibSource\zlib-1.2.11" -s
>> ZLIB_INCLUDE="E:\ZLibSource\zlib-1.2.11"
>>
>
> ZLIB_SOURCE is enough.  ZLIB_INCLUDE is actually
> ignored if you pass ZLIB_SOURCE.

On my next build, I will remove the ZLIB_INCLUDE and update this thread
with the results.

>
>> Whether I can now build with zlib via user-config.jam, I have not tested
>> it since roughly Boost 1.62.  Keep in mind that I construct Boost for
>> two different Windows compilers on Windows 8.1 Pro, x64 (e.g. Microsoft
>> and Intel C++).
>>
>
> The problem is that the library name is not mangled, right?
> This can be worked around by setting a <tag> rule that
> does the mangling (with -s, it's added implicitly by
> Boost.IOStreams).
>
> I just tried:
>
> import boostcpp ;
> using zlib : : <source>C:/path/to/zlib <tag>@boostcpp.tag ;
>
> but that breaks because boostcpp.jam has bugs that
> prevent it from being imported outside of Boost's
> Jamroot.

I suppose the importing outside of Boost's Jamroot bug is the reason
zlib fails via user-config.jam.  Regardless, I am perfectly happy using
the command line option.  It always succeeds with zlib-Boost output
files. :)

Thank you very much for your help. I appreciate your knowledge and feedback.

>
> In Christ,
> Steven Watanabe
> _______________________________________________
> Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
>

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build