Re: [boost] Link dependencies (was: [mpl] [build] [testing] Mergepullrequests)

Subject: Re: [boost] Link dependencies (was: [mpl] [build] [testing] Mergepullrequests)
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-12-04 05:42:13

On December 3, 2014 4:07:22 PM EST, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
>On Wed, Dec 3, 2014 at 11:30 PM, Rene Rivera <grafikrobot_at_[hidden]>
>wrote:
>> On Wed, Dec 3, 2014 at 2:07 PM, Andrey Semashev
><andrey.semashev_at_[hidden]>
>> wrote:
>
>Frankly, I'm not sure any build system even attempts to parse C/C++,
>let alone do some preprocessing. I must say, I don't know many build
>systems, though.

None do, to my knowledge.

>The way I see it, it would take a little more than a C++ preprocessor
>to do this. The preprocessor would have to support macro unfolding to
>obtain the file name. Note that the unfolding can yield different
>results depending on compiler/platform/etc., and the build system
>would have to collect all such combinations to get the full list of
>the possible includes.

Right.

>I had something like the following in mind:
>
>1. Boost.Build finds an #include in a source file.
>2. It determines which library this header belongs to.
>3. It parses the header to obtain the "obvious" dependencies from
>#includes not obscured by preprocessor.
>4. It also peeks into the library Jamfiles to obtain dependencies
>defined by the library developer.
>
>1-3 is basically what happens now. 4 is needed to explicitly describe
>dependencies which Boost.Build is unable to infer from headers. If
>Jamfiles don't fit for this role, I'm ok if it's a different config
>file.

Why not a dedicated header that exists to guide Boost.Build?

___
Rob

(Sent from my portable computation engine)