David Brown <david.brown@hesbynett.no> writes:
>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.

Indeed. In our case, we generate the manpages using nroff and
the simulator 'help' command will call system("man ${INSTALL_LOC}/man/topic.man")
to display the help text. We also process the manpage source files with troff
to generate pages appended to the end of the users guide (troff MOM
macro set) PDF.

Only one place (the manpage source file) need be updated.

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

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

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

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

("-j" engages parallel compilation.)

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

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

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

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

--
-v

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

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

I also had "try:" in my Makefile.

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

try:
_ _ _ _ _ _ _

But I changed the source to make it
explicitely:

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

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

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

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

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

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

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

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

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

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

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

On 29/01/2024 16:03, bart wrote:

> 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

I tried to do a proof of concept today. But there's one problem I'm not
sure how to get around yet. However, the odd behaviour of gcc comes to
the rescue here.

Going with the same 3-file test project, I created this version of the
above:

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

#ifndef __MCC__
#include "runcc.c"

int main(int n, char** args) {
char* compiler = (n>=2 ? args[1] : "tcc");

runcc(compiler, __FILE__);
}
#endif

runcc.c is 100 lines of code, but it is only to test the idea works.

First build this short program with any compiler, here using gcc:

c:\c>gcc demo.c

Now run the a.exe file produced, here shown in two different ways:

c:\c>a
Invoking compiler: tcc -o demo.exe cipher.c hmac.c sha2.c
Finished building: demo.exe

c:\c>a gcc
Invoking compiler: gcc -o demo.exe cipher.c hmac.c sha2.c
Finished building: demo.exe

c:\c>demo
argument count incorrect! ...

It defaults to using tcc to build, but a compiler can be provided as
shown. It wasn't possible to pick up the compiler used to build 'demo.c'.

The main problem is that if demo.c is compiled to demo.exe (the stub
program that reads the #pragmas from demo.c and invokes the compiler),
it is not possible for demo.exe to then build the application as
'demo.exe'; they will clash, Windows doesn't allow it anyway.

So gcc's a.exe helps for this demo.

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

> $ make -j

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

On Wed, 31 Jan 2024 15:13:20 GMT, Scott Lurndal wrote:

> ... and the simulator 'help' command will call system("man
> ${INSTALL_LOC}/man/topic.man")

Agh! Why do people feel the need to go through a shell where a shell is
not needed?

On Wed, 31 Jan 2024 15:31:29 +0100, David Brown wrote:

> ... but if the documentation is
> longer than perhaps a dozen pages/screenfuls, "man" is unsuitable.

So it is your considered opinion, then, that the bash man page is
“unsuitable”?

ldo@theon:~> man bash | wc -l
5276

Actually I refer to it quite a lot. Being able to use search functions
helps.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 31 Jan 2024 15:13:20 GMT, Scott Lurndal wrote:
>
>> ... and the simulator 'help' command will call system("man
>> ${INSTALL_LOC}/man/topic.man")
>
>Agh! Why do people feel the need to go through a shell where a shell is
>not needed?

Because 'system()' works and it a lot less code than
fork and exec?

How would you display an manpage using nroff markup
from an application?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 31 Jan 2024 15:31:29 +0100, David Brown wrote:
>
>> ... but if the documentation is
>> longer than perhaps a dozen pages/screenfuls, "man" is unsuitable.
>
>So it is your considered opinion, then, that the bash man page is
>“unsuitable”?
>
> ldo@theon:~> man bash | wc -l
> 5276
>
>Actually I refer to it quite a lot. Being able to use search functions
>helps.

When working with the ksh man page, I use vim.

function viman
{ a=$(mktemp absXXXXXXX)
man "$1" | col -b > ${a}
vim ${a}
rm ${a}
}

$ viman ksh

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"))
)

On 1/30/2024 11:36 PM, David Brown wrote:
> 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.
[...]

Ahhh, thanks David.

On 1/30/2024 7:14 PM, Lawrence D'Oliveiro wrote:
> 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.

Some people like apples, others might like oranges?

On Wed, 31 Jan 2024 23:00:58 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <upejfa$1nil8$1@dont-email.me>:

> On Wed, 31 Jan 2024 15:13:20 GMT, Scott Lurndal wrote:
>
>> ... and the simulator 'help' command will call system("man
>> ${INSTALL_LOC}/man/topic.man")
>
> Agh! Why do people feel the need to go through a shell where a shell is
> not needed?

In my case: it wasn't so much of a "need" -- more of a "want". :)

Generally, I'd agree with you; but let's say Programmer Joe decides to
change his path to run his own special version of make(1). (Maybe he's on
an ancient SunOS system with gnu make in (say) /opt/gnu/bin. You know --
weird Unix stuff.)

So who are we to decide "no gnus allowed"?

Okay, maybe that's a weak example -- but
yes, I wouldn't use system(3) in any program
that needs to be very specific about what it passes
on to its children. (I wouldn't -- but someone else might.)

--
-v

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:
>>
>> 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.

This statement was also to me an initiator of some neurons firing
and make me recall the development processes we used (in some large
projects, not in one-man-shows)...

>
> 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.

This self-discipline can be supported by tools. If we had to change
things (due to feature request or bug) we opened a 'feature or bug
request', established a 'track' and associated some 'fix-records'
to the track. The 'request' contained the description, requirements,
or specification, the individual 'fix-records' were, e.g., for code,
or documentation, or dependent parts, and separately assigned.
A (typical?) method to organize things and not forget an important
step or product part.

(Note: The used 'keywords' are approximations and may not actually
match the tool's literals.)

> 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.
>
> [...]

Janis

On 31.01.2024 15:31, David Brown wrote:
> On 31/01/2024 12:02, Spiros Bousbouras wrote:

> 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.

Ksh93 has chosen an interesting path here; they have a powerful getopts
command (to parse the command line options), and have extended the well
known simple option-string format to allow to specify with actually an
own language all about options (type, defaults, forms, purpose, etc.).
This allows an automated generation of output in some forms (HTML, man,
etc.) with every command that uses ksh93 getopts to parse the options
(try 'getopts --man' [in ksh93] for details).

There are a couple approaches (Eiffel extracts some properties inherent
to the language from the source, Javs extracts user defined doxygen
entries, etc.).

Janis

On 01.02.2024 01:33, Scott Lurndal wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 31 Jan 2024 15:31:29 +0100, David Brown wrote:
>>
>>> ... but if the documentation is
>>> longer than perhaps a dozen pages/screenfuls, "man" is unsuitable.
>>
>> So it is your considered opinion, then, that the bash man page is
>> “unsuitable”?
>>
>> ldo@theon:~> man bash | wc -l
>> 5276
>>
>> Actually I refer to it quite a lot. Being able to use search functions
>> helps.
>
> When working with the ksh man page, I use vim.
>
> function viman
> {
> a=$(mktemp absXXXXXXX)
> man "$1" | col -b > ${a}
> vim ${a}
> rm ${a}
> }
>
>
> $ viman ksh
>

In some modern shells (ksh, bash, zsh) you may use process substitution
and avoid creating a temporary file (it simplifies things)...

vim <(man "$1" | col -b)

Janis

On 31/01/2024 00:46, Tim Rentsch wrote:
> 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.

> 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),

So, will a specific build of such a project produce a single EXE/DLL//SO
file? (The // includes the typical file extension of Linux executables.)

This is all I want for a build.

I guess if you wrote your program in a language XXX that provided this
build process for example:

xxxc -build leadmodule.xxx

you would find it equally unusable because it doesn't provide the
flexibility you're accustomed to from the chaotic, DIY nature of your
current methods.

The idea is that you have a a tool that provides the basic build process
as illustrated with the xxxc example, and you superimpose any custom
requirements on top of that, making use of whatever customisation
abilities it does provide.

An analogy would be switching to a language that doesn't have C's
preprocessor. If your coding style depends on macros that yield random
bits of syntax, or to use conditional blocks to arbitrarily choose which
lines to process, then you can also dismiss it as unusable.

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"))
> )

WTF?

You are aware you are posting to comp.lang.c, right?

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

Sure. Programming languages need that if they are to scale at all.

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

Okay.

But what you are talking about to add to C is item 7, nothing more.
That is not adding "modules" to C. Your suggestion might be useful to
some people for some projects, but that doesn't make it "modules" in any
real sense.

>
> While for 6, there is only a hierarchy between groups of modules, each
> forming an independent sub-program or library. I tried a strict full
> per-module hierarchy early on, mixed up with independent compilation; it
> worked poorly.
>
> The two levels allow you to assemble one binary out of groups of modules
> that each represent an independent component or library.
>
> > Compiled
> > languages don't usually have such a thing, because developers (as
> > distinct from users) have build tools available that do a better job.
>
> Given a module scheme, the tool needed to build a whole program should
> not need to be told about the names and location of every constituent
> module; it should be able to determine that from what's already in the
> source code, given only a start point.

Why?

You can't just take some idea that you like, and that is suitable for
the projects you use, and assume it applies to everyone else.

I have no problem telling my build system, or compilers, where the files
are. In fact, I'd have a lot of problems if I couldn't do that. It is
not normal development practice to have the source files in the same
directory that you use for building the object code and binaries.

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

I already have tools for determining dependencies. What can your
methods do that mine can't?

(And don't bother saying that you can do it without extra tools -
everyone who wants "make" and "gcc" has them on hand. And those who
want an IDE that figures out dependencies for them have a dozen free
options there too. These are all standard tools available to everyone.)

>
> My view is that that tool only needs to be the compiler (a program that
> does the 'full stack' from source files to executable binary) working
> purely from the source code.
>
> Yours is to have compilers, assemblers, linkers and make programs,
> working with auxiliary data in makefiles, that itself have to be
> generated by extra tools or special options, or built by hand.
>

You want a limited little built-in tool. I want a toolbox that I can
use in all sorts of ways - for things you have never imagined. I can
see how your personal tools can be useful for you, as a single developer
on your own - if you want something else you can add it to those tools.
For others, they are useless.

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.

You are offering me a fish. I am offering to teach you to fish,
including where to go to catch different kinds of fish. This is really
a no-brainer choice.

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

We know that. Otherwise it would have happened, long ago.

On 01/02/2024 15:29, bart wrote:
> On 31/01/2024 00:46, Tim Rentsch wrote:

>
> > 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),
>
> So, will a specific build of such a project produce a single EXE/DLL//SO
> file? (The // includes the typical file extension of Linux executables.)
>
> This is all I want for a build.

I my current project, when I run "make" it builds 5 different
executables, each in three formats with different post-processing by
other programs (not the compiler or linker). Most of my projects have
fewer, but four or five outputs is not at all uncommon. It is also
common that a few of the source files are generated by other programs as
part of the build. So if I have an embedded web server in the program,
I can change an html file and "make" will result in that being in the
encrypted download image ready for deployment.

Your tools can't do what I need for a lot of my work. Maybe they could
be useable for some projects or programs. But why would I bother with
them when I already need more serious and flexible tools for other
things, already have these better tools, and those better tools work
simply and easily for the simple and easy projects that your ones could
handle?

On 31/01/2024 20:25, bart wrote:
> BTW that 'make' only works on my machine because it happens to be part
> of mingw; none of my other C compilers have make.
>
> And as written, it only works for 'cc' which comes with 'gcc'

Doesn't dos/windows have nmake and cl?