C++ Logo

sg15

Advanced search

Re: [Tooling] Modules feedback

From: Matthew Woehlke <mwoehlke.floss_at_[hidden]>
Date: Mon, 11 Feb 2019 16:39:43 -0500
On 11/02/2019 15.45, Steve Downey wrote:
> I think you can linearize the scan of all the translation units by assuming
> all of the unknown modules will be in $PROJECT_MODULE_DIR/module_name.bmi,

I'm not sure what "linearize" means here? I'm also not sure how it
helps; until you know what generates that module, you can't build the TU
that depends on it.

> and when you find the interface unit that produces module_name, write out
> the build dependency there.

That's basically how CMake works for Fortran.

> This works less well for external dependencies.

Well, for external dependencies, you just assume that the information
how to generate their BMI's already exists (as per discussion in my
previous message). If you don't find a module *at all*, that's a hard
build error. Plausibly the collator could detect this, but I'd be fine
with the compiler just croaking because it can't import the module.

> There's also the additional complication that the imported module name may
> not exist yet. That should be a build error

No, it should *work*. Again, this isn't a problem in the approach CMake
uses for Fortran modules.

> Building unrelated source should still be possible, the keep-going
> option.
The "keep going" option is a band-aid for "my build system is broken".

-- 
Matthew

Received on 2019-02-11 22:39:46