On 11/08/2023 17:53, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 11/08/2023 16:39, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 11/08/2023 14:32, Scott Lurndal wrote:
>>
>>>>> Perhaps it is time to simply stop responding to Bart when he continues
>>>>> to make such silly statements.
>>>>
>>>> What exactly is silly about it? Isn't that what is being said or not?
>>>
>>> Nobody has told you what you're allowed to have in your directories.
>>>
>>
>> So I must have misunderstood these comments:
>
>
> Yes, you did. As always.

So what do they mean?

Can I still usefully do gcc -MM *.c if I ignore that advice?

>>
>> RH: Then you have too many unrelated things in that directory.
>>
>> BC: That happens.
>>
>> SL: No, it doesn't. Except, perhaps to you.
>>
>> DB: Put the files of a project in a directory. Delete the junk.

piątek, 11 sierpnia 2023 o 18:45:26 UTC+2 Kalevi Kolttonen napisał(a):
> Scott Lurndal <sc...@slp53.sl.home> wrote:
> > Nobody is telling Bart "exactly what they're allowed
> > to have in their folders". That's just nonsense.
> Agreed. It is total nonsense, because nobody has made
> such claims.
>
> This thread is so long that I may have lost track
> already, but I suppose Bart does not want to
> create subdirectories. Instead he has a single
> directory, perhaps called "c" and all his not so
> important small C programs get dumped there.
>
> So his main directory contents probably look something
> like this:
>
> do-one-thing.c
> do-another-thing.c
> do-third-thing.c
> [ and so on ]
>
> I do not undestand why Bart cannot simply do:
>
> mkdir do-one-thing do-another-thing do-third-thing
> mv do-one-thing.c do-one-thing
> mv do-another-thing.c do-another-thing
> mv do-third-thing.c do-third-thing
> [ and so on ]
>
> So the directory hierarchy would be:
>
> c/do-one-thing
> c/do-another-thing
> c/do-third-thing
>
> and all the C programs would be contained in self-documenting
> subdirectories.
>
> For some unknown reason Bart wants to keep all the unrelated
> C files in the one directory. Have I undestood this right?
>
> br,
> KK

bartc seem to be a fan of parctical simplicity and he is totally right in that aspect imo (not reading into that particular case as i got other things to do)
i hovever keep code in subdirectories, but even thiose subdirectories you could have tens..
this layer of managing source is overcomplicated as it should as it was already talked... im a fan of totakl commander and imo given.c source probably should compile to dll simply if you press enter on it, and compile to exe also if you press enter on it and it have "main" method

that should be a rule so no weird build system and trash

(this makes a problem you cant divide such c files on parts having large files
becouse if you would divide it couldnt compile unles having reference to its other parts (two-direction references, part should know the container) but there is
a way of dealing with this, else adding thsi reference or ignore or eventually
rename such included partswith other extension, or other way eventually also compile toi some .o partial format

On 11/08/2023 17:45, Kalevi Kolttonen wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Nobody is telling Bart "exactly what they're allowed
>> to have in their folders". That's just nonsense.
>
> Agreed. It is total nonsense, because nobody has made
> such claims.
>
> This thread is so long that I may have lost track
> already, but I suppose Bart does not want to
> create subdirectories. Instead he has a single
> directory, perhaps called "c" and all his not so
> important small C programs get dumped there.

Yes, exactly.

Actual applications get their own directory. But generally I don't use C
for those. I use my private language with a module system which can
discover all the modules of a project without needing to segregate
project-related files from anything else.

It mainly happens with C applications that have been downloaded, and
there, ones that have .c and .h files scattered over a dozen nested
directories are a complete PITA. Given that the supplied build process
on Windows rarely works so I end up doing the chasing around.

Of course, any C programs *I* supply are designed to be as easy to build
as `hello.c`. And on Windows that is achievable:

c:\qx>gcc qc.c -oqq
c:\qx>qq hello
Hello, World! 11-Aug-2023 18:24:54

qc.c is a 43Kloc C source file implementing an interpreter (transpiled
from non-C source code in 30+ modules).

On Linux, it would be something like this:

gcc qc.c -oqq -lm -ldl -fno-builtin
./qq hello

Now, please tell me what is the point of creating a subdirectory to
contain only the one file. Or indeed, what is the point of using 'make'
in this case.

All that's needed is a compiler, and the one source file; three as we
all know is a crowd.

> For some unknown reason Bart wants to keep all the unrelated
> C files in the one directory. Have I undestood this right?

I use folders to represent different projects. I don't take that
structuring to the extreme as many do. I've seen Github projects use a
dozen or two directories, each one has only one file, and the total,
initially imposing application turns out to be a 300-line toy program.

It's just 10 times harder to study, understand and build.

On 11/08/2023 18:15, Bart wrote:
> On 11/08/2023 17:53, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 11/08/2023 16:39, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 11/08/2023 14:32, Scott Lurndal wrote:
>>>
>>>>>> Perhaps it is time to simply stop responding to Bart when he
>>>>>> continues
>>>>>> to make such silly statements.
>>>>>
>>>>> What exactly is silly about it? Isn't that what is being said or not?
>>>>
>>>> Nobody has told you what you're allowed to have in your directories.
>>>>
>>>
>>> So I must have misunderstood these comments:
>>
>>
>> Yes, you did.  As always.
>
> So what do they mean?
>
> Can I still usefully do gcc -MM *.c if I ignore that advice?
>

BTW no one has commented on my own build scheme for C that I've
mentioned a few times.

So I have a program 'pidemo.c' which if I try and build it like this:

bcc pidemo

it reports some undefined functions. It needs a library which exists in
one or more extra .c files. Which ones? Well, why not let it discover
them for itself:

c:\c>bcc -auto pidemo
1 Compiling pidemo.c to pidemo.asm (Pass 1)
* 2 Compiling bignum.c to bignum.asm (Pass 2)
Assembling to pidemo.exe

So you can takes your 'gcc -MM *.c', which requires hygienically clean
directories, and shove it wherever the hell you like.

My demo was run inside that folder with 260 assorted 'junk' C files. Magic!

On 11/08/2023 14:32, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 11/08/2023 07:43, David Brown wrote:
>>> On 09/08/2023 16:07, Bart wrote:
>>>> On 09/08/2023 14:32, Richard Harnden wrote:
>>>> > On 09/08/2023 13:32, Bart wrote:
>>>> >> Yes, that is one reason that it is so complicated. You have to
>> define
>>>> >> set of dependences between modules (and you may need to do that
>>>> >> manually, so it can be error prone).
>>>> >
>>>> > $ gcc -MM *.c
>>>>
>>>> I have a small, 3-file project (one of Chris's) comprising files
>>>> cipher.c, sha2.c, hmac.c
>>>>
>>>> gcc -MM cipher.c outputs:
>>>>
>>>> cipher.o: cipher.c hmac.c sha2.h
>>>>
>>>> I need to do -MM cipher.c hmac.c sha2.c for it to show:
>>>>
>>>> cipher.o: cipher.c hmac.h sha2.h
>>>> hmac.o: hmac.c hmac.h sha2.h
>>>> sha2.o: sha2.c sha2.h
>>>>
>>>> So I had to tell it the C files. I can't do *.c, as there are 259
>>>> other .c files in the folder.
>>>>
>>>
>>> There's this wonderful organisation technique for files called
>>> "directories". They even exist in Windows.
>>>
>>> Put the files of a project in a directory. Delete the junk. Then you
>>> can find your files, and you can use "gcc -MM *.c". It even works if
>>> you have multiple different programs - it simply generates dependency
>>> information so you know which C files need re-compiled when headers are
>>> changed.
>>>
>>> But of course when someone gives you help or answers your questions,
>>> you'd rather complain more.
>>>
>>
>> So you're telling people exactly what they're allowed to have in their
>> folders and what they're not.
>
> Perhaps it is time to simply stop responding to Bart when he continues
> to make such silly statements.

I think he's being wrong on purpose. Or just for effect.

If I tar xvzf project-version.tgz,
I expect it to go into ./project-version

If I git clone project,
I expect it to go into ./project

To have everything end up in once directory takes effort.

On 2023-08-11, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>On 2023-08-11, Spiros Bousbouras <spibou@gmail.com> wrote:
>>> On Thu, 10 Aug 2023 16:15:32 -0000 (UTC)
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>> What we could have is that an executable just dynamically links to
>>>> functions in these libraries, and the system automatically finds them at
>>>> load time, without the executable having to specify which libraries. >>>
>>> And how is your scheme different than how it already works in the Unix
>>> world ?
>>
>>How it differs is that the executable has to nominate the specific
>>libraries by indicating the library, which came in via the -l option,
>>and then look for specific symbols from specific libraries that it has
>>attached.
>>
>>Under the hood, the semantics is much like dlopen() of specific
>>liraries to obtain a handle and then doing dlsym(handle, "name")
>>to look for specific names from specific libs.
>>
>>Imagine it could specify just symbols, without specifying where
>>they come from; that's a big difference.
>
> Would this not require that no symbol be present in more than
> one library, i.e. that there is a single symbol namespace across the
> entire system?
>
> That would seem to be a non-starter.

I sort of addressed that in the parts that were snipped above.
We also have the problem that multiple versions of the same library
can exist (or multiple version nodes within the same library).

There would have to be some mechanism to bind the visible,
simple symbols to unique identities under the hood.

E.g the <stdio.h> header could have some magic so that
when you include it and call puts, a complex symbolic reference
is generated under the hood and imbued into the resulting
executable.

Insert other handwaving as necessary.

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

Bart <bc@freeuk.com> wrote:
> Now, please tell me what is the point of creating a subdirectory to
> contain only the one file. Or indeed, what is the point of using 'make'
> in this case.

Sorry, I really haven't followed this thread with that
great interest or mental concentration. I am only guessing
here but I suppose you wanted to do something like:

gcc *.c

and that fails because your main directory contains over
250 C source files. If you put them into their own
subdirectories, you would need:

cd subdir
gcc *.c

Maybe I have misunderstood something, but this discussion
seems pretty insane.

br,
KK

Bart <bc@freeuk.com> writes:
[...]
> Now, please tell me what is the point of creating a subdirectory to
> contain only the one file. Or indeed, what is the point of using
> 'make' in this case.
[...]

You have more than enough information to figure out what works best
for you. Just do that.

If you don't want to use make, don't use make. If you don't want
to create subdirectories, don't create subdirectories.

Some people in this thread have made the mistake of offering
you advice. That never ends well. Most people, if they say that
something is not working well for them, are implicitly asking for
better alternatives. That doesn't seem to be the case for you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 11/08/2023 21:33, Kalevi Kolttonen wrote:
> Bart <bc@freeuk.com> wrote:
>> Now, please tell me what is the point of creating a subdirectory to
>> contain only the one file. Or indeed, what is the point of using 'make'
>> in this case.
>
> Sorry, I really haven't followed this thread with that
> great interest or mental concentration. I am only guessing
> here but I suppose you wanted to do something like:
>
> gcc *.c
>
> and that fails because your main directory contains over
> 250 C source files. If you put them into their own
> subdirectories, you would need:
>
> cd subdir
> gcc *.c
>
> Maybe I have misunderstood something, but this discussion
> seems pretty insane.

I mentioned something about needing to manually write dependencies
inside makefiles.

Somebody said you can get gcc to do that with 'gcc -MM *.c'.

I then said then you'd need a clean directory with only those exact
files present.

And this is when a ton of bricks were heaped upon me by numerous posters.

Apparently the idea of having two .c files in the same folder, that
belong to different programs, is anathema.

I had thought that -MM was some clever option where gcc can crawl
through dependencies discovering the necessary files needed for a
project (a bit like the -auto experimental feature in my own compiler).

But apparently not. Either you to have submit the exact files required,
or marshall them into a dedicated folder and do *.c.

Either way, 'make' is not something I will ever use, and it was a
throwaway remark. I only come across makefiles when they are the only
way to get information about building an open source project, since
simply listing the .c files needed would be too easy.

However I wouldn't be averse to just doing gcc *.c as the build process.
And here, for a specially created distribution for other people to use,
it makes sense to ensure only the relevant files for the project are
present.

My own approach if I had to distribute a project with multiple .c files,
would be to list them in an @ file, as being more robust, and not
requiring the file-expansion needing for *.c which is not automatic
under Windows.

However I also like to distribute software (for the purpose of building
a binary from source), as a single amalgamated .c file. Hence my comment
at the top; no need to use dedicated folders or tools like make, which
are overkill.

(And thank you the civil post; that makes a change!)

On 2023-08-11, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Bart <bc@freeuk.com> wrote:
>> Now, please tell me what is the point of creating a subdirectory to
>> contain only the one file. Or indeed, what is the point of using 'make'
>> in this case.
>
> Sorry, I really haven't followed this thread with that
> great interest or mental concentration. I am only guessing
> here but I suppose you wanted to do something like:
>
> gcc *.c
>
> and that fails because your main directory contains over
> 250 C source files. If you put them into their own
> subdirectories, you would need:
>
> cd subdir
> gcc *.c

Well, no:

gcc suba/*.c subb/*.c subc/*.c

or with Bash brace expansion
gcc sub{a,b,c}/*.c

> Maybe I have misunderstood something, but this discussion
> seems pretty insane.

That it is.

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

On 2023-08-11, Bart <bc@freeuk.com> wrote:
> Now, please tell me what is the point of creating a subdirectory to
> contain only the one file. Or indeed, what is the point of using 'make'
> in this case.

If you don't see a technical point of using make in a certain situation,
there almost certainly isn't one.

Sometimes people write Makefiles (or follow other conventions) simply
to be compatible wth a common convention.

If you're writing code for an audience which expects to build
a program similarly to this:

$ ./configure && make && make install

then if you make that work, there are no surprises.

The point is to conform to social conventions than to meet
a technical objective in the simplest way.

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

On 11/08/2023 22:38, Kaz Kylheku wrote:
> On 2023-08-11, Bart <bc@freeuk.com> wrote:
>> Now, please tell me what is the point of creating a subdirectory to
>> contain only the one file. Or indeed, what is the point of using 'make'
>> in this case.
>
> If you don't see a technical point of using make in a certain situation,
> there almost certainly isn't one.
>
> Sometimes people write Makefiles (or follow other conventions) simply
> to be compatible wth a common convention.
>
> If you're writing code for an audience which expects to build
> a program similarly to this:
>
> $ ./configure && make && make install
>
> then if you make that work, there are no surprises.
>
> The point is to conform to social conventions than to meet
> a technical objective in the simplest way.
>
>

K&R2 page 6 explains how to compile hello.c:

cc hello.c

I want to keep that simplicity, even for much larger projects.

(However, it then goes on to say (without explanation) that it creates
a.out! <face palm>)

Well at least it doesn't bang on about 'make' and folders.

On 8/11/2023 1:44 PM, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Now, please tell me what is the point of creating a subdirectory to
>> contain only the one file. Or indeed, what is the point of using
>> 'make' in this case.
> [...]
>
> You have more than enough information to figure out what works best
> for you. Just do that.
>
> If you don't want to use make, don't use make. If you don't want
> to create subdirectories, don't create subdirectories.
>
> Some people in this thread have made the mistake of offering
> you advice. That never ends well. Most people, if they say that
> something is not working well for them, are implicitly asking for
> better alternatives. That doesn't seem to be the case for you.
>

Bart is a nice person. I feel like looking up some older conversations
we had. Iiirc, they were rather productive, indeeed. About an encryption
algo of mine....

On 11/08/2023 22:09, Bart wrote:
> On 11/08/2023 21:33, Kalevi Kolttonen wrote:
> > Bart <bc@freeuk.com> wrote:
> >> Now, please tell me what is the point of creating a subdirectory to
> >> contain only the one file. Or indeed, what is the point of using 'make'
> >> in this case.
> >
> > Sorry, I really haven't followed this thread with that
> > great interest or mental concentration. I am only guessing
> > here but I suppose you wanted to do something like:
> >
> >    gcc *.c
> >
> > and that fails because your main directory contains over
> > 250 C source files. If you put them into their own
> > subdirectories, you would need:
> >
> >   cd subdir
> >   gcc *.c
> >
> > Maybe I have misunderstood something, but this discussion
> > seems pretty insane.
>
> I mentioned something about needing to manually write dependencies
> inside makefiles.
>
> Somebody said you can get gcc to do that with 'gcc -MM *.c'.

Well, you can. You'd end up with 250 lines of stuff like ...

foo.o : foo.c foo.h bar.h

.... but only a few of those lines would actually matter to your
prog.exe, the rest is just noise.

But, really, having all your unrelated source files in one directory is
lazy/messy/idiotic.

>
> I then said then you'd need a clean directory with only those exact
> files present.

It would help, sure - but you don't /have/ to.

>
> And this is when a ton of bricks were heaped upon me by numerous posters.
>
> Apparently the idea of having two .c files in the same folder, that
> belong to different programs, is anathema.

It's not unusual for a project to have more that one executable, some of
them sharing the same source files. This is normal.

Bart <bc@freeuk.com> wrote:
> I mentioned something about needing to manually write dependencies
> inside makefiles.
>
> Somebody said you can get gcc to do that with 'gcc -MM *.c'.
>
> I then said then you'd need a clean directory with only those exact
> files present.
>
> And this is when a ton of bricks were heaped upon me by numerous posters.

I see. Thanks for the explanation.

> Apparently the idea of having two .c files in the same folder, that
> belong to different programs, is anathema.

It is pretty unusual, yes.

I am not a build expert by any means, but I have written some
Makefiles like most do on Unix machines. According to Wikipedia:

https://en.wikipedia.org/wiki/Make_(software)

Make first appeared in April 1976. That was a long time ago.
It is a well-established tool.

The usages of Make are not limited to programming languages
like C. It is a pretty general dependency tracking system
and I have also used it for tasks like automating the
building of LaTeX documents.

br,
KK

On 2023-08-11, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> The usages of Make are not limited to programming languages
> like C. It is a pretty general dependency tracking system
> and I have also used it for tasks like automating the
> building of LaTeX documents.

Make could be used to express the dependencies among start-up
activities in a system. Parallel make could then reduce the
boot-up time.

E.g. all things dependent on "networking", but independent of
each other, could start at the same time, thanks to make -j.

Probably most or all of it would be phony targets (no checking of any
file time stamps).

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

On 09/08/2023 18:34, Kaz Kylheku wrote:
> On 2023-08-09, Bart <bc@freeuk.com> wrote:
>> On 09/08/2023 14:32, Richard Harnden wrote:
>>> On 09/08/2023 13:32, Bart wrote:
>>>> Yes, that is one reason that it is so complicated. You have to define
>>>> set of dependences between modules (and you may need to do that
>>>> manually, so it can be error prone).
>>>
>>> $ gcc -MM *.c
>>
>> I have a small, 3-file project (one of Chris's) comprising files
>> cipher.c, sha2.c, hmac.c
>>
>> gcc -MM cipher.c outputs:
>>
>> cipher.o: cipher.c hmac.c sha2.h
>>
>> I need to do -MM cipher.c hmac.c sha2.c for it to show:
>>
>> cipher.o: cipher.c hmac.h sha2.h
>> hmac.o: hmac.c hmac.h sha2.h
>> sha2.o: sha2.c sha2.h
>>
>> So I had to tell it the C files. I can't do *.c, as there are 259 other
>> .c files in the folder.
>
> What you do is use the -MMD option of gcc which causes it
> to compile regularly while writing the dependency information to
> a .d file.
>
> These .d files are included into the Makefile (using -include
> so that the include doesn't fail when they don't yet exist).
>
> When a project is newly compiled from a clean state, dependencies
> are not required because everything must be built.
>
> After the first full build, you then have the .d files.
>
> It's a far from perfect solution. One problem is that when you make a
> change that removes a header file, the build breaks, due to a missing
> dependency. The dependency can't be fixed automatically because make
> wont't run the rule which does that. You either clean away all the
> dependencies, or if you don't want to suffer the rebuild time, you have
> to hunt down all the .d files which mention the removed header and blow
> those off.
>

You can do better than that. You can generate dependency rules for the
dependency files. My makefile has a rule template that is run for each
source directory. Part of that includes:

define compile_rule_template
# $(1) = directory
# $(2) = extra common flags
# $(3) = extra c flags
# $(4) = extra cpp flags

# First, rules to generate target directories as needed
$(dep_dir)$(1) $(obj_dir)$(1) $(lst_dir)$(1) :
$(MKDIR) -p $$@

# Generate dependancy files
$(dep_dir)$(1)%.d : $(1)%.c $(alldepends) | $(dep_dir)$(1)
@echo Generating depency file $$@
$(CCDEP) $(combined_cflags) $(2) $(3) -MM -MP \
-MT $(obj_dir)$(1)$$(@F:%.d=%.o) -MT \
$(dep_dir)$(1)$$(@F:%.o=%.o) \
-MF $$@ $$<

I'll let you look up the gcc manual and make manual for the details of
how this all works. It generates the dependency files automatically,
and updates them automatically. Obviously you need to set the variables
referenced, so that your object files and dependency files are in
separate trees from the source files.

I was a little reluctant to post this because Bart will get his knickers
in a twist over it, but you might find it useful or inspirational.

On Saturday, 12 August 2023 at 09:36:35 UTC+1, David Brown wrote:
> On 09/08/2023 18:34, Kaz Kylheku wrote:
> > On 2023-08-09, Bart <b...@freeuk.com> wrote:
> >> On 09/08/2023 14:32, Richard Harnden wrote:
> >>> On 09/08/2023 13:32, Bart wrote:
> >>>> Yes, that is one reason that it is so complicated. You have to define
> >>>> set of dependences between modules (and you may need to do that
> >>>> manually, so it can be error prone).
> >>>
> >>> $ gcc -MM *.c
> >>
> >> I have a small, 3-file project (one of Chris's) comprising files
> >> cipher.c, sha2.c, hmac.c
> >>
> >> gcc -MM cipher.c outputs:
> >>
> >> cipher.o: cipher.c hmac.c sha2.h
> >>
> >> I need to do -MM cipher.c hmac.c sha2.c for it to show:
> >>
> >> cipher.o: cipher.c hmac.h sha2.h
> >> hmac.o: hmac.c hmac.h sha2.h
> >> sha2.o: sha2.c sha2.h
> >>
> >> So I had to tell it the C files. I can't do *.c, as there are 259 other
> >> .c files in the folder.
> >
> > What you do is use the -MMD option of gcc which causes it
> > to compile regularly while writing the dependency information to
> > a .d file.
> >
> > These .d files are included into the Makefile (using -include
> > so that the include doesn't fail when they don't yet exist).
> >
> > When a project is newly compiled from a clean state, dependencies
> > are not required because everything must be built.
> >
> > After the first full build, you then have the .d files.
> >
> > It's a far from perfect solution. One problem is that when you make a
> > change that removes a header file, the build breaks, due to a missing
> > dependency. The dependency can't be fixed automatically because make
> > wont't run the rule which does that. You either clean away all the
> > dependencies, or if you don't want to suffer the rebuild time, you have
> > to hunt down all the .d files which mention the removed header and blow
> > those off.
> >
>
> You can do better than that. You can generate dependency rules for the
> dependency files. My makefile has a rule template that is run for each
> source directory. Part of that includes:
>
>
> define compile_rule_template
> # $(1) = directory
> # $(2) = extra common flags
> # $(3) = extra c flags
> # $(4) = extra cpp flags
>
> # First, rules to generate target directories as needed
> $(dep_dir)$(1) $(obj_dir)$(1) $(lst_dir)$(1) :
> $(MKDIR) -p $$@
>
> # Generate dependancy files
> $(dep_dir)$(1)%.d : $(1)%.c $(alldepends) | $(dep_dir)$(1)
> @echo Generating depency file $$@
> $(CCDEP) $(combined_cflags) $(2) $(3) -MM -MP \
> -MT $(obj_dir)$(1)$$(@F:%.d=%.o) -MT \
> $(dep_dir)$(1)$$(@F:%.o=%.o) \
> -MF $$@ $$<
>
>
>
> I'll let you look up the gcc manual and make manual for the details of
> how this all works. It generates the dependency files automatically,
> and updates them automatically. Obviously you need to set the variables
> referenced, so that your object files and dependency files are in
> separate trees from the source files.
>
> I was a little reluctant to post this because Bart will get his knickers
> in a twist over it, but you might find it useful or inspirational.
>
As professional software engineers we ought to be able to do better
than this sort of thing.

On 11/08/2023 22:38, Kaz Kylheku wrote:
> On 2023-08-11, Bart <bc@freeuk.com> wrote:
>> Now, please tell me what is the point of creating a subdirectory to
>> contain only the one file. Or indeed, what is the point of using 'make'
>> in this case.
>
> If you don't see a technical point of using make in a certain situation,
> there almost certainly isn't one.
>
> Sometimes people write Makefiles (or follow other conventions) simply
> to be compatible wth a common convention.
>
> If you're writing code for an audience which expects to build
> a program similarly to this:
>
> $ ./configure && make && make install

Such an audience is a lost cause.

I mean, what exactly are we building here, anyway? Is it A, B, or Z?
That's a rather important detail!

Long ago, I used independent compilation just like C still does. So it
happened that sometimes you made a change in a project that required
compiling all modules rather than the one you'd just edited.

However, this was easy to deal with: the structure of my apps was
simple: all modules shared the same project-wide header files (this not
for C):

So, any edits to a module only required compilation of that module.

Any edits to a header in general required compiling everything. But
since I was very familiar with a project because I could spend years on
one, I could usually tell exactly what needed to be recompiled.

In any case, compiling one module took some fraction of a second,
recompiling everything might take several seconds. It wasn't a big deal.

So, there was no need for an automatic tool that discovers dependencies.
The main dependencies I already know about. If I forget to do a
full-recompile, I will quickly find out.

I've also used a basic IDE for development right from the start (early
80s). This used a project file to list the modules of an application, to
simplify browsing and editing (and early versions had a resident
compiler and editor to streamline things on floppy-based systems).

I still use an IDE for my apps. But my compilers can run happily from a
command line, for example this script builds a new production version of
my C compiler:

mm -opt cc.m
copy cc.exe \m\bcc.exe

Or I can try to make bcc compile 'itself' (since it's not written in C):

c:\cx>g:\marchive\mxc\mc -c cc # (archived tool)
M6 Compiling cc.m---------- to cc.c

c:\cx>bcc cc
Compiling cc.c to cc.exe

c:\cx>cc cc -out:cc2 # run on itself again
Compiling cc.c to cc2.exe

c:\cx>cc2 -run hello
Compiling hello.c to hello.exe
Hello, World!

(Try this with gcc.)

So you can see there is no need for 'make', or special rules as to what
I can have in my directories. Or the need for dependencies to minimise
compilation, given that all my apps take a fraction of a second to build
from scratch.

As for that 'configure &&' business; I assume C developers know how to
directly build 'hello.c' using an actual compiler? If so, they can build
one of my C applications.

If they don't, then then they will trouble running my apps anyway.

On 12/08/2023 09:36, David Brown wrote:
> On 09/08/2023 18:34, Kaz Kylheku wrote:
>> On 2023-08-09, Bart <bc@freeuk.com> wrote:
>>> On 09/08/2023 14:32, Richard Harnden wrote:
>>>> On 09/08/2023 13:32, Bart wrote:
>>>>> Yes, that is one reason that it is so complicated. You have to define
>>>>> set of dependences between modules (and you may need to do that
>>>>> manually, so it can be error prone).
>>>>
>>>> $ gcc -MM *.c
>>>
>>> I have a small, 3-file project (one of Chris's) comprising files
>>> cipher.c, sha2.c, hmac.c
>>>
>>> gcc -MM cipher.c outputs:
>>>
>>>     cipher.o: cipher.c hmac.c sha2.h
>>>
>>> I need to do -MM cipher.c hmac.c sha2.c for it to show:
>>>
>>>     cipher.o: cipher.c hmac.h sha2.h
>>>     hmac.o: hmac.c hmac.h sha2.h
>>>     sha2.o: sha2.c sha2.h
>>>
>>> So I had to tell it the C files. I can't do *.c, as there are 259 other
>>> .c files in the folder.
>>
>> What you do is use the -MMD option of gcc which causes it
>> to compile regularly while writing the dependency information to
>> a .d file.
>>
>> These .d files are included into the Makefile (using -include
>> so that the include doesn't fail when they don't yet exist).
>>
>> When a project is newly compiled from a clean state, dependencies
>> are not required because everything must be built.
>>
>> After the first full build, you then have the .d files.
>>
>> It's a far from  perfect solution. One problem is that when you make a
>> change that removes a header file, the build breaks, due to a missing
>> dependency. The dependency can't be fixed automatically because make
>> wont't run the rule which does that. You either clean away all the
>> dependencies, or if you don't want to suffer the rebuild time, you have
>> to hunt down all the .d files which mention the removed header and blow
>> those off.
>>
>
> You can do better than that.  You can generate dependency rules for the
> dependency files.  My makefile has a rule template that is run for each
> source directory.  Part of that includes:
>
>
> define compile_rule_template
>   # $(1) = directory
>   # $(2) = extra common flags
>   # $(3) = extra c flags
>   # $(4) = extra cpp flags
>
>   # First, rules to generate target directories as needed
>   $(dep_dir)$(1) $(obj_dir)$(1) $(lst_dir)$(1) :
>         $(MKDIR) -p $$@
>
>   # Generate dependancy files
>   $(dep_dir)$(1)%.d : $(1)%.c $(alldepends) | $(dep_dir)$(1)
>         @echo Generating depency file $$@
>         $(CCDEP) $(combined_cflags) $(2) $(3) -MM -MP \
>                         -MT $(obj_dir)$(1)$$(@F:%.d=%.o) -MT \
>                         $(dep_dir)$(1)$$(@F:%.o=%.o) \
>                         -MF $$@ $$<
>
>
>
> I'll let you look up the gcc manual and make manual for the details of
> how this all works.  It generates the dependency files automatically,
> and updates them automatically.  Obviously you need to set the variables
> referenced, so that your object files and dependency files are in
> separate trees from the source files.
>
> I was a little reluctant to post this because Bart will get his knickers
> in a twist over it, but you might find it useful or inspirational.

Yeah, more likely to put people off for life.

Suppose you dispensed with all that dependency stuff; how long would it
take to build such a project? Say compared with just compiling one module.

My other recent post suggests that someone very familiar with their
application, will soon know which modules need to be recompiled after
any change. That is, if a full recompile takes too long.

piątek, 11 sierpnia 2023 o 21:41:41 UTC+2 Kaz Kylheku napisał(a):
> On 2023-08-11, Scott Lurndal <sc...@slp53.sl.home> wrote:
> > Kaz Kylheku <864-11...@kylheku.com> writes:
> >>On 2023-08-11, Spiros Bousbouras <spi...@gmail.com> wrote:
> >>> On Thu, 10 Aug 2023 16:15:32 -0000 (UTC)
> >>> Kaz Kylheku <864-11...@kylheku.com> wrote:
> >>>> What we could have is that an executable just dynamically links to
> >>>> functions in these libraries, and the system automatically finds them at
> >>>> load time, without the executable having to specify which libraries. >>>
> >>> And how is your scheme different than how it already works in the Unix
> >>> world ?
> >>
> >>How it differs is that the executable has to nominate the specific
> >>libraries by indicating the library, which came in via the -l option,
> >>and then look for specific symbols from specific libraries that it has
> >>attached.
> >>
> >>Under the hood, the semantics is much like dlopen() of specific
> >>liraries to obtain a handle and then doing dlsym(handle, "name")
> >>to look for specific names from specific libs.
> >>
> >>Imagine it could specify just symbols, without specifying where
> >>they come from; that's a big difference.
> >
> > Would this not require that no symbol be present in more than
> > one library, i.e. that there is a single symbol namespace across the
> > entire system?
> >
> > That would seem to be a non-starter.
> I sort of addressed that in the parts that were snipped above.
> We also have the problem that multiple versions of the same library
> can exist (or multiple version nodes within the same library).
>

versioning is a problem, i recently wrota a thought that given dll should be versioned by letters not numbers , most probably by\ig letters like version "A"
means some interface when lib is upbuild and shipped most rpbably it should contain "A B" strings meaning it conform to both "A" and "B" when "A" interface would stay but work slightly different it probably can be "A2 B"

i think its not bad as people working on dll probably would think if to add new
official version and its letter, also shoudl be aware that what they name "A"
is officially only what they named "A" and new added unoficcialy functions
between "A" and "B" are unoficcial

this is imo easy way to tame that great potential chaos...
(also they should be avare not to break "A" unles they want and then delete "A"
string)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> [...]
>
>>> Yes, C++ calls them literals. But that site does use the same
>>> terminology as the C standard when talking about C:
>>>
>>> https://en.cppreference.com/w/c/language/integer_constant
>>>
>>> I prefer C++'s usage, since "integer constant" can be so easily
>>> confused for "integer constant expression".
>>
>> Using the same term for both suggests a false equivalence, and
>> also is ahistorical. The two kinds of entities are fundamentally
>> different: constants denote values, literals denote objects.
>> Constants, like mathematical constants, always denote the same
>> value; literals denote different objects at different times or
>> places, even if the values used to produce a given literal are
>> always the same, which they need not be. The distinctions are
>> too important to gloss over by using a common term for both.
>
> When you say that "literals denote objects", are you referring
> specifically to the way C uses the terms "string literal" and
> "compound literal"?
>
> I haven't done an exhaustive search, but every language other than
> C whose documentation I've just checked (C++, Ada, Perl, Python,
> Go, Java) calls 42 an integer literal and "foo" a string literal.
> C is a bit of an outlier in callling 42 an integer constant.
>
> I suggest that the fact that C uses "constant" for tokens that
> refer to values and "literal" (string or compound) for constructs
> that refer to anonymous objects was an arbitrary choice, and the
> distinction you mention is not nearly as fundamental as you
> suggest it is.
>
> I do prefer to use the term "integer constant" when discussing C,
> but the phrase "integer literal" is (a) correct in most other
> languages and (b) perfectly clear. It wouldn't occur to me that
> "integer literal" implies something that refers to an object.

The word literal, used as a noun when describing programming
languages, came into vogue sometime after it became common to
specify language syntax by using a formal grammar (usually
expressed in some variation of Backus-Naur Form); roughly the
1970s timeframe. A typical usage would be for "literal" to be
synonymous with "terminal symbol", or perhaps with just a subset
of terminal symbols, as used in the rules of grammar. In some
cases the words "constant" and "literal" were used more or less
interchangeably.

A good decade earlier, however, the word literal was used in a
somewhat different programming language context, not as part of
describing a language but as an element of the language. The
assembly language for IBM System/360 had constants, both ordinary
numeric and character constants, and symbolic constants (defined
with EQU). Constants could be used as direct operands for some
instructions, depending on the particulars of the instruction and
for which operand, and represented values encoded directly in the
instruction. Distinct from constants there were also /literals/,
a distinct category of operand that produced the address of an
initialized anonymous region of memory. Here are two example
lines of assembly, to illustrate the difference:

OI VAL+2,X'F0'
C 3,=F'1000'

In the first line, there are two constants, 2 and X'F0'. These
tokens are numerical quantities that are used directly in the
generated instruction. (In the case of the constant 2 the value
is added to the address VAL, and it is the sum that is used to
produce the bytes of the instruction, but the key property is
that the value 2 participates locally, and not remotely.)

The second line has a constant 3 and a literal =F'1000'. Like in
the first line, the value 3 is used directly in the generated
instruction. The literal =F'1000' is not used directly. Instead,
the assembler keeps track of literals used in the program, and
uses them to initialize areas of memory elsewhere in the program.
A use of a literal, such as the =F'1000' here, results in the
address of the memory area reserved for the value of the literal.
(There are some further details about literals, such as literal
pools and the LTORG directive, that I won't explain because those
details are not important to the discussion.)

Note the parallels between how these terms are used in assembly
language and in C. Constants are used to generate code but appear
only implicitly; literals always occupy areas of memory (objects)
and use of a literal causes its address (lvalue) to be part of a
generated instruction. The distinction between constants and
literals is primarily a semantic distinction, not a syntactic one.

Besides being more historically faithful, having two different
terms provides a useful semantic distinction that would disappear
if the term "literal" were used for both concepts.

>> Given a choice between the level of confusion seen in the C++
>> standard and the level of confusion seen in the C standard ("integer
>> constant" and "integer constant expression" is confusing? really?)
>> I'm happy to be on the side of C's choice any day of the week and
>> twice on Sunday. Please cast my vote to continue using the terms
>> "constant" and "literal" as they are used in the C standard.
>
> I use those terms simply because that's how they're used in the C
> standard.

Obviously it's a good idea to use terminology in the C standard
when talking about the C language. My point though is that the
terminology used in the C standard is a better choice both
historically and semantically.

sobota, 12 sierpnia 2023 o 17:21:15 UTC+2 fir napisał(a):
> piątek, 11 sierpnia 2023 o 21:41:41 UTC+2 Kaz Kylheku napisał(a):
> > On 2023-08-11, Scott Lurndal <sc...@slp53.sl.home> wrote:
> > > Kaz Kylheku <864-11...@kylheku.com> writes:
> > >>On 2023-08-11, Spiros Bousbouras <spi...@gmail.com> wrote:
> > >>> On Thu, 10 Aug 2023 16:15:32 -0000 (UTC)
> > >>> Kaz Kylheku <864-11...@kylheku.com> wrote:
> > >>>> What we could have is that an executable just dynamically links to
> > >>>> functions in these libraries, and the system automatically finds them at
> > >>>> load time, without the executable having to specify which libraries. >>>
> > >>> And how is your scheme different than how it already works in the Unix
> > >>> world ?
> > >>
> > >>How it differs is that the executable has to nominate the specific
> > >>libraries by indicating the library, which came in via the -l option,
> > >>and then look for specific symbols from specific libraries that it has
> > >>attached.
> > >>
> > >>Under the hood, the semantics is much like dlopen() of specific
> > >>liraries to obtain a handle and then doing dlsym(handle, "name")
> > >>to look for specific names from specific libs.
> > >>
> > >>Imagine it could specify just symbols, without specifying where
> > >>they come from; that's a big difference.
> > >
> > > Would this not require that no symbol be present in more than
> > > one library, i.e. that there is a single symbol namespace across the
> > > entire system?
> > >
> > > That would seem to be a non-starter.
> > I sort of addressed that in the parts that were snipped above.
> > We also have the problem that multiple versions of the same library
> > can exist (or multiple version nodes within the same library).
> >
> versioning is a problem, i recently wrota a thought that given dll should be versioned by letters not numbers , most probably by\ig letters like version "A"
> means some interface when lib is upbuild and shipped most rpbably it should contain "A B" strings meaning it conform to both "A" and "B" when "A" interface would stay but work slightly different it probably can be "A2 B"
>
> i think its not bad as people working on dll probably would think if to add new
> official version and its letter, also shoudl be aware that what they name "A"
> is officially only what they named "A" and new added unoficcialy functions
> between "A" and "B" are unoficcial
>
> this is imo easy way to tame that great potential chaos...
> (also they should be avare not to break "A" unles they want and then delete "A"
> string)

still this wersioning could be a pain imo... there could be probably a tool
some "version guerd" that you could maybe use to set a version like

version_guard green.fire.dll "A"

that will add an "A" versioning to a given dll and produces something like
header/certyficate to be able to guard "A" interface from changes just not lett it
be changed (it could or maybe even should be build in compiler)

maybe that would help

there is also a problem of preserving interface (which may be guarded somewhat programatically) and guard the exact efects of how it work - as you can have "A"
interface and quite different work (as i said i rather see this versions should be named by arabic numbers)..im not sure how compiler could quard the second thing (partially it could - by assuming all branches below "A" interface should
ask programmer if some changes there for sure not violate the behaviur
-and if do they should note it is not compatible to arabic number and at another versioning chnge the arabic number)

this is all pain but imo seems better what there is now

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>>> Yes, C++ calls them literals. But that site does use the same
>>>> terminology as the C standard when talking about C:
>>>>
>>>> https://en.cppreference.com/w/c/language/integer_constant
>>>>
>>>> I prefer C++'s usage, since "integer constant" can be so easily
>>>> confused for "integer constant expression".
>>>
>>> Using the same term for both suggests a false equivalence, and
>>> also is ahistorical. The two kinds of entities are fundamentally
>>> different: constants denote values, literals denote objects.
>>> Constants, like mathematical constants, always denote the same
>>> value; literals denote different objects at different times or
>>> places, even if the values used to produce a given literal are
>>> always the same, which they need not be. The distinctions are
>>> too important to gloss over by using a common term for both.
>>
>> When you say that "literals denote objects", are you referring
>> specifically to the way C uses the terms "string literal" and
>> "compound literal"?
>>
>> I haven't done an exhaustive search, but every language other than
>> C whose documentation I've just checked (C++, Ada, Perl, Python,
>> Go, Java) calls 42 an integer literal and "foo" a string literal.
>> C is a bit of an outlier in callling 42 an integer constant.
>>
>> I suggest that the fact that C uses "constant" for tokens that
>> refer to values and "literal" (string or compound) for constructs
>> that refer to anonymous objects was an arbitrary choice, and the
>> distinction you mention is not nearly as fundamental as you
>> suggest it is.
>>
>> I do prefer to use the term "integer constant" when discussing C,
>> but the phrase "integer literal" is (a) correct in most other
>> languages and (b) perfectly clear. It wouldn't occur to me that
>> "integer literal" implies something that refers to an object.
>
> The word literal, used as a noun when describing programming
> languages, came into vogue sometime after it became common to
> specify language syntax by using a formal grammar (usually
> expressed in some variation of Backus-Naur Form); roughly the
> 1970s timeframe. A typical usage would be for "literal" to be
> synonymous with "terminal symbol", or perhaps with just a subset
> of terminal symbols, as used in the rules of grammar. In some
> cases the words "constant" and "literal" were used more or less
> interchangeably.
>
> A good decade earlier, however, the word literal was used in a
> somewhat different programming language context, not as part of
> describing a language but as an element of the language. The
> assembly language for IBM System/360 had constants, both ordinary
> numeric and character constants, and symbolic constants (defined
> with EQU). Constants could be used as direct operands for some
> instructions, depending on the particulars of the instruction and
> for which operand, and represented values encoded directly in the
> instruction. Distinct from constants there were also /literals/,
> a distinct category of operand that produced the address of an
> initialized anonymous region of memory. Here are two example
> lines of assembly, to illustrate the difference:
>
> OI VAL+2,X'F0'
> C 3,=F'1000'
>
> In the first line, there are two constants, 2 and X'F0'. These
> tokens are numerical quantities that are used directly in the
> generated instruction. (In the case of the constant 2 the value
> is added to the address VAL, and it is the sum that is used to
> produce the bytes of the instruction, but the key property is
> that the value 2 participates locally, and not remotely.)
>
> The second line has a constant 3 and a literal =F'1000'. Like in
> the first line, the value 3 is used directly in the generated
> instruction. The literal =F'1000' is not used directly. Instead,
> the assembler keeps track of literals used in the program, and
> uses them to initialize areas of memory elsewhere in the program.
> A use of a literal, such as the =F'1000' here, results in the
> address of the memory area reserved for the value of the literal.
> (There are some further details about literals, such as literal
> pools and the LTORG directive, that I won't explain because those
> details are not important to the discussion.)
>
> Note the parallels between how these terms are used in assembly
> language and in C. Constants are used to generate code but appear
> only implicitly; literals always occupy areas of memory (objects)
> and use of a literal causes its address (lvalue) to be part of a
> generated instruction. The distinction between constants and
> literals is primarily a semantic distinction, not a syntactic one.
>
> Besides being more historically faithful, having two different
> terms provides a useful semantic distinction that would disappear
> if the term "literal" were used for both concepts.
>
>
>>> Given a choice between the level of confusion seen in the C++
>>> standard and the level of confusion seen in the C standard ("integer
>>> constant" and "integer constant expression" is confusing? really?)
>>> I'm happy to be on the side of C's choice any day of the week and
>>> twice on Sunday. Please cast my vote to continue using the terms
>>> "constant" and "literal" as they are used in the C standard.
>>
>> I use those terms simply because that's how they're used in the C
>> standard.
>
> Obviously it's a good idea to use terminology in the C standard
> when talking about the C language. My point though is that the
> terminology used in the C standard is a better choice both
> historically and semantically.

Ok, that's some interesting history -- but I've never heard of anything
other than IBM System/360 assembly language (and C) that makes that
particular distinction. Most programmers these days (myself included)
are not more than vaguely familiar with System/360.

The distinction you suggest never occurred to me until you brought it up
here. (The term "string literal" appears to have been introduced in
K&R1, 1978; earlier documents use the term "string". All C documents
I've checked back to 1975 refer to integer, character, and floating
constants as "constants". B did the same. BCPL used the term "string
constant".)

Do you have other examples, or evidence that the distinction between
"literals" and "constants" has been common?

On the other hand, multiple modern languages use "literal" to refer
to what C calls "constants". I know that C only uses "literal"
to refer to string literals and compound literals, but I never
perceived any implication that a "literal" is something that refers
to an object. (And I'd have no problem if a future C standard
adopted the word "literal" for what it now calls "constants".)

A question for the group: does anyone else perceive this general
distinction between "constant" (denoting a value) and "literal"
(denoting an object)?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 12/08/2023 11:58, Malcolm McLean wrote:
> On Saturday, 12 August 2023 at 09:36:35 UTC+1, David Brown wrote:
>> On 09/08/2023 18:34, Kaz Kylheku wrote:
>>> On 2023-08-09, Bart <b...@freeuk.com> wrote:
>>>> On 09/08/2023 14:32, Richard Harnden wrote:
>>>>> On 09/08/2023 13:32, Bart wrote:
>>>>>> Yes, that is one reason that it is so complicated. You have to define
>>>>>> set of dependences between modules (and you may need to do that
>>>>>> manually, so it can be error prone).
>>>>>
>>>>> $ gcc -MM *.c
>>>>
>>>> I have a small, 3-file project (one of Chris's) comprising files
>>>> cipher.c, sha2.c, hmac.c
>>>>
>>>> gcc -MM cipher.c outputs:
>>>>
>>>> cipher.o: cipher.c hmac.c sha2.h
>>>>
>>>> I need to do -MM cipher.c hmac.c sha2.c for it to show:
>>>>
>>>> cipher.o: cipher.c hmac.h sha2.h
>>>> hmac.o: hmac.c hmac.h sha2.h
>>>> sha2.o: sha2.c sha2.h
>>>>
>>>> So I had to tell it the C files. I can't do *.c, as there are 259 other
>>>> .c files in the folder.
>>>
>>> What you do is use the -MMD option of gcc which causes it
>>> to compile regularly while writing the dependency information to
>>> a .d file.
>>>
>>> These .d files are included into the Makefile (using -include
>>> so that the include doesn't fail when they don't yet exist).
>>>
>>> When a project is newly compiled from a clean state, dependencies
>>> are not required because everything must be built.
>>>
>>> After the first full build, you then have the .d files.
>>>
>>> It's a far from perfect solution. One problem is that when you make a
>>> change that removes a header file, the build breaks, due to a missing
>>> dependency. The dependency can't be fixed automatically because make
>>> wont't run the rule which does that. You either clean away all the
>>> dependencies, or if you don't want to suffer the rebuild time, you have
>>> to hunt down all the .d files which mention the removed header and blow
>>> those off.
>>>
>>
>> You can do better than that. You can generate dependency rules for the
>> dependency files. My makefile has a rule template that is run for each
>> source directory. Part of that includes:
>>
>>
>> define compile_rule_template
>> # $(1) = directory
>> # $(2) = extra common flags
>> # $(3) = extra c flags
>> # $(4) = extra cpp flags
>>
>> # First, rules to generate target directories as needed
>> $(dep_dir)$(1) $(obj_dir)$(1) $(lst_dir)$(1) :
>> $(MKDIR) -p $$@
>>
>> # Generate dependancy files
>> $(dep_dir)$(1)%.d : $(1)%.c $(alldepends) | $(dep_dir)$(1)
>> @echo Generating depency file $$@
>> $(CCDEP) $(combined_cflags) $(2) $(3) -MM -MP \
>> -MT $(obj_dir)$(1)$$(@F:%.d=%.o) -MT \
>> $(dep_dir)$(1)$$(@F:%.o=%.o) \
>> -MF $$@ $$<
>>
>>
>>
>> I'll let you look up the gcc manual and make manual for the details of
>> how this all works. It generates the dependency files automatically,
>> and updates them automatically. Obviously you need to set the variables
>> referenced, so that your object files and dependency files are in
>> separate trees from the source files.
>>
>> I was a little reluctant to post this because Bart will get his knickers
>> in a twist over it, but you might find it useful or inspirational.
>>
> As professional software engineers we ought to be able to do better
> than this sort of thing.
>

Possibly. But most of the attempts, such as CMake, have not been as
good. They have tried to have a less cryptic syntax, but either fail to
provide the features needed, or simply replace cryptic symbols with
cryptic words.

Part of it is the flexibility needed - what suits me in my projects is
not the same as what suits other people in their projects.

The reality of good makefiles is that you don't spend much time on them.
I might spend a few hours on a project tweaking or modifying the
makefile I use, copied from a previous project. It's a tiny, tiny
fraction of the effort in a development project, and it makes things
much more efficient, portable, and easy to replicate - I am used to
rebuilding projects with bit-perfect replication on computers a decade
apart with different OS's. The effort required to google for "automatic
dependency generation for makefiles" and copy the ideas is small.