On Tue, 30 Jan 2024 19:22:00 +0000, Richard Harnden
<richard.nospam@gmail.invalid> wrote in <upbi8o$14443$1@dont-email.me>:

> On 30/01/2024 16:50, Malcolm McLean wrote:
>>
>> But I'm wondering about one file which contains all the sources for the
>> program. Like an IDE project file but lighter weight.
>>
>>
> In other words: a Makefile

Agreed; it's a solution looking for a problem.

$ make -j # how does Bart's new build manager handle this case?

("-j" engages parallel compilation.)

ObC:
$ cat try.c
#include <stdlib.h>
int main(void) {
return(system("make -j 16"));
} _ _ _ _ _ _ _

$ cat Makefile
CFLAGS=-g -O2 -std=c90 -pedantic
_ _ _ _ _ _ _

$ make try
cc -g -O2 -std=c90 -pedantic try.c -o try

$ ./try
make: 'try' is up to date.

--
-v

vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
> return(system("make -j 16"));

The return value of system() is not in the same format as the return value
of main().

On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor <vallor@cultnix.org>
wrote in <updt7h$1jc8a$1@dont-email.me>:

> On Tue, 30 Jan 2024 19:22:00 +0000, Richard Harnden
> <richard.nospam@gmail.invalid> wrote in <upbi8o$14443$1@dont-email.me>:
>
>> On 30/01/2024 16:50, Malcolm McLean wrote:
>>>
>>> But I'm wondering about one file which contains all the sources for the
>>> program. Like an IDE project file but lighter weight.
>>>
>>>
>> In other words: a Makefile
>
> Agreed; it's a solution looking for a problem.
>
> $ make -j # how does Bart's new build manager handle this case?
>
> ("-j" engages parallel compilation.)
>
> ObC:
> $ cat try.c
> #include <stdlib.h>
> int main(void) {
> return(system("make -j 16"));
> }
> _ _ _ _ _ _ _
>
> $ cat Makefile
> CFLAGS=-g -O2 -std=c90 -pedantic
> _ _ _ _ _ _ _
>
> $ make try
> cc -g -O2 -std=c90 -pedantic try.c -o try
>
> $ ./try
> make: 'try' is up to date.

I also had "try:" in my Makefile.

_ _ _ _ _ _ _
CFLAGS=-g -O2 -std=c90 -pedantic

try:
_ _ _ _ _ _ _

But I changed the source to make it
explicitely:

$ cat try.c
#include <stdlib.h>
int main(void) {
return(system("make -j 16 try"));
}

$ ./try
cc -g -O2 -std=c90 -pedantic try.c -o try

$ ./try
make: 'try' is up to date.

(Beats trying to learn COBOL to keep up with
comp.lang.c... ;)
--
-v

Nicolas George <nicolas$george@salle-s.org> writes:
>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a �crit�:
>> return(system("make -j 16"));
>
>The return value of system() is not in the same format as the return value
>of main().

Regardless, it suffices for a "success/failure" indication.

On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:

> Nicolas George <nicolas$george@salle-s.org> writes:
>>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
>>> return(system("make -j 16"));
>>
>>The return value of system() is not in the same format as the return value
>>of main().
>
> Regardless, it suffices for a "success/failure" indication.

Mostly. The only exception looks to be very rare: if no shell
is available, then system() returns 0. Thus, it is possible
(but, IMHO, highly unlikely) to have a failure condition that
reports as success.

--
Lew Pitcher
"In Skills We Trust"

On 31/01/2024 16:41, vallor wrote:
> On Tue, 30 Jan 2024 19:22:00 +0000, Richard Harnden
> <richard.nospam@gmail.invalid> wrote in <upbi8o$14443$1@dont-email.me>:
>
>> On 30/01/2024 16:50, Malcolm McLean wrote:
>>>
>>> But I'm wondering about one file which contains all the sources for the
>>> program. Like an IDE project file but lighter weight.
>>>
>>>
>> In other words: a Makefile
>
> Agreed; it's a solution looking for a problem.

Why do you think languages come with modules? That allows them to
discover their own modules, rather than rely on external apps where the
details are buried under appalling syntax and mixed up with a hundred
other matters.

> $ make -j # how does Bart's new build manager handle this case?
>
> ("-j" engages parallel compilation.)
>
> ObC:
> $ cat try.c
> #include <stdlib.h>
> int main(void) {
> return(system("make -j 16"));
> }
> _ _ _ _ _ _ _
>
> $ cat Makefile
> CFLAGS=-g -O2 -std=c90 -pedantic
> _ _ _ _ _ _ _
>
> $ make try
> cc -g -O2 -std=c90 -pedantic try.c -o try
>
> $ ./try
> make: 'try' is up to date.
>

This on the other hand looks EXACTLY like a solution looking a problem.

BTW that 'make' only works on my machine because it happens to be part
of mingw; none of my other C compilers have make.

And as written, it only works for 'cc' which comes with 'gcc'. If I use
CC to set another compiler, then the -o option is wrong for tcc. The
other options are not recognised with two other compilers.

Look at the follow-up to my OP that I will shortly post.

On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor wrote:

> $ make -j

The last time I tried that on an FFmpeg build, it brought my machine to
its knees. ;)

On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:

> On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
>
>> Nicolas George <nicolas$george@salle-s.org> writes:
>>
>>>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
>>>> return(system("make -j 16"));
>>>
>>>The return value of system() is not in the same format as the return
>>>value of main().
>>
>> Regardless, it suffices for a "success/failure" indication.
>
> Mostly. The only exception looks to be very rare: if no shell is
> available, then system() returns 0.

Why does this need to go through a shell?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
>
>> On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
>>
>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>
>>>>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
>>>>> return(system("make -j 16"));
>>>>
>>>>The return value of system() is not in the same format as the return
>>>>value of main().
>>>
>>> Regardless, it suffices for a "success/failure" indication.
>>
>> Mostly. The only exception looks to be very rare: if no shell is
>> available, then system() returns 0.
>
>Why does this need to go through a shell?

Something needs to parse and execute the command line.

$ man 3 system

Lawrence D'Oliveiro , dans le message <upeddh$1mjib$2@dont-email.me>, a
écrit :
> The last time I tried that on an FFmpeg build, it brought my machine to
> its knees. ;)

But at least, with FFmpeg's build system, parallel build works.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
>> On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
>>>>> return(system("make -j 16"));
>>>>
>>>>The return value of system() is not in the same format as the return
>>>>value of main().
>>>
>>> Regardless, it suffices for a "success/failure" indication.
>>
>> Mostly. The only exception looks to be very rare: if no shell is
>> available, then system() returns 0.
>
> Why does this need to go through a shell?

Since this is comp.unix.programmer, POSIX specifies that system()
invokes the "sh" utility as if by calling fork() and exec().

In comp.lang.c, I'd say that system() determines whether the host system
has a *command processor*, and if so passes the string pointed to by its
argument to that command processor (i.e., shell).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lew Pitcher , dans le message <upe6kk$1ikg6$1@dont-email.me>, a écrit :
> Mostly. The only exception looks to be very rare

Only exception?

Upon normal completion, system() returns the exit code of the child process
shifted left by 8 bits.

Only the 7 or 8 lower bits of the return value of main() end up in the exit
code of the process.

The lower 8 bits of something shifted 8 bits to the left: do the math.

On Wed, 31 Jan 2024 21:46:34 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
>>
>>> On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
>>>
>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>
>>>>>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
>>>>>> return(system("make -j 16"));
>>
>>Why does this need to go through a shell?
>
> Something needs to parse and execute the command line.

There is no need to “parse” any command line.

<manpages.debian.org/3/exec.3.en.html>

On 31 Jan 2024 22:28:45 GMT, Nicolas George wrote:

> Lawrence D'Oliveiro , dans le message <upeddh$1mjib$2@dont-email.me>, a
> écrit :
>>
>> On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor wrote:
>>
>>> $ make -j
>>
>> The last time I tried that on an FFmpeg build, it brought my machine to
>> its knees. ;)
>
> But at least, with FFmpeg's build system, parallel build works.

I still feel that the “-j” option is a bit dangerous: the fact that you
can specify it with an argument or without means it is too easy to tell it
to use unlimited numbers of processes.

Tip: I often use

make -j$(nproc)

though I’m told you may want to add 1 to this.

On Thu, 01 Feb 2024 00:25:53 +0000, Lawrence D'Oliveiro wrote:

> On Wed, 31 Jan 2024 21:46:34 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
>>>
>>>> On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
>>>>
>>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>>
>>>>>>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
>>>>>>> return(system("make -j 16"));
>>>
>>>Why does this need to go through a shell?
>>
>> Something needs to parse and execute the command line.
>
> There is no need to “parse” any command line.
>
> <manpages.debian.org/3/exec.3.en.html>

Lawrence, you will note that, in the original call
return(system("make -j 16"));
the argument to system() is a single string.

The equivalent exec() call takes a larger number of
arguments, including
a) the path to the program to be executed (in this case
something like "/usr/bin/make")
b) an array (or, for some of the exec() family, a list)
of pointers to strings representing each of the
arguments given to the program to be executed.
In this case, something like "make", "-j", "16", NULL
c) in some of the exec family, an array of environment
variable strings.

Do you see any of those /individual/ strings in the OP's
given argument to system()? I don't.

Yes, the OP /could/ have coded a fork/exec/wait codepath
and "hand parsed" the commandline, /BUT/ the OP instead
chose to use a handy utility function that does all that
for the cost of invoking a shell to parse out and build
the arguments to exec().

Dude. Get a handle on it. You don't have to be so argumentative
about a simple choice like that. No one is saying that
system() is the only way to go in a case like this, and
you seem to be over-reacting to this simple piece of code.
--
Lew Pitcher
"In Skills We Trust"

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On 31 Jan 2024 22:28:45 GMT, Nicolas George wrote:
>
>> Lawrence D'Oliveiro , dans le message <upeddh$1mjib$2@dont-email.me>, a
>> écrit :
>>>
>>> On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor wrote:
>>>
>>>> $ make -j
>>>
>>> The last time I tried that on an FFmpeg build, it brought my machine to
>>> its knees. ;)
>>
>> But at least, with FFmpeg's build system, parallel build works.
>
>I still feel that the “-j” option is a bit dangerous: the fact that you
>can specify it with an argument or without means it is too easy to tell it
>to use unlimited numbers of processes.
>
>Tip: I often use
>
> make -j$(nproc)
>
>though I’m told you may want to add 1 to this.

I use $(( 2 * nproc )) for builds, which are often iobound.

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>On Thu, 01 Feb 2024 00:25:53 +0000, Lawrence D'Oliveiro wrote:
>
>> On Wed, 31 Jan 2024 21:46:34 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
>>>>
>>>>> On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
>>>>>
>>>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>>>
>>>>>>>vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
>>>>>>>> return(system("make -j 16"));
>>>>
>>>>Why does this need to go through a shell?
>>>
>>> Something needs to parse and execute the command line.
>>
>> There is no need to “parse” any command line.
>>
>> <manpages.debian.org/3/exec.3.en.html>
>
>Lawrence, you will note that, in the original call
> return(system("make -j 16"));
>the argument to system() is a single string.
>
>The equivalent exec() call takes a larger number of
>arguments, including
>a) the path to the program to be executed (in this case
> something like "/usr/bin/make")
>b) an array (or, for some of the exec() family, a list)
> of pointers to strings representing each of the
> arguments given to the program to be executed.
> In this case, something like "make", "-j", "16", NULL
>c) in some of the exec family, an array of environment
> variable strings.
>
>Do you see any of those /individual/ strings in the OP's
>given argument to system()? I don't.
>
>Yes, the OP /could/ have coded a fork/exec/wait codepath
>and "hand parsed" the commandline, /BUT/ the OP instead
>chose to use a handy utility function that does all that
>for the cost of invoking a shell to parse out and build
>the arguments to exec().
>
>
>Dude. Get a handle on it. You don't have to be so argumentative
>about a simple choice like that. No one is saying that
>system() is the only way to go in a case like this, and
>you seem to be over-reacting to this simple piece of code.

Not to mention that
1) there are no html versions of the man pages installed.
2) even if there were, it's still a markup language that needs processing to be useful.
3) not everyone has an internet connection or wants to leave the terminal session to view a man
page. In fact most of the machines we run on are not connected to the internet at all
and the manpages for our application won't be on the internet anyway.

On Thu, 1 Feb 2024 00:54:33 -0000 (UTC), Lew Pitcher wrote:

> Lawrence, you will note that, in the original call
> return(system("make -j 16"));
> the argument to system() is a single string.

Which is completely unnecessary.

> The equivalent exec() call takes a larger number of
> arguments, including ...

And is safer to use.

People need to stop requiring the interposition of a shell to invoke
commands, unless there really is a need for it.

On 31 Jan 2024 23:24:07 GMT, Nicolas George <nicolas$george@salle-s.org>
wrote in <65bad697$0$3250$426a74cc@news.free.fr>:

> Lew Pitcher , dans le message <upe6kk$1ikg6$1@dont-email.me>, a écrit :
>> Mostly. The only exception looks to be very rare
>
> Only exception?
>
> Upon normal completion, system() returns the exit code of the child process
> shifted left by 8 bits.
>
> Only the 7 or 8 lower bits of the return value of main() end up in the exit
> code of the process.
>
> The lower 8 bits of something shifted 8 bits to the left: do the math.

That's not what my man page says:

* If all system calls succeed, then the return value is
the termination status of the child shell used to ex‐
ecute command. (The termination status of a shell is
the termination status of the last command it exe‐
cutes.)
[...]
CONFORMING TO
POSIX.1-2001, POSIX.1-2008, C89, C99.
[...]

But it wasn't a serious program anyway, it was a silly little program whose
sole job was to make itself.

Why? Because Bart posted a "C" source file that used nothing
but his own pragmas to build a project.

(Hey: if he want's to re-invent the wheel, it shouldn't start
off square...)

Oh, and sidenote: I "researched" (asked ChatGPT) about
make(1) being POSIX, and it says it isn't. However,
make(1) IS part of the SUS.

--
-Scott

On Thu, 1 Feb 2024 04:55:24 -0000 (UTC), vallor wrote:

> Oh, and sidenote: I "researched" (asked ChatGPT) about make(1) being
> POSIX, and it says it isn't.

POSIX Issue 7
<http://www.open-std.org/jtc1/sc22/open/n4217.pdf>, page 2830 onwards.

On Thu, 1 Feb 2024 05:44:47 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <upfb4f$1uid8$1@dont-email.me>:

> On Thu, 1 Feb 2024 04:55:24 -0000 (UTC), vallor wrote:
>
>> Oh, and sidenote: I "researched" (asked ChatGPT) about make(1) being
>> POSIX, and it says it isn't.
>
> POSIX Issue 7
> <http://www.open-std.org/jtc1/sc22/open/n4217.pdf>, page 2830 onwards.

Well, I stand corrected!

That's not the first time that Beast has been wrong. I think maybe
it makes it up as it goes along...

And thank you for the pointer. :)

--
-v

vallor , dans le message <upf87s$1tvq1$1@dont-email.me>, a écrit :
> That's not what my man page says:
>
> * If all system calls succeed, then the return value is
> the termination status of the child shell used to ex‐
> ecute command. (The termination status of a shell is
> the termination status of the last command it exe‐
> cutes.)

That IS what the man page says, you just read it wrong. Thankfully, Single
Unix decided to avoid the pitfall by making it more explicit:

“If command is not a null pointer, system() shall return the termination
status of the command language interpreter in the format specified by
waitpid().”

But you did not have to rely on badly worded sentences in English, you could
have just tested for yourself. You should have tested for yourself.

> Oh, and sidenote: I "researched" (asked ChatGPT) about

Asking ChatGPT about technical matters is a sure way of wasting your time
and ours.

On 31/01/2024 21:25, bart wrote:
> On 31/01/2024 16:41, vallor wrote:
>> On Tue, 30 Jan 2024 19:22:00 +0000, Richard Harnden
>> <richard.nospam@gmail.invalid> wrote in <upbi8o$14443$1@dont-email.me>:
>>
>>> On 30/01/2024 16:50, Malcolm McLean wrote:
>>>>
>>>> But I'm wondering about one file which contains all the sources for the
>>>> program. Like an IDE project file but lighter weight.
>>>>
>>>>
>>> In other words: a Makefile
>>
>> Agreed; it's a solution looking for a problem.
>
> Why do you think languages come with modules? That allows them to
> discover their own modules, rather than rely on external apps where the
> details are buried under appalling syntax and mixed up with a hundred
> other matters.
>

No, that is not at all the purpose of modules in programming. Note that
there is no specific meaning of "module", and different languages use
different for similar concepts. There are many features that a
language's "module" system might have - some have all, some have few:

1. It lets you split the program into separate parts - generally
separate files. This is essential for scalability for large programs.

2. You can compile modules independently to allow partial builds.

3. Modules generally have some way to specify exported symbols and
facilities that can be used by other modules.

4. Modules can "import" other modules, gaining access to those modules'
exported symbols.

5. Modules provide encapsulation of data, code and namespaces.

6. Modules can be used in a hierarchical system, building big modules
from smaller ones to support larger libraries with many files.

7. Modules provide a higher level concept that can be used by language
tools to see how the whole program fits together or interact with
package managers and librarian tools.

C provides 1, 2, 3, and 4 if you use a "file.c/file.h" organisation. It
provides a limited form of 5 (everything that is not exported is
"static"), but scaling to larger systems is dependent on identifier
prefixes.

You seem to be thinking purely about item 7 above. This is, I think,
common in interpreted languages (where modules have to be found at
run-time, where the user is there but the developer is not). Compiled
languages don't usually have such a thing, because developers (as
distinct from users) have build tools available that do a better job.

On 31/01/2024 22:17, Lawrence D'Oliveiro wrote:
> On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor wrote:
>
>> $ make -j
>
> The last time I tried that on an FFmpeg build, it brought my machine to
> its knees. ;)

Sometimes "make -j" can be a bit enthusiastic about the number of
processes it starts. If there are many operations it /could/ do, trying
to run them all can chew through a lot more memory than you'd like. I
usually use something like "make -j 8", though the ideal number of
parallel tasks depends on the number of cpu cores you have, their type
(SMT threads or real cores, "big" cores or "little" cores), memory,
speed of disks, additional tools like ccache or distcc, etc.

I'd rather "make -j" (without a number) defaulted to using the number of
cpu cores, as that is a reasonable guess for most compilations.

On 01/02/2024 08:39, David Brown wrote:
> On 31/01/2024 21:25, bart wrote:
>> On 31/01/2024 16:41, vallor wrote:
>>> On Tue, 30 Jan 2024 19:22:00 +0000, Richard Harnden
>>> <richard.nospam@gmail.invalid> wrote in <upbi8o$14443$1@dont-email.me>:
>>>
>>>> On 30/01/2024 16:50, Malcolm McLean wrote:
>>>>>
>>>>> But I'm wondering about one file which contains all the sources for
>>>>> the
>>>>> program. Like an IDE project file but lighter weight.
>>>>>
>>>>>
>>>> In other words: a Makefile
>>>
>>> Agreed; it's a solution looking for a problem.
>>
>> Why do you think languages come with modules? That allows them to
>> discover their own modules, rather than rely on external apps where
>> the details are buried under appalling syntax and mixed up with a
>> hundred other matters.
>>
>
> No, that is not at all the purpose of modules in programming.  Note that
> there is no specific meaning of "module", and different languages use
> different for similar concepts.  There are many features that a
> language's "module" system might have - some have all, some have few:
>
> 1. It lets you split the program into separate parts - generally
> separate files.  This is essential for scalability for large programs.
>
> 2. You can compile modules independently to allow partial builds.
>
> 3. Modules generally have some way to specify exported symbols and
> facilities that can be used by other modules.
>
> 4. Modules can "import" other modules, gaining access to those modules'
> exported symbols.
>
> 5. Modules provide encapsulation of data, code and namespaces.
>
> 6. Modules can be used in a hierarchical system, building big modules
> from smaller ones to support larger libraries with many files.
>
> 7. Modules provide a higher level concept that can be used by language
> tools to see how the whole program fits together or interact with
> package managers and librarian tools.
>
>
> C provides 1, 2, 3, and 4 if you use a "file.c/file.h" organisation.  It
> provides a limited form of 5 (everything that is not exported is
> "static"), but scaling to larger systems is dependent on identifier
> prefixes.
>
> You seem to be thinking purely about item 7 above.  This is, I think,
> common in interpreted languages (where modules have to be found at
> run-time, where the user is there but the developer is not).
I've been implementing languages with language-supported modules for
about 12 years.

They generally provide 1, 2, 4, 5, and 7 from your list, and partial
support of 6.

They don't provide 2 (compiling individual modules) because the aim is a
very fast, whole-program compler.

While for 6, there is only a hierarchy between groups of modules, each
forming an independent sub-program or library. I tried a strict full
per-module hierarchy early on, mixed up with independent compilation; it
worked poorly.

The two levels allow you to assemble one binary out of groups of modules
that each represent an independent component or library.

> Compiled
> languages don't usually have such a thing, because developers (as
> distinct from users) have build tools available that do a better job.

Given a module scheme, the tool needed to build a whole program should
not need to be told about the names and location of every constituent
module; it should be able to determine that from what's already in the
source code, given only a start point.

Even with independent compilation, you might be able to use that info to
determine dependencies, but you will need that module hierarchy if you
want to compile individual modules.

My view is that that tool only needs to be the compiler (a program that
does the 'full stack' from source files to executable binary) working
purely from the source code.

Yours is to have compilers, assemblers, linkers and make programs,
working with auxiliary data in makefiles, that itself have to be
generated by extra tools or special options, or built by hand.

I see that as old-fashioned and error-prone. Also complex and limited
(eg. they will not support my compiler.)

The experiment in my OP is intended to bring part of my module scheme to C.

However, that will of course be poorly received. Why? Because when a
language doesn't provide a certain feature (eg. module management), then
people are free to do all sorts of wild and whacky things to achieve
some result.

Approaches that don't fit in to the disciplined requirements of a
language-stipulated module scheme.

A good example is the header-based module scheme of my BCC compiler;
this required modules to be implemented as tidy .h/.c pairs of files. Of
course, real C code is totally chaotic in its use of headers.

In other words, you can're retro-fit a real module-scheme to C, not one
that will work with existing code.

But for all my projects and all the ones /I/ want to build, they do come
down to just knowing what source files need to be submitted to the
compiler. It really can be that simple. That CAN be trivially
retro-fitted to existing projects.