On Thu, 1 Feb 2024 23:09:48 +0100, David Brown wrote:

> "nmake" is MS's version of "make" ...

I think they did originally have a tool called “make”. But this was so
crap in comparison to the GNU/POSIX equivalent that they changed the name
in the new version to try to distance themselves from the bad taste the
old version left in people’s mouths.

On Thu, 01 Feb 2024 15:24:00 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> nproc(1) is part of the GNU Core Utilities
>> <manpages.debian.org/1/nproc.1.html>.
>
> And GNU make is not, so it's possible that a system might have make but
> not nproc.

While that is theoretically possible, I somehow think such an installation
would feel to the typical *nix user somewhat ... crippled.

Particularly since the “install” command is part of coreutils.

Also imagine trying to do builds, or any kind of development, on a system
without the “mkdir” command--another component of coreutils.

On Thu, 01 Feb 2024 15:00:03 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>On Thu, 01 Feb 2024 00:29:23 GMT, Scott Lurndal wrote:
>>
>>> How would you display an manpage using nroff markup from an
>>> application?
>>
>>Much safer:
>>
>>subprocess.run \
>> (
>> args = ("man", os.path.expandvars("${INSTALL_LOC}/man/topic.man"))
>> )
>
> You are aware you are posting to comp.lang.c, right?

Yes. Nevertheless, this is the clearest and most concise (read: least work
involved for me) way of explaining what I mean; I will leave it to the C
experts to translate it into their preferred lower-level way of doing
things.

On 2024-02-01, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 01 Feb 2024 15:24:00 -0800, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> nproc(1) is part of the GNU Core Utilities
>>> <manpages.debian.org/1/nproc.1.html>.
>>
>> And GNU make is not, so it's possible that a system might have make but
>> not nproc.
>
> While that is theoretically possible, I somehow think such an installation
> would feel to the typical *nix user somewhat ... crippled.

Selected GNU programs can be individually installed on Unix-like systems
which already have other tools of their own.

> Particularly since the “install” command is part of coreutils.

The install utility appeared in 4.2 BSD, which was released in
August 1983.

The GNU Project was announced in September 1983.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 01/02/2024 21:34, David Brown wrote:
>
>> It works for me, and I'm sure could work for others if they didn't
>> have makefiles forced down their throats and hardwired into their brains.
>
> /Nobody/ has makefiles forced on them.  People use "make" because it is
> convenient, and it works.  If something better comes along, and it is
> better enough to overcome the familiarity momentum, people will use that.
>
What?
You have total control of your programming environment and never have to
consider anybody else? For hobby programming you do in a way. Not if you
want other people to use your stuff. But can always say that fun of
doing things exactly your way outweighs the fun of getting downloads.

But for professional or academic programming, often you'll find you have
to use make. You don't have a choice. Either someone else took the
decision, or there are so many other people who expect that build shall
be via make that you have no real alternative.

Now in one study, someone had wanted to do a survey of genetic sequence
analysis software. They reported no results for half the programs,
because they had attempted to build them, and failed. They didn't say,
but it's a fair bet that most of those build systems used make. The
software distribution system is a disaster and badly needs fixing.

But there are lots of caveats. Bart's system might be better, but it as
you say it needs traction. I'd be reluctant to evangelise for it and get
everyone to use it at work, because it might prove to have major
drawbacks, and then I'd get the blame. Which I wouldn't if I wrote a
makefile which broke. Not in the same way. And of course one person
can't rigorously test and debug, and buid an ecosystem of ancilliary
tools, dcumentation, resoruces, help meesage boards. However a lot of
things start small, with one lone programmer beavering away in his
bedroom. It's necessary to look at the positives, and not strangle
things at birth.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 02/02/2024 00:26, Malcolm McLean wrote:
> On 01/02/2024 21:34, David Brown wrote:
>>
>>> It works for me, and I'm sure could work for others if they didn't
>>> have makefiles forced down their throats and hardwired into their
>>> brains.
>>
>> /Nobody/ has makefiles forced on them.  People use "make" because it
>> is convenient, and it works.  If something better comes along, and it
>> is better enough to overcome the familiarity momentum, people will use
>> that.
>>
> What?
> You have total control of your programming environment and never have to
> consider anybody else? For hobby programming you do in a way. Not if you
> want other people to use your stuff. But can always say that fun of
> doing things exactly your way outweighs the fun of getting downloads.
>
> But for professional or academic programming, often you'll find you have
> to use make. You don't have a choice. Either someone else took the
> decision, or there are so many other people who expect that build shall
> be via make that you have no real alternative.
>
> Now in one study, someone had wanted to do a survey of genetic sequence
> analysis software. They reported no results for half the programs,
> because they had attempted to build them, and failed. They didn't say,
> but it's a fair bet that most of those build systems used make. The
> software distribution system is a disaster and badly needs fixing.
>
> But there are lots of caveats. Bart's system might be better, but it as
> you say it needs traction. I'd be reluctant to evangelise for it and get
> everyone to use it at work, because it might prove to have major
> drawbacks, and then I'd get the blame.

There's a lite, flexible version of it, which doesn't interfere with any
existing uses of 'make'.

That is to also provide a simple list the C files somewhere, in a
comment, or text files. Plus any other notes needed to build the project
(written in English or Norwegian, I don't care; Norwegian will be decode
to understand than a typical makefile).

This is exactly what you did with the resource compiler, specifying the
three lots of *.c files needed to build it; no makefiles or CMake needed
(which failed if you remember).

On 01.02.2024 22:34, David Brown wrote:
>
> I've nothing against shorter or simpler makefiles. [...]

During mid/late 1990's someone at our site looked for an alternative
to Make. After some evaluation of tools it was decided to not replace
Make. I've just googled for what at that time appeared to be the most
promising candidate (it's obviously still there) and the description
of Jam reads as it would fulfill some of the requirements that have
been mentioned by various people here (see https://freetype.org/jam/
for details).

Janis

On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:

> The C standard doesn't specify file
> extensions, either for source files or for files included with #include.

It does for the standard library includes, though.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:
>> The C standard doesn't specify file
>> extensions, either for source files or for files included with #include.
>
> It does for the standard library includes, though.

Strictly speaking, it doesn't specify that the standard library headers
are files. But yes, their names end in ".h", and that's certainly
because of the common convention to use ".h" as the extension for C
header files.

--
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 */

Michael S <already5chosen@yahoo.com> writes:
>On Thu, 1 Feb 2024 22:38:13 +0100
>David Brown <david.brown@hesbynett.no> wrote:
>

>> > And then to proceed with automatiion of his pre and post-processing
>> > needs.
>>
>> But then I'd still be using "make", and Bart would not be happy.
>>
>> And "gcc -MD" does not need any extra #pragmas, so presumably neither
>> would an implementation of that feature in bcc (or mcc or whatever).
>> So Bart's new system would disappear entirely.
>>
>>
>>
>
>Bart spares you from managing list(s) of objects in your makefile and
>from writing arcan helper macros.
>Yes, I know, you copy&past arcan macros from project to project, but
>you had to write them n years ago and that surely was not easy.

"Not easy for you" doesn't automatically translate to "not easy for
everyone else".

Difficult is the configuration file for sendmail processed by m4.

Make is easy.

On 2/1/24 23:29, bart wrote:
> I do. You type:
>
>    cc prog
>
> without knowing or caring whether the contains that one module, or there
> are 99 more.
>

I also do. You type:

make prog

without knowing or caring whether the contains that one module, or
there are 51 more.

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

On Thu, 01 Feb 2024 17:42:32 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:
>>
>>> The C standard doesn't specify file extensions, either for source
>>> files or for files included with #include.
>>
>> It does for the standard library includes, though.
>
> Strictly speaking, it doesn't specify that the standard library headers
> are files.

From the C99 spec, page 149:

6.10.2 Source file inclusion
Constraints
A #include directive shall identify a header or source file that
can be processed by the implementation.

...

3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of
the source file identified by the specified sequence between the "
delimiters. The named source file is searched for in an
implementation-defined manner.

So you see, the spec very explicitly uses the term “file”.

<https://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/>

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 17:42:32 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:
>>>> The C standard doesn't specify file extensions, either for source
>>>> files or for files included with #include.
>>>
>>> It does for the standard library includes, though.
>>
>> Strictly speaking, it doesn't specify that the standard library headers
>> are files.
>
> From the C99 spec, page 149:
>
> 6.10.2 Source file inclusion
> Constraints
> A #include directive shall identify a header or source file that
> can be processed by the implementation.
>
> ...
>
> 3 A preprocessing directive of the form
> # include "q-char-sequence" new-line
> causes the replacement of that directive by the entire contents of
> the source file identified by the specified sequence between the "
> delimiters. The named source file is searched for in an
> implementation-defined manner.
>
> So you see, the spec very explicitly uses the term “file”.
>
> <https://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/>

Yes, but not in reference to the standard headers.

A #include directive with <> searches for a "header", which is not
stated to be a file. A #include directive with "" searches for a file
in an implementation-defined manner; if that search fails, it tries
again as if <> had been used.

References to standard headers (stdio.h et al) always use the <> syntax.
You can write `#include "stdio.h"` if you like, but it risks picking up
a file with the same name instead of the standard header (which *might*
be what you want).

BTW, the n1256.pdf draft is a close approximation to the C99 standard;
it consists of the published standard with the three Technical
Corrigenda merged into it. The n1570.pdf draft is the last publicly
release draft before C11 was published, and is close enough to C11 for
most purposes.

--
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 */

On 01/02/2024 23:55, Michael S wrote:
> On Thu, 1 Feb 2024 22:38:13 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 01/02/2024 21:23, Michael S wrote:
>>> On Thu, 1 Feb 2024 18:34:08 +0000
>>

>>>
>>> You proposal and needs of David Brown are not necessarily
>>> contradictory.
>>> All you need to do to satisfy him is to add to your compiler an
>>> option for export of dependencies in make-compatible format, i.e.
>>> something very similar to -MD option of gcc.
>>>
>>> Then David could write in his makefile:
>>>
>>> out/foo.elf : main_foo.c
>>> mcc -MD $< -o $@
>>>
>>> -include out/foo.d
>>>
>>> And then to proceed with automatiion of his pre and post-processing
>>> needs.
>>
>> But then I'd still be using "make", and Bart would not be happy.
>>
>> And "gcc -MD" does not need any extra #pragmas, so presumably neither
>> would an implementation of that feature in bcc (or mcc or whatever).
>> So Bart's new system would disappear entirely.
>>
>>
>>
>
> Bart spares you from managing list(s) of objects in your makefile and
> from writing arcan helper macros.
> Yes, I know, you copy&past arcan macros from project to project, but
> you had to write them n years ago and that surely was not easy.
>

Google "makefile automatic dependencies", then adapt to suit your own
needs. Re-use the same makefile time and again.

Yes, some of the functions I have in my makefiles are a bit hairy, and
some of the command line options for gcc are a bit complicated. They
are done now.

If there had been an easier way than this, which still let me do what I
need (Bart's system does not), which is popular enough that you can
easily google for examples, blogs, and tutorials, then I'd have been
happy to use that at the time. I won't change to something else unless
it gives me significant additional benefits.

People smarter and more experienced than Bart have been trying to invent
better replacements for "make" for many decades. None have succeeded.
Some build systems are better in some ways, but nothing has come close
to covering the wide range of features and uses of make, or gaining hold
outside a particular niche. Everyone who has ever made serious use of
"make" knows it has many flaws, unnecessarily complications, limitations
and inefficiencies. Despite that, it is the best we have.

With Bart's limited knowledge and experience, and deeply ingrained
prejudices and misunderstandings, the best we can hope for is something
that works well enough for some simple cases of C programs. More
realistically, it will work for Bart's use alone.

And that, of course, is absolutely fine. No one is paying Bart to write
a generic build system, or something of use to anyone else. He is free
to write exactly what he wants, in the way he wants, and if ends up with
a tool that he finds useful himself, that is great. If he ends up with
something that at least some other people find useful, that is even
better, and I wish him luck with his work.

But don't hold your breath waiting for something that will replace make,
or attract users of any other build system.

On 01/02/2024 23:29, bart wrote:
> On 01/02/2024 21:34, David Brown wrote:
>> On 01/02/2024 19:34, bart wrote:
>
>>> You don't see that the language taking over task (1) of the things
>>> that makefiles do, and possibly (2) (of the list I posted; repeated
>>> below), can streamline makefiles to make them shorter, simpler,
>>> easier to write and to read, and with fewer opportunities to get
>>> stuff wrong?
>>>
>>> That was a rhetorical question. Obviously not.
>>
>> I've nothing against shorter or simpler makefiles.  But as far as I
>> can see, you are just moving the same information from a makefile into
>> the C files.
>>
>> Indeed, you are duplicating things - now your C files have to have
>> "#pragma module this, #pragma module that" in addition to having
>> "#include this.h, #include that.h".  With my makefiles, all the "this"
>> and "that" is found automatically - writing the includes in the C code
>> is sufficient.
>
> I don't think so. Seeing:
>
>     #include "file.h"
>
> doesn't necessarily mean there is a matching "file.c". It might not
> exist, or the header might be for some external library, or maybe it
> does exist but in a different location.

As I said, you are duplicating things.

For my builds, I do not have anywhere that I need to specify "file.c".

>
> Or maybe some code may use a file "fred.c", which needs to be submitted
> to the compiler, but for which there is either no header used, or uses a
> header file with a different name.
>
> As I said, C's uses of .h and .c files are chaotic.

My uses of .h and .c files are not chaotic.

Maybe you can't write well-structured C programs. Certainly not
everyone can. (And /please/ do not give another list of open source
programs that you don't like. I didn't write them. I can tell you how
and why /I/ organise my projects and makefiles - I don't speak for others.)

>
> Did you have in mind using gcc's -MM option? For my 'cipher.c' demo,
> that only gives a set of header names.  Missing are hmac.c and sha2.c.
>

I use makefiles where gcc's "-M" options are part of the solution - not
the whole solution.

> If I try it on lua.c, it gives me only 5 header files; the project
> comprises 33 .c files and 27 .h files.
>

I don't care. I did not write lua.

But I /have/ integrated lua with one of my projects, long ago. It fit
into my makefile format without trouble - I added the lua directory as a
subdirectory of my source directory, and that was all that was needed.

>>>
>>>
>>>> Perhaps I would find your tools worked for a "Hello, world" project.
>>>> Maybe they were still okay as it got slightly bigger.  Then I'd have
>>>> something that they could not handle, and I'd reach for make.  What
>>>> would be the point of using "make" to automate - for example -
>>>> post-processing of a binary to add a CRC check, but using your tools
>>>> to handle the build?  It's much easier just to use "make" for the
>>>> whole thing.
>>>
>>>
>>> Because building one binary is a process should be the job of a
>>> compiler, not some random external tool that knows nothing of the
>>> language or compiler.
>>
>> No, it is the job of the linker.
>
> There is where you're still stuck in the past.
>
> I first got rid of a formal 'linker' about 40 years ago. I got rid of
> the notion of combining independently compiled modules into an
> executable a decade ago.

No, you built a monolithic tool that /included/ the linker. That's fine
for niche tools that are not intended to work with anything else. Most
people work with many tools - that's why we have standards, defined file
formats, and flexible tools with wide support.

Other people got rid of monolithic tools forty years ago when they
realised it was a terrible way to organise things.

>
> But I suspect you don't understand what a 'whole-program compiler' does:
>

I know exactly what it does. I am entirely without doubt that I know
the point and advantages of them better than you do - the /real/ points
and advantages, not some pathetic "it means I don't have to use that
horrible nasty make program" reason.

> * It means that for each binary, all sources are recompiled at the same
>   time to create it

No, it does not.

>
> * It doesn't mean that an application can only comprise one binary

Correct.

>
> * It moves the compilation unit granularity from a module to a single
>   EXE or DLL file

No, it does not.

>
> * Interfaces (in the case of a lower level language), are moved inter-
>   module to inter-program. The boundaries are between one program or
>   library and another, not between modules.

Correct.

>
> A language which claims to have a module system, but still compiles a
> module at a time, will probably still have discrete inter-module
> interfaces, although they may be handled automatically.
>

Correct.

In real-world whole program compilation systems, the focus is on
inter-module optimisations. Total build times are expected to go /up/.
Build complexity can be much higher, especially for large programs. It
is more often used for C++ than C.

The main point of a lot of whole-program compilation is to allow
cross-module optimisation. It means you can have "access" functions
hidden away in implementation files so that you avoid global variables
or inter-dependencies between modules, but now they can be inline across
modules so that you have no overhead or costs for this. It means you
can write code that is more structured and modular, with different teams
handling different parts, and with layers of abstractions, but when you
pull it all together into one whole-program build, the run-time costs
and overhead for this all disappear. And it means lots of checks and
static analysis can be done across the whole program.

For such programs, each translation unit is still compiled separately,
but the "object" files contain internal data structures and analysis
information, rather than generated code. Lots of the work is done by
this point, with inter-procedural optimisations done within the unit.
These compilations will be done as needed, in parallel, under the
control of a build system. Then they are combined for the linking and
link-time optimisation which fits the parts together. Doing this in a
scalable way is hard, and the subject of a lot of research, as you need
to partition it into chunks that can be handled in parallel on multiple
cpu cores (or even distributed amongst servers). Once you have parts of
code that are ready, they are handed on to backend compilers that do
more optimisation and generate the object code, and this in turn is
linked (sometimes incrementally in parts, again aiming at improving
parallel building and scalability.

You go to all this effort because you are building software that is used
by millions of people, and your build effort is minor compared to the
total improvements for all users combined. Or you do it because you are
building speed-critical software. Or you want the best static analysis
you can get, and want that done across modules. Or you are building
embedded systems that need to be as efficient as possible.

You don't do it because you find "make" ugly.

It is also very useful on old-fashioned microcontrollers with multiple
banks for data ram and code memory, and no good data stack access - the
compiler can do large-scale lifetime analysis and optimise placement and
the re-use of the very limited ram.

>
>> /Nobody/ has makefiles forced on them.  People use "make" because it
>> is convenient, and it works.
>
> BUT IT DOESN'T.

IT DOES WORK.

People use it all the time.

> It fails a lot of the time on Windows, but they are too
> complicated to figure out why.

People use it all the time on Windows.

Even Microsoft ships its own version of make, "nmake.exe", and has done
for decades.

/You/ can't work it, but you excel at failing to get things working.
You have a special gift - you just have to look at a computer with tools
that you didn't write yourself, and it collapses.

>
>> But I have no interest in changing to something vastly more limited
>> and which adds nothing at all.
>
> That's right; it adds nothing, but it takes a lot away! Like a lot of
> failure points.

Like pretty much everything I need.

On 02/02/2024 04:03, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Thu, 01 Feb 2024 17:42:32 -0800, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:
>>>>> The C standard doesn't specify file extensions, either for source
>>>>> files or for files included with #include.
>>>>
>>>> It does for the standard library includes, though.
>>>
>>> Strictly speaking, it doesn't specify that the standard library headers
>>> are files.
>>
>> From the C99 spec, page 149:
>>
>> 6.10.2 Source file inclusion
>> Constraints
>> A #include directive shall identify a header or source file that
>> can be processed by the implementation.
>>
>> ...
>>
>> 3 A preprocessing directive of the form
>> # include "q-char-sequence" new-line
>> causes the replacement of that directive by the entire contents of
>> the source file identified by the specified sequence between the "
>> delimiters. The named source file is searched for in an
>> implementation-defined manner.
>>
>> So you see, the spec very explicitly uses the term “file”.
>>
>> <https://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/>
>
> Yes, but not in reference to the standard headers.
>
> A #include directive with <> searches for a "header", which is not
> stated to be a file. A #include directive with "" searches for a file
> in an implementation-defined manner; if that search fails, it tries
> again as if <> had been used.
>
> References to standard headers (stdio.h et al) always use the <> syntax.
> You can write `#include "stdio.h"` if you like, but it risks picking up
> a file with the same name instead of the standard header (which *might*
> be what you want).
>
> BTW, the n1256.pdf draft is a close approximation to the C99 standard;
> it consists of the published standard with the three Technical
> Corrigenda merged into it. The n1570.pdf draft is the last publicly
> release draft before C11 was published, and is close enough to C11 for
> most purposes.
>

In 7.1.2 "Standard headers", it says:

"""
Each library function is declared, with a type that includes a
prototype, in a header, 188) whose contents are made available by the
#include preprocessing directive.
"""

"Header" here is in italics, meaning it is a definition of the term.
And footnote 188 has :

"""
header is not necessarily a source file, nor are the < and > delimited
sequences in header names necessarily valid source file names.
"""

(I am quoting from n2346, the final C18 draft. The section numbering is
generally consistent between standard versions, but footnote numbers
change, in case anyone is looking this up.)

I have personally used a toolchain where the standard library headers
did not exist as files, but were internal to the compiler (and the
implementations were internal to the linker). I think the toolchain
company was a bit paranoid that others would copy their proprietary library.

On 02/02/2024 00:30, Lawrence D'Oliveiro wrote:
> On Thu, 1 Feb 2024 22:34:36 +0100, David Brown wrote:
>
>> I am, however, considering CMake (which works at a
>> higher level, and outputs makefiles, ninja files or other project
>> files).
>
> Ninja was created as an alternative to Make.

It is an alternative to some uses of make - but by no means all uses.

> Basically, if your Makefiles
> are going to be generated by a meta-build system like CMake or Meson, then
> they don’t need to support the kinds of niceties that facilitate writing
> them by hand. So you strip it write down to the bare-bones functionality,
> which makes your builds fast while consuming minimal resources, and that
> is Ninja.

Yes.

It is not normal to write ninja files by hand - the syntax is relatively
simple, but quite limited. So it covers the lower level bits of "make",
but not the higher level bits.

Perhaps ninja is the tool that Bart is looking for? For the kinds of
things he is doing, I don't think it would be hard to write the ninja
files by hand.

So it won't work for my needs, as I want to work at a higher level
(without manually detailing file lists and dependencies).

But if I find that CMake supports all I need at that level, then I
expect I could just as easily generate ninja files as makefiles. The
only issue that I know of is that ninja does not have full jobserver
support, which could be important if the build involves other parallel
tasks (like gcc LTO linking).

>
>> It appears to have some disadvantages compared to my makefiles,
>> such as needed to be run as an extra step when files are added or
>> removed to a project or dependencies are changed, but that doesn't
>> happen too often, and it's integration with other tools and projects
>> might make it an overall win.
>
> Some are proposing Meson as an alternative to CMake. I think they are
> saying that the fact that its scripting language is not fully Turing-
> equivalent is an advantage.
>
> Me, while I think the CMake language can be a little clunky in places, I
> still think having Turing-equivalence is better than not having it. ;)

For many reasons, CMake is the prime candidate as an alternative to make
for my use.

On 02/02/2024 01:26, Malcolm McLean wrote:
> On 01/02/2024 21:34, David Brown wrote:
>>
>>> It works for me, and I'm sure could work for others if they didn't
>>> have makefiles forced down their throats and hardwired into their
>>> brains.
>>
>> /Nobody/ has makefiles forced on them.  People use "make" because it
>> is convenient, and it works.  If something better comes along, and it
>> is better enough to overcome the familiarity momentum, people will use
>> that.
>>
> What?
> You have total control of your programming environment and never have to
> consider anybody else? For hobby programming you do in a way. Not if you
> want other people to use your stuff. But can always say that fun of
> doing things exactly your way outweighs the fun of getting downloads.
>

Okay, none of the people talking about "make" /here/ had it forced on
them for the uses they are talking about /here/.

Yes, I have a very large degree of control over my programming
environment - because I work in a company where employees get to make
the decisions that they are best qualified to make, and management's job
is to support them. One of the important factors I consider is
interaction with colleagues and customers, for which "make" works well.

And while people may be required to use make, or particular compilers,
or OS's, no one is forced to /like/ a tool or find it useful. I believe
that when people here say they like make, or find it works well for
them, or that it can handle lots of different needs, or that they know
of nothing better for their requirements, they are being honest about
that. If they didn't like it, they would say.

The only person here whom we can be absolutely sure does /not/ have
"make" forced upon them for their development, is Bart. And he is the
one who complains about it.

On 02/02/2024 10:13, David Brown wrote:
> On 02/02/2024 01:26, Malcolm McLean wrote:
>> On 01/02/2024 21:34, David Brown wrote:
>>>
>>>> It works for me, and I'm sure could work for others if they didn't
>>>> have makefiles forced down their throats and hardwired into their
>>>> brains.
>>>
>>> /Nobody/ has makefiles forced on them.  People use "make" because it
>>> is convenient, and it works.  If something better comes along, and it
>>> is better enough to overcome the familiarity momentum, people will
>>> use that.
>>>
>> What?
>> You have total control of your programming environment and never have
>> to consider anybody else? For hobby programming you do in a way. Not
>> if you want other people to use your stuff. But can always say that
>> fun of doing things exactly your way outweighs the fun of getting
>> downloads.
>>
>
> Okay, none of the people talking about "make" /here/ had it forced on
> them for the uses they are talking about /here/.
>
> Yes, I have a very large degree of control over my programming
> environment - because I work in a company where employees get to make
> the decisions that they are best qualified to make, and management's job
> is to support them.  One of the important factors I consider is
> interaction with colleagues and customers, for which "make" works well.
>
> And while people may be required to use make, or particular compilers,
> or OS's, no one is forced to /like/ a tool or find it useful.  I believe
> that when people here say they like make, or find it works well for
> them, or that it can handle lots of different needs, or that they know
> of nothing better for their requirements, they are being honest about
> that.  If they didn't like it, they would say.
>
> The only person here whom we can be absolutely sure does /not/ have
> "make" forced upon them for their development, is Bart.  And he is the
> one who complains about it.
>

Not for my own development, no. Unless that includes having to build
external dependenceies from source, which are written in C.

Or just things I want to test my C compiler on.

If I want to build Seed7, for example, that comes with 19 different
makefiles. LibJPEG has 15 different makefiles. GMP has one makefiles,
but a 30,000-line configure script dependent on Linux.

I could and have spent a lot of time on many of those in manually
discovering the C files necessary to building the project.

Once done, the process was beautifully streamlined and simple.

But I know this a waste of time and nobody's mind is going to be changed.

On 02/02/2024 02:22, tTh wrote:
> On 2/1/24 23:29, bart wrote:
>> I do. You type:
>>
>>     cc prog
>>
>> without knowing or caring whether the contains that one module, or
>> there are 99 more.
>>
>
> I also do. You type:
>
>    make prog
>
> without knowing or caring whether the contains that one module, or
> there are 51 more.

Really? OK, let's try it:

c:\c>make cipher
cc cipher.c -o cipher
C:\tdm\bin\ld.exe:
C:\Users\44775\AppData\Local\Temp\ccRvFIdY.o:cipher.c:(.text+0x55a):
undefined reference to `hmac_sha256_final'

It seems I do need to care after all!

Oh, you mean I don't need to care AFTER I've created a complicated
makefile containing all those details that you claim I don't need to
bother with?

Let's try with a real solution:

c:\c>mcc cipher
Compiling cipher.c to cipher.exe

Or here's one where I don't need to add anything to the C code:

c:\c>bcc -auto cipher
1 Compiling cipher.c to cipher.asm (Pass 1)
* 2 Compiling hmac.c to hmac.asm (Pass 2)
* 3 Compiling sha2.c to sha2.asm (Pass 2)
Assembling to cipher.exe

I'm the one who's trying innovative approaches to minimise the extra
gumph you need to provide to build programs.

You're the one who needs to first write a pile of garbage within a
makefile in order for you to do:

make prog

Below is the makefile needed to build lua 5.4, which is a project of
only 35 C modules. Simple, isn't it?

---------------------------------
# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.

# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================

# Your platform. See PLATS for possible values.
PLAT= guess

CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra -DLUA_COMPAT_5_3 $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= -lm $(SYSLIBS) $(MYLIBS)

AR= ar rcu
RANLIB= ranlib
RM= rm -f
UNAME= uname

SYSCFLAGS=
SYSLDFLAGS=
SYSLIBS=

MYCFLAGS=
MYLDFLAGS=
MYLIBS=
MYOBJS=

# Special flags for compiler modules; -Os reduces code size.
CMCFLAGS=

# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======

PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris

LUA_A= liblua.a
CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o
ltm.o lundump.o lvm.o lzio.o
LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o
loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)

LUA_T= lua
LUA_O= lua.o

LUAC_T= luac
LUAC_O= luac.o

ALL_O= $(BASE_O) $(LUA_O) $(LUAC_O)
ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T)
ALL_A= $(LUA_A)

# Targets start here.
default: $(PLAT)

all: $(ALL_T)

o: $(ALL_O)

a: $(ALL_A)

$(LUA_A): $(BASE_O)
$(AR) $@ $(BASE_O)
$(RANLIB) $@

$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUA_O) $(LUA_A) $(LIBS)

$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUAC_O) $(LUA_A) $(LIBS)

test:
./$(LUA_T) -v

clean:
$(RM) $(ALL_T) $(ALL_O)

depend:
@$(CC) $(CFLAGS) -MM l*.c

echo:
@echo "PLAT= $(PLAT)"
@echo "CC= $(CC)"
@echo "CFLAGS= $(CFLAGS)"
@echo "LDFLAGS= $(LDFLAGS)"
@echo "LIBS= $(LIBS)"
@echo "AR= $(AR)"
@echo "RANLIB= $(RANLIB)"
@echo "RM= $(RM)"
@echo "UNAME= $(UNAME)"

# Convenience targets for popular platforms.
ALL= all

help:
@echo "Do 'make PLATFORM' where PLATFORM is one of these:"
@echo " $(PLATS)"
@echo "See doc/readme.html for complete instructions."

guess:
@echo Guessing `$(UNAME)`
@$(MAKE) `$(UNAME)`

AIX aix:
$(MAKE) $(ALL) CC="xlc" CFLAGS="-O2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-ldl" SYSLDFLAGS="-brtl -bexpall"

bsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-Wl,-E"

c89:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_C89" CC="gcc -std=c89"
@echo ''
@echo '*** C89 does not guarantee 64-bit integers for Lua.'
@echo '*** Make sure to compile all external Lua libraries'
@echo '*** with LUA_USE_C89 to ensure consistency'
@echo ''

FreeBSD NetBSD OpenBSD freebsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE
-I/usr/include/edit" SYSLIBS="-Wl,-E -ledit" CC="cc"

generic: $(ALL)

ios:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_IOS"

Linux linux: linux-noreadline

linux-noreadline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl"

linux-readline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE"
SYSLIBS="-Wl,-E -ldl -lreadline"

Darwin macos macosx:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_MACOSX -DLUA_USE_READLINE"
SYSLIBS="-lreadline"

mingw:
$(MAKE) "LUA_A=lua54.dll" "LUA_T=lua.exe" \
"AR=$(CC) -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
$(MAKE) "LUAC_T=luac.exe" luac.exe

posix:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX"

SunOS solaris:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN
-D_REENTRANT" SYSLIBS="-ldl"

# Targets that do not create files (not all makes understand .PHONY).
..PHONY: all $(PLATS) help test clean default o a depend echo

# Compiler modules may use special flags.
llex.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c llex.c

lparser.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lparser.c

lcode.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lcode.c

# DO NOT DELETE

lapi.o: lapi.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lstring.h \
ltable.h lundump.h lvm.h
lauxlib.o: lauxlib.c lprefix.h lua.h luaconf.h lauxlib.h
lbaselib.o: lbaselib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lcode.o: lcode.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lgc.h lstring.h ltable.h lvm.h
lcorolib.o: lcorolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lctype.o: lctype.c lprefix.h lctype.h lua.h luaconf.h llimits.h
ldblib.o: ldblib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ldebug.o: ldebug.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h lcode.h llex.h lopcodes.h lparser.h \
ldebug.h ldo.h lfunc.h lstring.h lgc.h ltable.h lvm.h
ldo.o: ldo.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lopcodes.h \
lparser.h lstring.h ltable.h lundump.h lvm.h
ldump.o: ldump.c lprefix.h lua.h luaconf.h lobject.h llimits.h lstate.h \
ltm.h lzio.h lmem.h lundump.h
lfunc.o: lfunc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h
lgc.o: lgc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lstring.h ltable.h
linit.o: linit.c lprefix.h lua.h luaconf.h lualib.h lauxlib.h
liolib.o: liolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
llex.o: llex.c lprefix.h lua.h luaconf.h lctype.h llimits.h ldebug.h \
lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lgc.h llex.h lparser.h \
lstring.h ltable.h
lmathlib.o: lmathlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lmem.o: lmem.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h
loadlib.o: loadlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lobject.o: lobject.c lprefix.h lua.h luaconf.h lctype.h llimits.h \
ldebug.h lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h \
lvm.h
lopcodes.o: lopcodes.c lprefix.h lopcodes.h llimits.h lua.h luaconf.h
loslib.o: loslib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lparser.o: lparser.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lfunc.h lstring.h lgc.h ltable.h
lstate.o: lstate.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h llex.h \
lstring.h ltable.h
lstring.o: lstring.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h
lstrlib.o: lstrlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltable.o: ltable.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
ltablib.o: ltablib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltm.o: ltm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
lua.o: lua.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
luac.o: luac.c lprefix.h lua.h luaconf.h lauxlib.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h lopcodes.h lopnames.h lundump.h
lundump.o: lundump.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lstring.h lgc.h \
lundump.h
lutf8lib.o: lutf8lib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lopcodes.h lstring.h \
ltable.h lvm.h ljumptab.h
lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
lobject.h ltm.h lzio.h

On Fri, 2 Feb 2024 09:02:15 +0100
David Brown <david.brown@hesbynett.no> wrote:
>
> But don't hold your breath waiting for something that will replace
> make, or attract users of any other build system.
>
>

It seems, you already forgot the context of my post that started this
short sub-thread.

BTW, I would imagine that Stu Feldman, if he is still in good health,
would fine talking with Bart more entertaining that talking with you.
I think, you, English speakers, call it birds of feather.

On 02/02/2024 22:13, bart wrote:
[Bitching about "make" snipped]

Try "cake", Zoltan wrote it many decades ago, when we were at
$GOSHWHATAUNIVERSITY, because he thought "make" was too prolix.

Cheers,
Gary B-)

On 02/02/2024 11:13, bart wrote:

> You're the one who needs to first write a pile of garbage within a
makefile in order for you to do:
>
> make prog
>
> Below is the makefile needed to build lua 5.4, which is a project of
only 35 C modules. Simple, isn't it?

> ---------------------------------
> # Makefile for building Lua
> # See ../doc/readme.html for installation and customization instructions.
>
> # == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT

Now this is an interesting comment. The makefile is set up for gcc. For
another compiler it won't work.

If I try to switch to 'tcc', there are a number of problems. First,
unless you do 'make clean', the .o files lying about (I guess a
consequence of being to do incremental builds), are incompatible.

At this point I discovered a bug in the makefile for Lua (you might say
it's not bug, it's one of the settings that need changing, but I've no
idea how or where):

Although this makefile works with gcc on Windows, it thinks the
executable is called 'lua', not 'lua.exe'. It will produce 'lua.exe'
with gcc, but it checks for the existence of 'lua'.

That is never present, so it always links; it never says 'is up-to-date'.

With tcc however, there's another issue: tcc requires the .exe extension
in the -o option, otherwise it writes the executable as 'lua'. Now, at
last, make sees 'lua' and deems it up-to-date. Unfortunately that won't
run under Windows.

Either not at all, or it will use the lua.exe left over from gcc. I can
bodge this by using '-o $@.exe', producing lua.exe from tcc, but make is
still checking 'lua'.

There are some minor things: tcc doesn't like the -lm option for example.

But what it comes down to is that it seems I need a separate makefile
for each compiler. As supplied, it didn't even work 100% for gcc on Windows.

That means duplicating all that file info.

This is a solution I used before, using this @ file:

------------------------------
-O2 -s -o lua.exe
lua.c lapi.c lcode.c lctype.c ldebug.c ldo.c ldump.c lfunc.c lgc.c
llex.c lmem.c lobject.c lopcodes.c lparser.c lstate.c lstring.c
ltable.c ltm.c lundump.c lvm.c lzio.c lauxlib.c lbaselib.c lcorolib.c
ldblib.c liolib.c lmathlib.c loadlib.c loslib.c lstrlib.c ltablib.c
lutf8lib.c linit.c
------------------------------

If I run it like this:

gcc @luafiles

it produces a 260KB executable. Which is another interesting thing:
using 'make lua' set up for gcc produces a 360KB executable.

But I can also run it like this:

tcc @luafiles

The same file works for both gcc and tcc.

It won't work for mcc unless I split it into two, as that first line of
options doesn't work there. However with mcc I can now just do this:

mcc lua

So two solutions for this project that (1) don't involve a makefile; (2)
work better than the makefile.

It's true that it involved recompiling every module. But tcc still
builds this project in 0.3 seconds.

This project contains 34 C files, or which 33 are needed (not 35 as I
said). That means that using *.c is not possible, unless that extra file
(I believe used when building a shared library) is renamed.

If that is done, then all compilers just need "*.c" plus whatever other
options are needed.

On Fri, 2 Feb 2024 10:47:12 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 01/02/2024 23:29, bart wrote:
> > On 01/02/2024 21:34, David Brown wrote:
> >> On 01/02/2024 19:34, bart wrote:
> >
> >>> You don't see that the language taking over task (1) of the
> >>> things that makefiles do, and possibly (2) (of the list I posted;
> >>> repeated below), can streamline makefiles to make them shorter,
> >>> simpler, easier to write and to read, and with fewer
> >>> opportunities to get stuff wrong?
> >>>
> >>> That was a rhetorical question. Obviously not.
> >>
> >> I've nothing against shorter or simpler makefiles.  But as far as
> >> I can see, you are just moving the same information from a
> >> makefile into the C files.
> >>
> >> Indeed, you are duplicating things - now your C files have to have
> >> "#pragma module this, #pragma module that" in addition to having
> >> "#include this.h, #include that.h".  With my makefiles, all the
> >> "this" and "that" is found automatically - writing the includes in
> >> the C code is sufficient.
> >
> > I don't think so. Seeing:
> >
> >     #include "file.h"
> >
> > doesn't necessarily mean there is a matching "file.c". It might not
> > exist, or the header might be for some external library, or maybe
> > it does exist but in a different location.
>
> As I said, you are duplicating things.
>
> For my builds, I do not have anywhere that I need to specify "file.c".
>
> >
> > Or maybe some code may use a file "fred.c", which needs to be
> > submitted to the compiler, but for which there is either no header
> > used, or uses a header file with a different name.
> >
> > As I said, C's uses of .h and .c files are chaotic.
>
> My uses of .h and .c files are not chaotic.
>
> Maybe you can't write well-structured C programs. Certainly not
> everyone can. (And /please/ do not give another list of open source
> programs that you don't like. I didn't write them. I can tell you
> how and why /I/ organise my projects and makefiles - I don't speak
> for others.)
>
> >
> > Did you have in mind using gcc's -MM option? For my 'cipher.c'
> > demo, that only gives a set of header names.  Missing are hmac.c
> > and sha2.c.
>
> I use makefiles where gcc's "-M" options are part of the solution -
> not the whole solution.
>
> > If I try it on lua.c, it gives me only 5 header files; the project
> > comprises 33 .c files and 27 .h files.
> >
>
> I don't care. I did not write lua.
>
> But I /have/ integrated lua with one of my projects, long ago. It
> fit into my makefile format without trouble - I added the lua
> directory as a subdirectory of my source directory, and that was all
> that was needed.
>
> >>>
> >>>
> >>>> Perhaps I would find your tools worked for a "Hello, world"
> >>>> project. Maybe they were still okay as it got slightly bigger.
> >>>> Then I'd have something that they could not handle, and I'd
> >>>> reach for make.  What would be the point of using "make" to
> >>>> automate - for example - post-processing of a binary to add a
> >>>> CRC check, but using your tools to handle the build?  It's much
> >>>> easier just to use "make" for the whole thing.
> >>>
> >>>
> >>> Because building one binary is a process should be the job of a
> >>> compiler, not some random external tool that knows nothing of the
> >>> language or compiler.
> >>
> >> No, it is the job of the linker.
> >
> > There is where you're still stuck in the past.
> >
> > I first got rid of a formal 'linker' about 40 years ago. I got rid
> > of the notion of combining independently compiled modules into an
> > executable a decade ago.
>
> No, you built a monolithic tool that /included/ the linker. That's
> fine for niche tools that are not intended to work with anything
> else. Most people work with many tools - that's why we have
> standards, defined file formats, and flexible tools with wide support.
>
> Other people got rid of monolithic tools forty years ago when they
> realised it was a terrible way to organise things.
>

Actually, nowadays monolithic tools are solid majority in programming.
I mean, programming in general, not C/C++/Fortran programming which by
itself is a [sizable] minority.
Even in C++, a majority uses non-monolithic tools well-hidden behind
front end (IDE) that makes them indistinguishable from monolithic.

>
> >
> > But I suspect you don't understand what a 'whole-program compiler'
> > does:
>
> I know exactly what it does. I am entirely without doubt that I know
> the point and advantages of them better than you do - the /real/
> points and advantages, not some pathetic "it means I don't have to
> use that horrible nasty make program" reason.
>
> > * It means that for each binary, all sources are recompiled at the
> > same time to create it
>
> No, it does not.
>
> >
> > * It doesn't mean that an application can only comprise one binary
>
> Correct.
>
> >
> > * It moves the compilation unit granularity from a module to a
> > single EXE or DLL file
>
> No, it does not.
>
> >
> > * Interfaces (in the case of a lower level language), are moved
> > inter- module to inter-program. The boundaries are between one
> > program or library and another, not between modules.
>
> Correct.
>
> >
> > A language which claims to have a module system, but still compiles
> > a module at a time, will probably still have discrete inter-module
> > interfaces, although they may be handled automatically.
> >
>
> Correct.
>
>
> In real-world whole program compilation systems, the focus is on
> inter-module optimisations. Total build times are expected to go
> /up/. Build complexity can be much higher, especially for large
> programs. It is more often used for C++ than C.
>
> The main point of a lot of whole-program compilation is to allow
> cross-module optimisation. It means you can have "access" functions
> hidden away in implementation files so that you avoid global
> variables or inter-dependencies between modules, but now they can be
> inline across modules so that you have no overhead or costs for this.
> It means you can write code that is more structured and modular,
> with different teams handling different parts, and with layers of
> abstractions, but when you pull it all together into one
> whole-program build, the run-time costs and overhead for this all
> disappear. And it means lots of checks and static analysis can be
> done across the whole program.
>
>
> For such programs, each translation unit is still compiled
> separately, but the "object" files contain internal data structures
> and analysis information, rather than generated code. Lots of the
> work is done by this point, with inter-procedural optimisations done
> within the unit. These compilations will be done as needed, in
> parallel, under the control of a build system. Then they are
> combined for the linking and link-time optimisation which fits the
> parts together. Doing this in a scalable way is hard, and the
> subject of a lot of research, as you need to partition it into chunks
> that can be handled in parallel on multiple cpu cores (or even
> distributed amongst servers). Once you have parts of code that are
> ready, they are handed on to backend compilers that do more
> optimisation and generate the object code, and this in turn is linked
> (sometimes incrementally in parts, again aiming at improving parallel
> building and scalability.
>
>
> You go to all this effort because you are building software that is
> used by millions of people, and your build effort is minor compared
> to the total improvements for all users combined. Or you do it
> because you are building speed-critical software. Or you want the
> best static analysis you can get, and want that done across modules.
> Or you are building embedded systems that need to be as efficient as
> possible.
>
> You don't do it because you find "make" ugly.
>
>
> It is also very useful on old-fashioned microcontrollers with
> multiple banks for data ram and code memory, and no good data stack
> access - the compiler can do large-scale lifetime analysis and
> optimise placement and the re-use of the very limited ram.
>
>
> >
> >> /Nobody/ has makefiles forced on them.  People use "make" because
> >> it is convenient, and it works.
> >
> > BUT IT DOESN'T.
>
> IT DOES WORK.
>
> People use it all the time.
>
> > It fails a lot of the time on Windows, but they are too
> > complicated to figure out why.
>
> People use it all the time on Windows.
>
> Even Microsoft ships its own version of make, "nmake.exe", and has
> done for decades.
>
> /You/ can't work it, but you excel at failing to get things working.
> You have a special gift - you just have to look at a computer with
> tools that you didn't write yourself, and it collapses.
>
> >
> >> But I have no interest in changing to something vastly more
> >> limited and which adds nothing at all.
> >
> > That's right; it adds nothing, but it takes a lot away! Like a lot
> > of failure points.
>
> Like pretty much everything I need.
>
>

On 02/02/2024 08:02, David Brown wrote:
> On 01/02/2024 23:55, Michael S wrote:
>> On Thu, 1 Feb 2024 22:38:13 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> On 01/02/2024 21:23, Michael S wrote:
>>>> On Thu, 1 Feb 2024 18:34:08 +0000
>>>
>
>>>>
>>>> You proposal and needs of David Brown are not necessarily
>>>> contradictory.
>>>> All you need to do to satisfy him is to add to your compiler an
>>>> option for export of dependencies in make-compatible format, i.e.
>>>> something very similar to -MD option of gcc.
>>>>
>>>> Then David could write in his makefile:
>>>>
>>>> out/foo.elf : main_foo.c
>>>>     mcc -MD $< -o $@
>>>>
>>>> -include out/foo.d
>>>>
>>>> And then to proceed with automatiion of his pre and post-processing
>>>> needs.
>>>
>>> But then I'd still be using "make", and Bart would not be happy.
>>>
>>> And "gcc -MD" does not need any extra #pragmas, so presumably neither
>>> would an implementation of that feature in bcc (or mcc or whatever).
>>> So Bart's new system would disappear entirely.
>>>
>>>
>>>
>>
>> Bart spares you from managing list(s) of objects in your makefile and
>> from writing arcan helper macros.
>> Yes, I know, you copy&past arcan macros from project to project, but
>> you had to write them n years ago and that surely was not easy.
>>
>
> Google "makefile automatic dependencies", then adapt to suit your own
> needs.  Re-use the same makefile time and again.
>
> Yes, some of the functions I have in my makefiles are a bit hairy, and
> some of the command line options for gcc are a bit complicated.  They
> are done now.
>
> If there had been an easier way than this, which still let me do what I
> need (Bart's system does not), which is popular enough that you can
> easily google for examples, blogs, and tutorials, then I'd have been
> happy to use that at the time.  I won't change to something else unless
> it gives me significant additional benefits.
>
> People smarter and more experienced than Bart have been trying to invent
> better replacements for "make" for many decades.  None have succeeded.
> Some build systems are better in some ways, but nothing has come close
> to covering the wide range of features and uses of make, or gaining hold
> outside a particular niche.  Everyone who has ever made serious use of
> "make" knows it has many flaws, unnecessarily complications, limitations
> and inefficiencies.  Despite that, it is the best we have.
>
> With Bart's limited knowledge and experience,

That's true: only 47 years in computing, and 42 years of evolving,
implementing and running my systems language.

What can I possibly know about compiling sources files of a lower-level
language into binaries?

How many assemblers, compilers, linkers, and interpreters have /you/
written?

> and deeply ingrained
> prejudices and misunderstandings, the best we can hope for is something
> that works well enough for some simple cases of C programs.

With the proposal outlined in my OP, any of MY C programs, if I was to
write or port multi-module projects in that language, could be trivially
built by giving only the name of the compiler, and the name of one module.

>  More
> realistically, it will work for Bart's use alone.

It certainly won't for your stuff, or SL's, or JP's, or TR's, as you
all seem to delight in wheeling out the most complex scenarios you can find.

That is another aspect you might do well to learn how to do: KISS. (Yes
I can be a patronising fuck too.)

> And that, of course, is absolutely fine.  No one is paying Bart to write
> a generic build system, or something of use to anyone else.  He is free
> to write exactly what he wants, in the way he wants, and if ends up with
> a tool that he finds useful himself, that is great.  If he ends up with
> something that at least some other people find useful, that is even
> better, and I wish him luck with his work.
>
> But don't hold your breath waiting for something that will replace make,
> or attract users of any other build system.

Jesus. And you seem to determined to ignore everything I write, or have
a short memory.

I'm not suggesting replacing make, only to reduce its involvement.

Twice I posted a list of 3 things that make takes care of; I'm looking
at replacing just 1 of those things, the I which for me is more critical.