C++ Logo


Advanced search

Re: [Tooling] [isocpp-modules] Dependency information for module-aware build tools

From: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>
Date: Wed, 6 Mar 2019 16:37:12 -0500
On Wed, Mar 6, 2019 at 4:01 PM Nathan Sidwell <nathan_at_[hidden]> wrote:

> On 3/6/19 3:01 PM, Mathias Stearn wrote:
> >
> >
> > On Wed, Mar 6, 2019 at 10:18 AM Nathan Sidwell <nathan_at_[hidden]
> > <mailto:nathan_at_[hidden]>> wrote:
> >
> > Yes, a BMI is required for a header import. Textually including the
> > header import's original header file is not equivalent.
> >
> >
> > It won't be required for the scan stage will it? If it is, there is a
> > bootstrapping problem because there is no good way to figure out which
> > order to build the header-unit BMIs in if they import other
> > header-units. I've been assuming that the scan stage will be able to
> > just temporarily mask off the defines and replace them with the correct
> > ones for the header-unit while scanning a file, so that scanning has no
> > generated dependencies.
> As header units export #defines, which can go on to determine the path
> of conditional inclusion, you have to decide:
> a) if you want precise scanning, you need the header units at scan time
> b) if you're ok with imprecise scanning (getting false positives). But
> you need something other than the C++ preprocessor

If in addition to being told which headers are importable, the
scanner/preprocessor is also told what flags are used for each of those
headers, how hard would it be to just resolve it precisely internally? I
assume it could be done by something like push_macroing all current macros,
figuring out which builtin macros to use for the header unit, then when you
are done processing that header merge the pushed macros with the current
macros using the rules for modules. Is that infeasably hard or not work for
some reason?

Received on 2019-03-06 22:37:26