Re: [Boost-build] feature, properties, variants, and all the rest

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-09-29 21:27:20

On 29.09.2017 17:14, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 09/29/2017 01:07 PM, Stefan Seefeld via Boost-build wrote:
>> On 29.09.2017 14:58, Steven Watanabe via Boost-build wrote:
>>> On 09/29/2017 12:33 PM, Stefan Seefeld via Boost-build wrote:
>>>> On 29.09.2017 14:20, Steven Watanabe via Boost-build wrote:
>>>>> - It can scan headers that are generated during the build.
>>>> and so can a compiler-based approach.
>>>>
>>> I don't know any perfect way to handle this.
>>>
>>> It's impossible to complete the scan before
>>> building all the headers that are required.
>> A generated header is like any other artefacts (targets): before it
>> exists, dependencies need to be explicitly provided to bjam. Once it
>> does exist, it can be scanned.
>>
> This is only practical when the number of
> generated headers is very small.
>
>> <snip>
>>
>>> It's also impossible to determine which headers
>>> are required before scanning.
>> Well, for generated headers I would assume this information to be
>> explicitly provided to the build tool. Are there situation where that's
>> not practical ?
>>
> b2 headers.  (The entire header tree is created by
> copying from multiple sources.)

Hmm, I should continue my work on faber, then provide some build logic
for boost so we can compare performance on that scale. :-)
(I'm not disagreeing with your assessment. I'm just stating that
correctness should win over performance, in particular as the exact
performance impact remains to be measured.)

> Also, `gcc -M` is very C specific.  For languages
> that don't use the C preprocessor (or equivalent),
> either you can calculate the dependencies accurately
> a file at a time, or you can't calculate them perfectly
> no matter how hard you try.
I would actually use that as an argument for my approach, not against
it: I want faber to be totally agnostic of language-specific idioms
(such as "header" and "include"), which means these things have to be
layered on top, into language-specific extensions ("tools"). So if I
want to generate a binary from "C++" code, a C++ toolchain is used both
to compute the dependency graph as well as to compile the code. If the
source code is in "Java", a Java toolchain should be used instead. The
underlying build engine has no knowledge about how to do either.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...