On 4/28/22 3:54 PM, Ville Voutilainen wrote:
> 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.
Yes.
>
>>> 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.

I'm content with the solution that Clang has offered since version 3.6
or so. It manages a cache of implicitly built modules in a platform
dependent but overridable location, typically within the user's home
directory.

Sure, build systems have all kinds of advantages. They also impose
overhead relative to ad-hoc interactive compiler use.

>> 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.
That is why I said, "it depends".
>
> 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?".
I will because I write and test small code samples on remote machines
many times every day. Those machines typically do not have an IDE
installed and even if they did, it wouldn't be worth it to me to deal
with the remote display issues.
>
> 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.

That may be a reason. But folks may be underestimating how frequently
their compiler drivers are used for simple ad-hoc purposes too.

Tom.