On Thu, 28 Apr 2022 at 22:38, Tom Honermann <tom_at_[hidden]> wrote:
> > If the compiler can't use an existing build artifact, and needs to
> > rebuild one, where is it going to put it? Is the location somehow
> > relative to the current source tree (relative how? Where?), specific
> > to the current user, something wider than that? Do you want
> > to keep it for reuse with other source files and their compilation?
>
> I would put that in the implementation-defined bucket.

Are you sure? See below.

> > Answering such questions with a build system in hand seems much more
> > reasonable, because build systems are able to do
> > all of those things.
> I don't agree with the "much more reasonable" characterization. Compiler
> drivers recognize options for directories used for many purposes today,
> both input and output. I don't see this use case as being any different.

Right.. but at least for me and many others I know, many users use a
build system
because it gives portable behavior over different compilers. I'm not
exactly sure what
you mean by the above "implementation-defined bucket", but the portability and
compatibility are rather important.

> It depends somewhat on what that "new driver" is. If it is something
> that is shipped with the compiler such that it doesn't have to be
> separately installed and configured for any particular toolchain, that
> might be ok. But it probably wouldn't be something that I could just
> drop in and use with my existing build systems.

Hmm.. why not? Isn't ccache a drop-in thing? Same for various other wrappers.
Perhaps this new driver could be a drop-in, too.

Anyhoo, *I* am not opposed to having whichever solution to this
problem, in addition to build systems,
with the hope that whatever ends up being provided is something more
than "here are seven different
ways to do a modular std-using helloworld in modern C++ with seven
different single command lines". I don't particularly care, myself,
whether
this is being provided as a new portable driver. I'll be using CMake
as soon as it can help me with modules,
and I and many other users won't be doing all that many purely
command-line builds, because we'll absolutely
cheat and have the IDE generate the initial CMakeFiles.txt which we'll
then tweak both from the IDE and
directly with editors, and we'll then run that build both from the IDE
and from the command line.
And for me and those users, we'll remember this sort of discussion
with popcorn and say "well, we ended
up with the thing we expected, 'cmake --build .', did anyone manage to
miss the ability to do the initial generation
from the command line so that you can build helloworlds without that
short trip to the IDE? Anyone?".

That's quite possibly a reason why folks like Gaby don't necessarily
think the sand castle build with just a compiler is worth
high priority. Because going to the skyscrapers, or even going to the
ground floor of the skyscraper and building a sand castle
there takes you where you want to go anyway, to the tools that
abstract away all this stuff, but yet allow you to jump back
out and do things from the command line if you want. And for people
like me, a command-line utility that does "here's files,
spit out a CMakeLists.txt for me" will facilitate the sand castles
anyway, and I won't be missing this "just a compiler" facility at all.