On 2024-02-01, David Brown <david.brown@hesbynett.no> wrote:
> 5. Modules provide encapsulation of data, code and namespaces.

Case study: C++ originally had only classes which provie this. Then it
acquired the namespace construct which also provides it.. In spite of
that, someone decided it needs modules also.

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

On 01/02/2024 16:09, Richard Harnden wrote:
> 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?

No.

On 01/02/2024 15:11, David Brown wrote:
> 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.
>

Our system is that we've got two types of source generated by us, the
libraries which are used by all the programs, and the code specific to
each program. The library source code is placed on a central server and
then downloaded by conan (a package manager) which keeps it in a private
directory in the local machine not intended for viewing. The source
specific to the program is placed in a git project and synchronised with
git's remote repository facilities. Then IDE project files are built
with CMake. These with various other derived bits and bobs are placed in
a build folder, which is always under the git repository, but placed in
the ignore file and so not under git source control. The IDE is then
invoked on the project file in the build directory, and the executables
also go into the build directory. They then need to be moved to a
different location to be run.
CMake is set up so that it recursively crawls the source directories and
places every single source file into the IDE project file. This isn't
really recommended but it means you don't have to maintain CMakeLists files.
So it's an out of tree build. But we can't just place source in some
random location on the local machine and tell the system to pull it in.
Technically you could modify the CMake script to do that. But it would
break the whole system.

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

On 01/02/2024 15:11, David Brown wrote:

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

Item 7 is my biggest stumbling to building open source C projects.

While the developer (say you), knows the necessary info, and can somehow
import into the build system, my job is trying to get it out.

I can't use the intended build system because for one reason or another
it doesn't work, or requires complex dependencies (MSYS, CMake, MSTOOLS,
..configure), or I want to run mcc on it.

That info could trivially be added to the C source code. Nobody actually
needs to use my #pragma scheme; it could simply be a block comment on
one of the modules.

I'm sure with all your complicated tools, they could surely dump some
text that looks like:

// List of source files to build the binary cipher.c:
// cipher.c
// hmac.c
// sha2.c

and prepend it to one of the files. Even a README will do.

That wouldn't hurt would it?

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

So, if C were to acquire modules, so that a C compiler could determine
that all for it itself (maybe even work out for itself which need
recompiling), would you just ignore that feature and use the same
auxiliary methods you have always done?

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.

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

Maybe you think makefiles should individually list all the 1000s of
functions of a project too?

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

That analogy makes no sense.

Let me try and explain what I do: I write whole-program compilers. That
means that, each time you do a new build, it will reprocess each file
from source. They use the language's module scheme to know which files
to process.

I tend to build C programs by recompiling all modules too. So I want to
introduce the same convenience I have elsewhere.

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.

----------------------------
(Repost)

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.

bart <bc@freeuk.com> writes:
>On 01/02/2024 16:09, Richard Harnden wrote:
>> 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?
>
>No.

You sure about that? They sure used to have them
as an add-on. IIRC, they're still part of visual studio.

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

Agreed, but there might not be a sufficiently portable way to determine
that number.

--
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 19:25, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 01/02/2024 16:09, Richard Harnden wrote:
>>> 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?
>>
>> No.
>
> You sure about that? They sure used to have them
> as an add-on. IIRC, they're still part of visual studio.

Visual Studio is a 10,000MB monster. It might well have it around, but
it's so complex, it's been years since I've even seen discrete cl.exe
and link.exe programs, despite scouring massive, 11-deep directory
structures.

Meanwhile my everyday compilers are 0.4MB for my language and 0.3MB for C.

I like to keep things simple. Everybody else likes to keep things
complicated, and the more the better.

Anyway, acquiring VS just to build one small program would be like just
a giant sledgehammer, 1000 times normal size, to crack a tiny nut.

On 2/1/2024 11:51 AM, bart wrote:
> On 01/02/2024 19:25, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 01/02/2024 16:09, Richard Harnden wrote:
>>>> 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?
>>>
>>> No.
>>
>> You sure about that?  They sure used to have them
>> as an add-on.  IIRC, they're still part of visual studio.
>
> Visual Studio is a 10,000MB monster.

Shit happens. I still use MSVC, quite a lot actually. I install
everything! ;^) Have the space, so, well, okay. ;^)

> It might well have it around, but
> it's so complex, it's been years since I've even seen discrete cl.exe
> and link.exe programs, despite scouring massive, 11-deep directory
> structures.
>
> Meanwhile my everyday compilers are 0.4MB for my language and 0.3MB for C.
>
> I like to keep things simple. Everybody else likes to keep things
> complicated, and the more the better.
>
> Anyway, acquiring VS just to build one small program would be like just
> a giant sledgehammer, 1000 times normal size, to crack a tiny nut.

On Thu, 1 Feb 2024 18:34:08 +0000
bart <bc@freeuk.com> wrote:

> On 01/02/2024 15:11, David Brown wrote:
>
> >>> 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.
>
> Item 7 is my biggest stumbling to building open source C projects.
>
> While the developer (say you), knows the necessary info, and can
> somehow import into the build system, my job is trying to get it out.
>
> I can't use the intended build system because for one reason or
> another it doesn't work, or requires complex dependencies (MSYS,
> CMake, MSTOOLS, .configure), or I want to run mcc on it.
>
> That info could trivially be added to the C source code. Nobody
> actually needs to use my #pragma scheme; it could simply be a block
> comment on one of the modules.
>
> I'm sure with all your complicated tools, they could surely dump some
> text that looks like:
>
> // List of source files to build the binary cipher.c:
> // cipher.c
> // hmac.c
> // sha2.c
>
> and prepend it to one of the files. Even a README will do.
>
> That wouldn't hurt would it?
>
> >> 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.)
>
> So, if C were to acquire modules, so that a C compiler could
> determine that all for it itself (maybe even work out for itself
> which need recompiling), would you just ignore that feature and use
> the same auxiliary methods you have always done?
>
> 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.
>
>
> > 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.
>
> Maybe you think makefiles should individually list all the 1000s of
> functions of a project too?
>
> > 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.
>
> That analogy makes no sense.
>
> Let me try and explain what I do: I write whole-program compilers.
> That means that, each time you do a new build, it will reprocess each
> file from source. They use the language's module scheme to know which
> files to process.
>
> I tend to build C programs by recompiling all modules too. So I want
> to introduce the same convenience I have elsewhere.
>
> 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.
>
> ----------------------------
> (Repost)
>
> 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.
>

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

On Thu, 1 Feb 2024 19:51:53 +0000
bart <bc@freeuk.com> wrote:

> On 01/02/2024 19:25, Scott Lurndal wrote:
> > bart <bc@freeuk.com> writes:
> >> On 01/02/2024 16:09, Richard Harnden wrote:
> >>> 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?
> >>
> >> No.
> >
> > You sure about that? They sure used to have them
> > as an add-on. IIRC, they're still part of visual studio.
>
> Visual Studio is a 10,000MB monster. It might well have it around,
> but it's so complex, it's been years since I've even seen discrete
> cl.exe and link.exe programs, despite scouring massive, 11-deep
> directory structures.
>

If you only download command-line build tools then it's somewhat less
huge.
2022 version is 3,152,365,436 bytes.
I don't know the size of installation package. It looks like on my home
PC I used online installer.

> Meanwhile my everyday compilers are 0.4MB for my language and 0.3MB
> for C.
>
> I like to keep things simple. Everybody else likes to keep things
> complicated, and the more the better.
>
> Anyway, acquiring VS just to build one small program would be like
> just a giant sledgehammer, 1000 times normal size, to crack a tiny
> nut.

On 2/1/2024 12:12 PM, Chris M. Thomasson wrote:
> On 2/1/2024 11:51 AM, bart wrote:
>> On 01/02/2024 19:25, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 01/02/2024 16:09, Richard Harnden wrote:
>>>>> 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?
>>>>
>>>> No.
>>>
>>> You sure about that?  They sure used to have them
>>> as an add-on.  IIRC, they're still part of visual studio.
>>
>> Visual Studio is a 10,000MB monster.
>
> Shit happens. I still use MSVC, quite a lot actually. I install
> everything! ;^) Have the space, so, well, okay. ;^)

The fat bastard wants me to update to version (17.8.6). I currently have
(17.8.5):

:^)

https://youtu.be/t2mU6USTBRE?t=94

Ham On! LOL! ;^)

>
>
>
>> It might well have it around, but it's so complex, it's been years
>> since I've even seen discrete cl.exe and link.exe programs, despite
>> scouring massive, 11-deep directory structures.
>>
>> Meanwhile my everyday compilers are 0.4MB for my language and 0.3MB
>> for C.
>>
>> I like to keep things simple. Everybody else likes to keep things
>> complicated, and the more the better.
>>
>> Anyway, acquiring VS just to build one small program would be like
>> just a giant sledgehammer, 1000 times normal size, to crack a tiny nut.
>

Michael S <already5chosen@yahoo.com> writes:
>On Thu, 1 Feb 2024 18:34:08 +0000
>bart <bc@freeuk.com> wrote:
>
>> On 01/02/2024 15:11, David Brown wrote:

>> But you may still need makefiles to deal with (3).
>>=20
>> If your main requirement /is/ only (1), then my idea is to move the=20
>> necessary info into the source code, and tackle it with the C
>> compiler.
>>=20
>
>
>You proposal and needs of David Brown are not necessarily
>contradictory.=20

Although David (and I) aren't particularly interested in
changing something that already works quite well.

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

I suspect he may be much more difficult to satisfy on this topic.

Nobody is going to switch production software to a one-off
unsupported compiler.

On 2/1/2024 12:55 PM, Scott Lurndal wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Thu, 1 Feb 2024 18:34:08 +0000
>> bart <bc@freeuk.com> wrote:
>>
>>> On 01/02/2024 15:11, David Brown wrote:
>
>>> But you may still need makefiles to deal with (3).
>>> =20
>>> If your main requirement /is/ only (1), then my idea is to move the=20
>>> necessary info into the source code, and tackle it with the C
>>> compiler.
>>> =20
>>
>>
>> You proposal and needs of David Brown are not necessarily
>> contradictory.=20
>
> Although David (and I) aren't particularly interested in
> changing something that already works quite well.
>
>> 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.
>
> I suspect he may be much more difficult to satisfy on this topic.
>
> Nobody is going to switch production software to a one-off
> unsupported compiler.
>

No shit. Even then, he would have to test drive it, make sure it passes
all unit tests, ect... How fun... ;^)

On Thu, 1 Feb 2024 09:39:15 +0100, David Brown wrote:

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

In our Comp Sci classes we were careful to draw a distinction between
“separate” and “independent” compilation. The latter is exemplified by
(old-style) Fortran and C, where the same name may be declared in multiple
units, and the linker will happily tie them together, but without any
actual checking that the declarations match.

“Separate” compilation, on the other hand, means that there is some
consistency checking done between the declarations, and the program will
fail to build if there are mismatches. Ada has this. And it looks like
Fortran has acquired it, too, since the Fortran 90 spec.

On 01/02/2024 19:34, bart wrote:
> On 01/02/2024 15:11, David Brown wrote:
>
>>>> 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.
>
> Item 7 is my biggest stumbling to building open source C projects.
>
> While the developer (say you), knows the necessary info, and can somehow
> import into the build system, my job is trying to get it out.
>
> I can't use the intended build system because for one reason or another
> it doesn't work, or requires complex dependencies (MSYS, CMake, MSTOOLS,
> .configure), or I want to run mcc on it.
>
> That info could trivially be added to the C source code. Nobody actually
> needs to use my #pragma scheme; it could simply be a block comment on
> one of the modules.
>
> I'm sure with all your complicated tools, they could surely dump some
> text that looks like:
>
>    // List of source files to build the binary cipher.c:
>    // cipher.c
>    // hmac.c
>    // sha2.c
>
> and prepend it to one of the files.  Even a README will do.
>
> That wouldn't hurt would it?

Complain to the people that made that open source software, not me. But
don't be surprised if they tell you "There's a makefile. It works for
everyone else." Or maybe they will say they can't cater for every
little problem with everyone's unusual computer setup. Maybe they will
try to be helpful, maybe they will be rude and arrogant. Maybe they
will point out that their makefile /is/ just a list of the files needed,
along with the compiler options. Usually projects of any size /do/ have
readme's and build instructions - but some won't.

No matter what, it is not the fault of anyone here, it is not the fault
of "make" or Linux or C, and there is nothing that any of us can do to
help you. (And $DEITY knows, we have tried.)

>>
>> 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.)
>
> So, if C were to acquire modules, so that a C compiler could determine
> that all for it itself (maybe even work out for itself which need
> recompiling), would you just ignore that feature and use the same
> auxiliary methods you have always done?

That's not unlikely. Why would I change? You still haven't given any
reasons why your tools would be /better/. Even if they could do all I
needed to do for a particular project, "just as good" is not "better",
and does not encourage change.

I would still need "make" for everything else. I would, however, be
quite happy if there were some standard way to get the list of include
files needed by a C file, rather than using gcc-specific flags.

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

>
>
>> 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. Compiling is the job of the compiler.
Controlling the build is the job of the build system. I don't see
monolithic applications as an advantage.

>
> Maybe you think makefiles should individually list all the 1000s of
> functions of a project too?
>
>> 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.
>
> That analogy makes no sense.
>
> Let me try and explain what I do: I write whole-program compilers. That
> means that, each time you do a new build, it will reprocess each file
> from source. They use the language's module scheme to know which files
> to process.

Surely most sensibly organised projects could then be built with :

bcc *.c -o prog.exe

I mean, that's what I can do with gcc if I had something that doesn't
need other flags (which is utterly impractical for my work).

Or if I had lots of files, each with their own c file :

for f in *.c; do gcc $i -o ${f%.c}; done

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

I do a round of checking the state of the art of build tools on a
regular basis - perhaps every year or so. I look at what's popular and
what's new, to see if there's anything that would work for me and be a
step up from what I have. So far, I've not found anything that comes
very close to "make" for my needs. There's some tools that are pretty
good in many ways, but none that I can see as being a better choice for
me than "make". I am, however, considering CMake (which works at a
higher level, and outputs makefiles, ninja files or other project
files). 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. I'll need some time to investigate and
study it.

On 01/02/2024 21:23, Michael S wrote:
> On Thu, 1 Feb 2024 18:34:08 +0000

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

On Thu, 01 Feb 2024 11:49:36 -0800, Keith Thompson wrote:

> David Brown <david.brown@hesbynett.no> writes:
>
>> 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.
>
> Agreed, but there might not be a sufficiently portable way to determine
> that number.

nproc(1) is part of the GNU Core Utilities
<manpages.debian.org/1/nproc.1.html>.

On 01/02/2024 17:09, Richard Harnden wrote:
> 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?

Those are part of MSVC, which runs on Windows but does not come with it.
"nmake" is MS's version of "make", and has been shipped with most MS
development tools for many decades.

On 01/02/2024 20:49, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> 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.
>
> Agreed, but there might not be a sufficiently portable way to determine
> that number.
>

gcc manages to figure it out for parallel tasks, such as LTO linking. I
think it would be reasonable enough to have it use the number of cores
when it was able to figure it out, and a default (say, 4) when it could not.

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.

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.

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.

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

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

Linking would only come up for me if I wanted to statically combine the
outputs of several languages. Since I can't process object files, I need
to generate an object file (in my case, it represents ALL my modules),
and a traditional linker. That would be someone else's job.

>  Compiling is the job of the compiler.
> Controlling the build is the job of the build system.  I don't see
> monolithic applications as an advantage.

I do. You type:

cc prog

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

In any case, your linker will generate a monolithic binary whether you
like it or not.

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

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

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

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

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

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.

>>
>> Maybe you think makefiles should individually list all the 1000s of
>> functions of a project too?
>>
>>> 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.
>>
>> That analogy makes no sense.
>>
>> Let me try and explain what I do: I write whole-program compilers.
>> That means that, each time you do a new build, it will reprocess each
>> file from source. They use the language's module scheme to know which
>> files to process.
>
> Surely most sensibly organised projects could then be built with :
>
>     bcc *.c -o prog.exe
>
> I mean, that's what I can do with gcc if I had something that doesn't
> need other flags (which is utterly impractical for my work).

Yes, that's one technique that can be used. But few projects are like
that one. One or two, you can try *.c and it will work.

Malcolm's resource compiler is like that, but it still benefits from a
file like this:

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

here called bbx.c. I can build it like this:

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

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

BUT IT DOESN'T. It fails a lot of the time on Windows, but they are too
complicated to figure out why. From a recent thread I made about trying
to build piet.c, it failed on extra programs that weren't needed (that
was on Linux; it didn't work at all on Windows).

This is a program which actually only needed:

cc piet.c

(Here cc *.c wouldn't work.) This mirrors pretty much what I see in most
C projects; needless complexity that muddies the waters and creates
failures.

ALL I WANT IS A LIST OF FILES. Why doesn't anybody get that? And why is
it so hard?

Apparently makefiles are superior because you don't even need to know
the name of the program (and will have to hunt for where it put the
executable because it won't tell you!).

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

(Look at the Monty Hall problem, but instead of 3 doors, try it with
100, of which 98 will be opened. Then it will easy to make the right
decision because nearly all the wrong ones have been eliminated.)

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 11:49:36 -0800, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> 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.
>>
>> Agreed, but there might not be a sufficiently portable way to determine
>> that number.
>
> 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. Also, nproc was added to GNU Coreutils in 2009, and the
current meaning of "make -j" with no numeric argument was defined before
that.

A new "-J" option that means "-j $(nproc)" might be useful, but it's
easy enough to use "make -j $(nproc)".

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

bart <bc@freeuk.com> writes:
[...]
> As I said, C's uses of .h and .c files are chaotic.

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

It's fairly straightforward to implement something similar to "modules"
in C, using matching *.h and *.c files, include guards, and so forth,
but it requires a bit of discipline. It's a mechanism built on top of
the language, not a feature of the language itself (though of course the
language definition intentionally supports that usage).

Some projects might use .h and .c files in a chaotic manner. Most, in
my experience, do not.

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

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

On Fri, 2 Feb 2024 00:55:38 +0200, Michael S wrote:

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

And maybe you discover bugs in them in certain situations, and have to
track down all the places you copied/pasted them and fix them.

My code-reuse OCD reflex is twitching at this point.