Em ter., 30 de mai. de 2023 às 11:28, Mathias Stearn <
redbeard0531+isocpp_at_[hidden]> escreveu:

> Please don't move the goalposts. You asked me what was needed to support
> importable headers *in ninja*, so that is what I provided. This is
> especially notable in the context that where I was saying that different
> build strategies will apply for different build systems (specifically the
> execution component like make/ninja/msbuild). *Of course* a strategy that
> was specifically designed for ninja to take advantage of restat will not
> work unmodified with make which doesn't.
>

Sorry, I took too many steps. I skipped acknowledging that this would work
in ninja (which you educated me on). And moved on to the next point, which
is the impact of requiring a feature like what ninja does.


> It essentially means that `make` is no longer a viable implementation to
>> drive a C++ build (not even generated make, as CMake does). As I mentioned
>> before, we use ninja for development builds, but it doesn't satisfy all our
>> requirements for the production builds (e.g.:
>> https://github.com/ninja-build/ninja/issues/1139 ).
>>
> You also said that you'd be willing to move to ninja if they took that
> patch. Given that you have a working (I assume?) patch that meets your
> needs, I suspect that using a patched ninja is a tiny amount of work
> relative to the other build system work required to support modules.
>

Yes. I'm looking at the ecosystem as a whole. This is a whole lot of work
for a whole lot of people, if they all have to convert from one build
system to another as part of this process.


> And that's the crux of what the paper is pointing at: Only a subset of
>> build systems in use today will be able to viably support Importable
>> Headers, which will exclude systems where Named Modules could be
>> implemented.
>>
> I'm still not sure how any of this is specific to header units. The scan
> step is already required for named modules, and if you have a single
> megascan as a normal (ie not order-only) dep of every compile, AND you are
> unable to do the equivalent of restat=1, it is going to hurt.
>

The list of named modules is not an input to the dependency scan, because
they don't affect the preprocessor state.

The list of header units and their local preprocessor arguments have to be
an input to the dependency scan ("megascan" or not). Which means when the
list changes it invalidates the entire build (for a build system that
doesn't know how to stop the invalidation from propagating).


> I guess the fundamental question is whether we have consensus on "GNU Make
>> is no longer a viable C++ build driver". I, personally, strongly oppose
>> that direction.
>>
> Personally, I'd love if we could decouple from broken build systems of the
> past. There is so much fundamentally wrong with Make, that I'd love to see
> adoption of modules, and the need to do build system work anyway, be used
> as a reason to wholesale move off of it. I'm not saying that it *can't* be
> made to work, or even work well, I'm just saying that we should instead
> invest any effort in less fundamentally broken tools.
>

And it may be the case that this is the direction that we'll go, however
I'd like us to be very explicit about it. After all there are tons of
projects using a variety of build systems, and we'd be creating a whole lot
of costs for those people.

daniel