Chuanqi Xu via SG15 <sg15_at_[hidden]> writes:

> In case we would love to do the same thing when writing the object to
> a known location, we need to handle/answer the following things:
>
> (1) Where should be the position for the produced BMI of the std module?
>
> (2) Where should be the position of the produced object file of the std
> module?
>
> (3) Do we want to share the BMIs and object files with other invocations
> in the same system?
>
> (4) If (3) is yes, how can we find a BMI and the object file that match the
> flags and compilers we're using. For example, a BMI for std module
> produced with `-std=c++23` can't be consumed with an invocation with
> `-std=c++20`. Also a BMI produced with clang18 can't be consumed with an
> invocation with clang19. And then how can we record that? This should
> not be an easy problem.
>
> (5) Once the `std.cppm` and the corresponding header files changes, how
> can we know that to remove the existing BMIs and object files.
>
> If we can answer all of the issues, I think we're inventing a new tiny
> build systems. But this is not our goal.

Agree and would also add that if you choose to share BMIs, you will
also have to deal with concurrent invocations/file locking.

Perhaps we are approaching this from the wrong end? Maybe instead of
the compiler acting more and more like a build system we can make
the build system act more like a compiler? That is, a build system's
driver can support the "direct compilation" mode that mimics the
compiler invocation while under the hood taking care of the above
"build system" issues (which would naturally be quite easy).

Specifically, instead of, say:

$ clang++ -c hello.cpp

One would run (using the build2 driver as an example):

$ b -m cxx clang++ -c hello.cpp

(I am just riff'ing on the idea; here `-m cxx` means "ask the
build system module that provides the C++ compilation support
to perform direct compilation using the arguments that follow".)

Some extra things that immediately follow from this:


- Sensible default so you don't need to specify /EHsc /nologo or
  -fPIC manually.


- We could support change tracking:

$ b -m cxx clang++ hello.cpp impl.cpp
$ touch hello.cpp
$ b -m cxx clang++ hello.cpp impl.cpp # Only recompiles hello.cpp.


- We could support additional operations, such as clean, test,
  install/uninstall:

$ b clean -m cxx clang++ hello.cpp impl.cpp


- We could invent an imaginary compile option for producing static
  libraries:

$ b -m cxx clang++ hello.cpp # Executable.
$ b -m cxx clang++ -shared hello.cpp # Shared library.
$ b -m cxx clang++ -archive hello.cpp # Static library.


In a sense it becomes a form of "build by convention" support where
the convention is not how we lay source files on disk and name them
but how we invoke the compiler.

I could probably prototype something like this in build2 if there is
interest.