By 'Build System', I mean a convenient or automatic way to tell a
compiler which source and library files comprise a project, one that
doesn't involve extra dependencies.

This proposal comes under 'convenient' rather than 'automatic'. (I did
try an automatic scheme in the past, but that only worked for specially
written projects.)

Here, the method is straightforward: the necessary info is simply listed
in the designated lead module, within a set of #pragma lines.

For my go-to small project demo, which comprises the three source files
cipher.c, hmac.c, sha2.c, there are two ways to do it:

(1) Add the info to top of the lead module cipher.c:

#pragma module "hmac.c"
#pragma module "sha2.c"
....

I wasn't intending to actually implement it, but it didn't take long,
and it seems to work:

c:\cx>mcc cipher
Compiling cipher.c to cipher.exe
Adding module hmac.c
Adding module sha2.c

(2) Create an extra lead module and add it to the project.

This allows the scheme to be superimposed on an existing codebase
without having to modify it. If I try that on the above cipher project
in a new module demo.c, it will contain:

#pragma module "cipher.c"
#pragma module "hmac.c"
#pragma module "sha2.c"

It works like this (in the real version those "Adding" lines will be
silent):

c:\cx>mcc demo
Compiling demo.c to demo.exe
Adding module cipher.c
Adding module hmac.c
Adding module sha2.c

To get the original cipher.exe output needs an override option, but see
below.

Method (2) is attractive as it provides a means to easily set up
different configurations of an applications, but mix-and-matching modules.

Pragma Directives
-----------------

These are the ones I had in mind:

module "file.c" As used above. Possibly, wildcards can work here

import "file.c Incorporate a separate project which has its own
set of pragma directives

link "file.dll" Any binary libraries

header "file.h" Specify a program-wide shared header

Possibly the 'import' one can be dispensed with; it is simple enough to
manually copy and past the necessary info. However that means it is
listed in more than one place, and the original can change.

The idea of 'header' is to specify big headers (windows.h, sdl2.h, etc)
which are independent of anything else, which are then processed just
once in the compiler, rather than once for each module that includes
them. The usual '#include's are still needed.

(The intention is not to create a whole-program compiler, or to
introduce a module scheme, although this provides some of the benefits.
The C language is unchanged.)

Possibly, there can be a directive called 'name' to specify an
executable file name.

Working with Other Compilers
----------------------------

Clearly, my scheme will only work with a suitable modified compiler.
Without that, then I considered doing something like this, adding this
block to my example from (2):

#pragma module "cipher.c"
#pragma module "hmac.c"
#pragma module "sha2.c"

#ifndef __MCC__
#include "runcc.c"

int main(void) {
runcc(__FILE__);
}
#endif

When run a compiler that is not MCC, this builds a small program (here
still called demo.exe), which calls a function to read from this file,
process the relevant #pragma lines, and use that info to invoke a
conventional compiler.

I haven't tested it, but it would mean a two-step process that looks
something like this (possibly, it can pick up the name of the compiler
that /is/ used, and invoke that on the actual program):

c:\cx\tcc demo.c
c:\cx\demo
... invoke tcc to build cipher.c hmac.c sha2.c ...

(Tcc of course also has the -run option to save that second line)

For this to work, the pragma stuff must be cleanly written: the runcc()
function will only do basic string processing, it is not a C compiler.

Using a Makefile
----------------

One use-case for this would be if /I/ supplied a multi-module C program,
or packaged someone else's.

But people are mad about makefiles so, sure, I can also supply a 2-line
makefile to do the above.

Dependencies and Incremental Compilation
----------------------------------------

This project is not about that, and is for cases where compiling all
sources in one go is viable, or where a one-off build time is not relevant.

That can mean when using fast a compiler and/or the scale of the project
allows.

Although the 'header' directive will also help, in cases where the
application itself is small, but has dependencies on large complex
headers. (I haven't quite figured out how it might work though.)

On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:

> By 'Build System', I mean a convenient or automatic way to tell a
> compiler which source and library files comprise a project, one that
> doesn't involve extra dependencies.

If it only works for C code, then that is going to limit its usefulness in
today’s multilingual world.

On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote:
> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>
>> By 'Build System', I mean a convenient or automatic way to tell a
>> compiler which source and library files comprise a project, one that
>> doesn't involve extra dependencies.
>
> If it only works for C code, then that is going to limit its usefulness in
> today’s multilingual world.

Huh?

On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>
>> By 'Build System', I mean a convenient or automatic way to tell a
>> compiler which source and library files comprise a project, one that
>> doesn't involve extra dependencies.
>
> If it only works for C code, then that is going to limit its usefulness in
> today’s multilingual world.

Languages these days tend to have module schemes and built-in means of
compiling assemblies of modules.

C doesn't.

The proposal would allow a project to be built using:

cc file.c

instead of cc file.c file2.c .... lib1.dll lib2.dll ...,

or instead of having to provide a makefile or an @ filelist.

That is significant advance on what C compilers typically do.

On 30/01/2024 01:45, bart wrote:
> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>
>>> By 'Build System', I mean a convenient or automatic way to tell a
>>> compiler which source and library files comprise a project, one that
>>> doesn't involve extra dependencies.
>>
>> If it only works for C code, then that is going to limit its
>> usefulness in
>> today’s multilingual world.
>
> Languages these days tend to have module schemes and built-in means of
> compiling assemblies of modules.
>
> C doesn't.
>
> The proposal would allow a project to be built using:
>
>    cc file.c
>
> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>
> or instead of having to provide a makefile or an @ filelist.
>
> That is significant advance on what C compilers typically do.
>
There's a desperate need for hierarchy.
A library like ChatGTP only needs to expose one function,
"answer_question". Maybe a few extra to give context. But of course that
one function calls masses and masses of subroutines. Which should be
private to the module, but not to the source file for the
"answer_question" function.

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

On 30/01/2024 02:38, Chris M. Thomasson wrote:
> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote:
>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>
>>> By 'Build System', I mean a convenient or automatic way to tell a
>>> compiler which source and library files comprise a project, one that
>>> doesn't involve extra dependencies.
>>
>> If it only works for C code, then that is going to limit its
>> usefulness in
>> today’s multilingual world.
>
> Huh?

I assume he means it's common to use multiple programming languages,
rather than multiple human languages. (The later may also be true, but
it's the former that is relevant.)

For my own use at least, he's right. His system is aimed at being
simpler than make for C-only projects with limited and straightforward
build requirements. That's fine for such projects, and if that suits
his needs or the needs of others, great. But it would not cover more
than a tiny proportion of my projects over the decades - at least not
without extra help (extra commands, bash/bat files, etc.)

On 30/01/2024 02:45, bart wrote:
> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>
>>> By 'Build System', I mean a convenient or automatic way to tell a
>>> compiler which source and library files comprise a project, one that
>>> doesn't involve extra dependencies.
>>
>> If it only works for C code, then that is going to limit its
>> usefulness in
>> today’s multilingual world.
>
> Languages these days tend to have module schemes and built-in means of
> compiling assemblies of modules.
>
> C doesn't.
>
> The proposal would allow a project to be built using:
>
>    cc file.c
>
> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>
> or instead of having to provide a makefile or an @ filelist.
>
> That is significant advance on what C compilers typically do.

You are absolutely right that C does not have any real kind of module
system, and that can be a big limitation compared to other languages.
However, I don't think the build system is where the lack of modules is
an issue - it is the scaling of namespaces and identifier clashes that
are the key challenge for large C projects.

Building is already solved - "make" handles everything from tiny
projects to huge projects. When "make" isn't suitable, you need /more/,
not less - build server support, automated build and test systems, etc.
And for users who like simpler things and have simpler projects, IDE's
are almost certainly a better option and will handle project builds.

I don't doubt that your build system is simpler and easier for the type
of project for which it can work - but I doubt that there are many
people who work with such limited scope projects and who don't already
have a build method that works for their needs. Still, if it is useful
for you, and useful for some other people, then that makes it useful.

On 30/01/2024 04:46, Malcolm McLean wrote:
> On 30/01/2024 01:45, bart wrote:
>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Languages these days tend to have module schemes and built-in means of
>> compiling assemblies of modules.
>>
>> C doesn't.
>>
>> The proposal would allow a project to be built using:
>>
>>     cc file.c
>>
>> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>>
>> or instead of having to provide a makefile or an @ filelist.
>>
>> That is significant advance on what C compilers typically do.
> >
> There's a desperate need for hierarchy.
> A library like ChatGTP only needs to expose one function,
> "answer_question". Maybe a few extra to give context. But of course that
> one function calls masses and masses of subroutines. Which should be
> private to the module, but not to the source file for the
> "answer_question" function.

I'm not sure what that has to do with my proposal (which is not to add a
module scheme as I said).

I've now added wildcards to my test implementation. If I go to your
resource compiler project (which I call 'BBX') and add one small C file
called bbx.c containing:

#pragma module "*.c"
#pragma module "freetype/*.c"
#pragma module "samplerate/*.c"

then I can build it like this:

c:\bbx\src>mcc bbx
Compiling bbx.c to bbx.exe

The file provides also the name of the executable:

c:\bbx\src>bbx
The Baby X resource compiler v1.1
by Malcolm Mclean
....

Without this feature, building wasn't exactly onerous; I used an @ file
called 'bbx' which contained:

*.c freetype/*.c samplerate/*.c

and built using:

c:\bbx\src>mcc @bbx -out:bbx
Compiling 44 files to bbx.exe

But this requires an extra, non-C file (effectively a script), and a
special invocation (the @). The EXE name can be put in there was well,
but the option for that depends on compiler. (gcc can''t use this @ file
as it contains wildcards.)

On 30/01/2024 08:17, David Brown wrote:
> On 30/01/2024 02:45, bart wrote:
>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Languages these days tend to have module schemes and built-in means of
>> compiling assemblies of modules.
>>
>> C doesn't.
>>
>> The proposal would allow a project to be built using:
>>
>>     cc file.c
>>
>> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>>
>> or instead of having to provide a makefile or an @ filelist.
>>
>> That is significant advance on what C compilers typically do.
>
> You are absolutely right that C does not have any real kind of module
> system, and that can be a big limitation compared to other languages.
> However, I don't think the build system is where the lack of modules is
> an issue - it is the scaling of namespaces and identifier clashes that
> are the key challenge for large C projects.
>
> Building is already solved - "make" handles everything from tiny
> projects to huge projects.  When "make" isn't suitable, you need /more/,
> not less - build server support, automated build and test systems, etc.
> And for users who like simpler things and have simpler projects, IDE's
> are almost certainly a better option and will handle project builds.

I've already covered this in many posts on the subject. But 'make' deals
with three kinds of requirements:

(1) Specifying what the modules are to be compiled and combined into one
binary file

(2) Specifying dependences between all files to allow rebuilding of that
one file with minimal recompilation

(3) Everything else needed in a complex project: running processes to
generate files file config.h, creating multiple binaries, specifying
dependencies between binaries, installation etc

My proposal tackles only (1), which is something that many languages now
have the means to deal with themselves. I already stated that (2) is not
covered.

But you may still need makefiles to deal with (3).

If your main requirement /is/ only (1), then my idea is to move the
necessary info into the source code, and tackle it with the C compiler.

Then no separate script or 'make' utility is needed.

I also outlined a way to make this work with any existing compiler.
(Needs an extra C module. Effectively the list of #pragmas becomes a
script which is processed by this module. But no extra language is
needed; only C.)

On 30/01/2024 11:52, bart wrote:
> On 30/01/2024 04:46, Malcolm McLean wrote:
>> On 30/01/2024 01:45, bart wrote:
>>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>>
>>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>>> compiler which source and library files comprise a project, one that
>>>>> doesn't involve extra dependencies.
>>>>
>>>> If it only works for C code, then that is going to limit its
>>>> usefulness in
>>>> today’s multilingual world.
>>>
>>> Languages these days tend to have module schemes and built-in means
>>> of compiling assemblies of modules.
>>>
>>> C doesn't.
>>>
>>> The proposal would allow a project to be built using:
>>>
>>>     cc file.c
>>>
>>> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>>>
>>> or instead of having to provide a makefile or an @ filelist.
>>>
>>> That is significant advance on what C compilers typically do.
>>  >
>> There's a desperate need for hierarchy.
>> A library like ChatGTP only needs to expose one function,
>> "answer_question". Maybe a few extra to give context. But of course
>> that one function calls masses and masses of subroutines. Which should
>> be private to the module, but not to the source file for the
>> "answer_question" function.
>
>
> I'm not sure what that has to do with my proposal (which is not to add a
> module scheme as I said).
>
Oh you are not adding modules
> I've now added wildcards to my test implementation. If I go to your
> resource compiler project (which I call 'BBX') and add one small C file
> called bbx.c containing:
>
>     #pragma module "*.c"
>     #pragma module "freetype/*.c"
>     #pragma module "samplerate/*.c"
>
> then I can build it like this:
>
>     c:\bbx\src>mcc bbx
>     Compiling bbx.c to bbx.exe
>
> The file provides also the name of the executable:
>
>     c:\bbx\src>bbx
>     The Baby X resource compiler v1.1
>     by Malcolm Mclean
>     ....
>
> Without this feature, building wasn't exactly onerous; I used an @ file
> called 'bbx' which contained:
>
>     *.c freetype/*.c samplerate/*.c
>
> and built using:
>
>    c:\bbx\src>mcc @bbx -out:bbx
>    Compiling 44 files to bbx.exe
>
> But this requires an extra, non-C file (effectively a script), and a
> special invocation (the @). The EXE name can be put in there was well,
> but the option for that depends on compiler. (gcc can''t use this @ file
> as it contains wildcards.)
>
So essentially we have path listing and description language.
Which ironically is what the resource compiler basically does. You put a
list of paths into an XML file, and it uses that to find the resources,
and merge them together on standard output (as text, of course :-) ).

You're doing the same, except that of course you have to compile and
link rather than decode and lightly pre-process.

But I'm wondering about one file which contains all the sources for the
program. Like an IDE project file but lighter weight.

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

On 30/01/2024 16:50, Malcolm McLean wrote:
> On 30/01/2024 11:52, bart wrote:
>> On 30/01/2024 04:46, Malcolm McLean wrote:

>>> There's a desperate need for hierarchy.
>>> A library like ChatGTP only needs to expose one function,
>>> "answer_question". Maybe a few extra to give context. But of course
>>> that one function calls masses and masses of subroutines. Which
>>> should be private to the module, but not to the source file for the
>>> "answer_question" function.
>>
>>
>> I'm not sure what that has to do with my proposal (which is not to add
>> a module scheme as I said).
>>
> Oh you are not adding modules

In my other language with modules, it specifically does not have a
hierarchy of modules. It causes all sorts of problems, since it's hard
to get away from cycles.

And sometimes you just want to split one module M into modules A and B;
there is no dominant one.

But it also means it doesn't do anything clever to determine the set of
modules comprising a project, starting from one module.

Some languages traverse a tree of import statements. In mine, I don't
have import statements at all littered across the program. There is just
a shopping list of modules started at the start the lead module.

That is the model I used for this C experiment.

>> I've now added wildcards to my test implementation. If I go to your
>> resource compiler project (which I call 'BBX') and add one small C
>> file called bbx.c containing:
>>
>>      #pragma module "*.c"
>>      #pragma module "freetype/*.c"
>>      #pragma module "samplerate/*.c"
>>
>> then I can build it like this:
>>
>>      c:\bbx\src>mcc bbx
>>      Compiling bbx.c to bbx.exe

> So essentially we have path listing and description language.
> Which ironically is what the resource compiler basically does. You put a
> list of paths into an XML file, and it uses that to find the resources,
> and merge them together on standard output (as text, of course :-) ).
>
> You're doing the same, except that of course you have to compile and
> link rather than decode and lightly pre-process.

Yes, the requirement are very simple: it's a list of files! The same
list is usually encoded cryptically inside a make file, or that you need
to submit to CMake, or that you put inside an @ file, or submit to the
compiler on one long command line, or in multiple invocations.

Here it's tidily contained within the C source code.

> But I'm wondering about one file which contains all the sources for the
> program. Like an IDE project file but lighter weight.

That occurred to me too. I gave an outline to invoke a special C module
to scan those #pragma entries in cases where my compiler was not used.

Such an approach could also be used to unpack a set of source files
concatenated into one big source file. This is tidier than having a
sprawling set of files perhaps split across directories.

It means you can just supply one text file.

But there are other ways that people do the same job of turning
multi-module C into a single file.

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

On 1/30/2024 12:06 AM, David Brown wrote:
> On 30/01/2024 02:38, Chris M. Thomasson wrote:
>> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Huh?
>
> I assume he means it's common to use multiple programming languages,
> rather than multiple human languages.  (The later may also be true, but
> it's the former that is relevant.)
>
> For my own use at least, he's right.  His system is aimed at being
> simpler than make for C-only projects with limited and straightforward
> build requirements.

When you say his, you mean, Bart's system, right?

> That's fine for such projects, and if that suits
> his needs or the needs of others, great.  But it would not cover more
> than a tiny proportion of my projects over the decades - at least not
> without extra help (extra commands, bash/bat files, etc.)
>

On 1/30/2024 12:17 AM, David Brown wrote:
> On 30/01/2024 02:45, bart wrote:
>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Languages these days tend to have module schemes and built-in means of
>> compiling assemblies of modules.
>>
>> C doesn't.
>>
>> The proposal would allow a project to be built using:
>>
>>     cc file.c
>>
>> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>>
>> or instead of having to provide a makefile or an @ filelist.
>>
>> That is significant advance on what C compilers typically do.
>
> You are absolutely right that C does not have any real kind of module
> system, and that can be a big limitation compared to other languages.
> However, I don't think the build system is where the lack of modules is
> an issue - it is the scaling of namespaces and identifier clashes that
> are the key challenge for large C projects.

Yup. ct_*, ct_experimental_*, ct_test_*, ect...

Namespaces in C are fun... ;^)

>
> Building is already solved - "make" handles everything from tiny
> projects to huge projects.  When "make" isn't suitable, you need /more/,
> not less - build server support, automated build and test systems, etc.
> And for users who like simpler things and have simpler projects, IDE's
> are almost certainly a better option and will handle project builds.
>
> I don't doubt that your build system is simpler and easier for the type
> of project for which it can work - but I doubt that there are many
> people who work with such limited scope projects and who don't already
> have a build method that works for their needs.  Still, if it is useful
> for you, and useful for some other people, then that makes it useful.
>
>

On 30/01/2024 08:06, David Brown wrote:
> On 30/01/2024 02:38, Chris M. Thomasson wrote:
>> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Huh?
>
> I assume he means it's common to use multiple programming languages,
> rather than multiple human languages.  (The later may also be true, but
> it's the former that is relevant.)
>
> For my own use at least, he's right.  His system is aimed at being
> simpler than make for C-only projects with limited and straightforward
> build requirements.  That's fine for such projects, and if that suits
> his needs or the needs of others, great.  But it would not cover more
> than a tiny proportion of my projects over the decades - at least not
> without extra help (extra commands, bash/bat files, etc.)

It would cover most open source C projects that I have tried to build.
All the following examples came down to a list of C files to be
submitted to a compiler:

Lua
Seed7* (a version from 5 years ago)
Tcc*
PicoC
LibJPEG*
'BBX' (Malcolm's resource compiler)
A68G (An older version; current one is Linux-only)

The ones marked * I believe required some process first to synthesised
some essential header, eg. config.h, often only a few lines long. But
once out of the way, then yes it was just N C files to plough through.

Tcc also had other things going on (once tcc.exe was built, it was used
to prepare some libraries).

LibJPEG had more than one executable, which shared a lot of common
modules. The makefile put those into one .a file, which was then
included in all programs. But since it was statically linked, it did not
save space.

Once I knew what was going on, I just put the common modules in the list
for each program. Or /I/ could choose to put those into a shared library.

It's a question of extracting the easy parts of a project. Once I know
that, I can work my way around anything else and devise my own solutions.

--------------------

In terms of my own real applications, they involved compiled modules;
interpreted modules (that needed compiling to bytecode); processing
source files to derive/update message files for internationalisation;
packaging the numerous files into tidy containers; uploading to
distribution disks, or via FTP; scripts to generate the new index.html
for downloads...

I understand all that part of it. The necessary scripting is utterly
trivial. The above was a process to go through for each release. It
wasn't time-critical, and there were no dependencies to deal with. It
wasn't makefile territory.

The build system described in my OP is that needed to build one binary
file in one language, which is 95% of what I had trouble with in that
list above, /because/ the supplied build process revolved around
makefiles and configure scripts.

bart <bc@freeuk.com> writes:

> [description of a rudimentary C build system]

What was described is what I might call the easiest and
least important part of a build system.

Looking over one of my current projects (modest in size,
a few thousand lines of C source, plus some auxiliary
files adding perhaps another thousand or two), here are
some characteristics essential for my workflow (given
in no particular order):

* have multiple outputs (some outputs the result of
C compiles, others the result of other tools)

* use different flag settings for different translation
units

* be able to express dependency information

* produece generated source files, sometimes based
on other source files

* be able to invoke arbitrary commands, including
user-written scripts or other programs

* build or rebuild some outputs only when necessary

* condition some processing steps on successful
completion of other processing steps

* deliver partially built as well as fully built
program units

* automate regression testing and project archival
(in both cases depending on completion status)

* produce sets of review locations for things like
program errors or TBD items

* express different ways of combining compiler
outputs (such as .o files) depending on what
is being combined and what output is being
produced (sometimes a particular set of inputs
will be combined in several different ways to
produce several different outputs)

Indeed it is the case that producing a complete program is one
part of my overall build process. But it is only one step out
of many, and it is easy to express without needing any special
considerations from the build system.

On 1/30/2024 3:25 PM, Chris M. Thomasson wrote:
> On 1/30/2024 12:17 AM, David Brown wrote:
>> On 30/01/2024 02:45, bart wrote:
>>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>>
>>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>>> compiler which source and library files comprise a project, one that
>>>>> doesn't involve extra dependencies.
>>>>
>>>> If it only works for C code, then that is going to limit its
>>>> usefulness in
>>>> today’s multilingual world.
>>>
>>> Languages these days tend to have module schemes and built-in means
>>> of compiling assemblies of modules.
>>>
>>> C doesn't.
>>>
>>> The proposal would allow a project to be built using:
>>>
>>>     cc file.c
>>>
>>> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>>>
>>> or instead of having to provide a makefile or an @ filelist.
>>>
>>> That is significant advance on what C compilers typically do.
>>
>> You are absolutely right that C does not have any real kind of module
>> system, and that can be a big limitation compared to other languages.
>> However, I don't think the build system is where the lack of modules
>> is an issue - it is the scaling of namespaces and identifier clashes
>> that are the key challenge for large C projects.
>
> Yup. ct_*, ct_experimental_*, ct_test_*, ect...
>
> Namespaces in C are fun... ;^)

The really fun part. Somebody else has the initials CT, so I have to use
cmt_* for the main prefix. ;^)

>
>>
>> Building is already solved - "make" handles everything from tiny
>> projects to huge projects.  When "make" isn't suitable, you need
>> /more/, not less - build server support, automated build and test
>> systems, etc. And for users who like simpler things and have simpler
>> projects, IDE's are almost certainly a better option and will handle
>> project builds.
>>
>> I don't doubt that your build system is simpler and easier for the
>> type of project for which it can work - but I doubt that there are
>> many people who work with such limited scope projects and who don't
>> already have a build method that works for their needs.  Still, if it
>> is useful for you, and useful for some other people, then that makes
>> it useful.
>>
>>
>

On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:

> * have multiple outputs (some outputs the result of
> C compiles, others the result of other tools)

Just as an example, the man page for Blender is generated by a Python
script that runs the built executable with the “--help” option and wraps
that output in some troff markup.

On Tue, 30 Jan 2024 09:17:51 +0100, David Brown wrote:

> You are absolutely right that C does not have any real kind of module
> system ...

Guess which language, which was already considered a bit ancient when C
became popular, has a module system now?

Fortran.

On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:
>
>> * have multiple outputs (some outputs the result of
>> C compiles, others the result of other tools)
>
> Just as an example, the man page for Blender is generated by a Python
> script that runs the built executable with the “--help” option and wraps
> that output in some troff markup.

That's the sort of stunt why distros have given up on clean cross
compiling, and resorted to Qemu.

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

On 31/01/2024 00:23, Chris M. Thomasson wrote:
> On 1/30/2024 12:06 AM, David Brown wrote:
>> On 30/01/2024 02:38, Chris M. Thomasson wrote:
>>> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote:
>>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>>
>>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>>> compiler which source and library files comprise a project, one that
>>>>> doesn't involve extra dependencies.
>>>>
>>>> If it only works for C code, then that is going to limit its
>>>> usefulness in
>>>> today’s multilingual world.
>>>
>>> Huh?
>>
>> I assume he means it's common to use multiple programming languages,
>> rather than multiple human languages.  (The later may also be true,
>> but it's the former that is relevant.)
>>
>> For my own use at least, he's right.  His system is aimed at being
>> simpler than make for C-only projects with limited and straightforward
>> build requirements.
>
> When you say his, you mean, Bart's system, right?
>

Yes.

>
>> That's fine for such projects, and if that suits his needs or the
>> needs of others, great.  But it would not cover more than a tiny
>> proportion of my projects over the decades - at least not without
>> extra help (extra commands, bash/bat files, etc.)
>>
>

On 31/01/2024 04:23, Kaz Kylheku wrote:
> On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:
>>
>>> * have multiple outputs (some outputs the result of
>>> C compiles, others the result of other tools)
>>
>> Just as an example, the man page for Blender is generated by a Python
>> script that runs the built executable with the “--help” option and wraps
>> that output in some troff markup.
>
> That's the sort of stunt why distros have given up on clean cross
> compiling, and resorted to Qemu.
>

It is also the sort of stunt that reduces development effort and ensures
that you minimise the risk of documentation being out of sync with the
program. I have never tried to build Blender, so I can't comment on
this particular project, but if it is done right then I don't see a big
problem. (If it is done wrong, requiring multiple "make" invocations or
something like that, then it can be annoying.)

For distros trying to make good meta-build systems, something like that
is minor compared to C source files using __DATE__ and __TIME__ (or even
worse, $Id$) to generate version numbers.

On Wed, 31 Jan 2024 08:47:20 +0100
David Brown <david.brown@hesbynett.no> wrote:
> On 31/01/2024 04:23, Kaz Kylheku wrote:
> > On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> >> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:
> >>
> >>> * have multiple outputs (some outputs the result of
> >>> C compiles, others the result of other tools)
> >>
> >> Just as an example, the man page for Blender is generated by a Python
> >> script that runs the built executable with the “--help” option and wraps
> >> that output in some troff markup.
> >
> > That's the sort of stunt why distros have given up on clean cross
> > compiling, and resorted to Qemu.
> >
>
> It is also the sort of stunt that reduces development effort and ensures
> that you minimise the risk of documentation being out of sync with the
> program.

I don't see how it achieves such tasks. For preventing loss of agreement
between behaviour and documentation , the developers must have the necessary
self-discipline to modify the documentation when they make changes in the
behaviour. If they have such self-discipline then it's no harder to modify a
separate documentation file than it is to modify the part of the source code
which prints the --help output. Personally , I have the file(s) with the
documentation as additional tabs in the same vim session where other tabs
have the source code.

Regarding development effort , it's actually more development effort to have
the documentation as source code which prints a message. If it is source code
then you have the usual requirements for good documentation *plus* the
requirement that it is embedded within legal source code in the language you
are writing. If for example the text of the documentation has somewhere a
double quote then you have to take into account whether a double quote has a
special meaning in the programming language you are using (and likely it will
have). If the documentation is a separate file then you don't have this
additional requirement.

Also , the output of --help should be a short reminder whereas
documentation should be longer , possibly much longer , possibly containing a
tutorial , depending on how complex the application is.

> I have never tried to build Blender, so I can't comment on
> this particular project, but if it is done right then I don't see a big
> problem. (If it is done wrong, requiring multiple "make" invocations or
> something like that, then it can be annoying.)

--
vlaho.ninja/menu

On 31/01/2024 03:13, Lawrence D'Oliveiro wrote:
> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:
>
>> * have multiple outputs (some outputs the result of
>> C compiles, others the result of other tools)
>
> Just as an example, the man page for Blender is generated by a Python
> script that runs the built executable with the “--help” option and wraps
> that output in some troff markup.

I do things a bit more simply. The '-help' text for my MCC program is
implemented with this line in the original source:

println strinclude("help.txt")

The help text is just a regular text file. So often you see reams of
printf statements containing strings full of escape codes...

But I can do complex too, if this is what we're trying to show off.

I needed to produce (some time ago...) a printed manual for my
application (CAD software), which contained a mix of text, tables,
images and vector diagrams:

- The text was created with an ordinary text editor

- It incorporated runoff-like commands that I'd devised

- It was processed by a program I'd written in a scripting language.

- That program ran under the application in question

- It rendered it a page at a time, which was then processed by the app's
PostScript driver, then sent it to an actual PostScript printer

- I also wrote the manual

- I also wrote the whole CAD application

- I created both the language used for the app, and the scripting language

- I /implemented/ both languages, one of them in itself

- Oh, and I wrote the text editor!

- I believe this was done pre-Windows, which meant also writing various
drivers for graphics adaptors, all the libraries needed to draw stuff
including GUI, providing bitmap and vector fonts, writing printer and
plotter drivers (of which the PS/EPS driver was one), etc etc

So this was not just orchestrating various bits of pre-existing
software, which makes Unix people feel so superior because they can do:

x | a | b | c > y

instead of (using default file extensions):

a x
b x
c x

On 31/01/2024 12:02, Spiros Bousbouras wrote:
> On Wed, 31 Jan 2024 08:47:20 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> On 31/01/2024 04:23, Kaz Kylheku wrote:
>>> On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:
>>>>
>>>>> * have multiple outputs (some outputs the result of
>>>>> C compiles, others the result of other tools)
>>>>
>>>> Just as an example, the man page for Blender is generated by a Python
>>>> script that runs the built executable with the “--help” option and wraps
>>>> that output in some troff markup.
>>>
>>> That's the sort of stunt why distros have given up on clean cross
>>> compiling, and resorted to Qemu.
>>>
>>
>> It is also the sort of stunt that reduces development effort and ensures
>> that you minimise the risk of documentation being out of sync with the
>> program.
>
> I don't see how it achieves such tasks. For preventing loss of agreement
> between behaviour and documentation , the developers must have the necessary
> self-discipline to modify the documentation when they make changes in the
> behaviour. If they have such self-discipline then it's no harder to modify a
> separate documentation file than it is to modify the part of the source code
> which prints the --help output. Personally , I have the file(s) with the
> documentation as additional tabs in the same vim session where other tabs
> have the source code.

They must document the user-visible features in (at least) two places -
the "man" page, and the "--help" output. By using automation to
generate one of these from the other, they reduce the duplicated effort.

>
> Also , the output of --help should be a short reminder whereas
> documentation should be longer , possibly much longer , possibly containing a
> tutorial , depending on how complex the application is.

The same applies to "man" pages. Sometimes it makes sense to have short
"--help" outputs and longer "man" pages, but if the documentation is
longer than perhaps a dozen pages/screenfuls, "man" is unsuitable. And
I imagine that the documentation for blender, along with its tutorials
(as you say), is many orders of magnitude more than that. Keeping the
"man" page and "--help" output the same seems sensible here.