On 2023-08-13, David Brown <david.brown@hesbynett.no> wrote:
> On 12/08/2023 11:58, Malcolm McLean wrote:
>> On Saturday, 12 August 2023 at 09:36:35 UTC+1, David Brown wrote:
>>> 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.

I've learned something from your Makefile fragment there.
And in turn, I have a potentially nice idea; see below.

It looks like your rules might be solving the problem when header files
disappear from dependencies.

You used the -MT option twice, in order to insert the .d file itself
as a target into the .d file, so you have this in a "whatever.d"
file:

whatever.o: whatever.c header.h ...

whatever.d: whatever.c header.h ...

Thus if any of the files whatever.c header.h .. change, not onlly
is the .o out of date, but so is the .d.

Now the .d is a Makefile fragment that is included.

When GNU Make finishes reading the Makefile and all included fragments,
it considers them as targets to be updated (before doing anything else).
So at that point, any out of date .d files will get re-made by your
dependency generating rule, and everything gets reloaded.

Then the .d files are up-to-date and compiling proceeds with
the correct dependencies.

When you generate .d files as byproduct of making .o files, and don't
have a rule to generate them separately, then a code change that removes
a header breaks the build.

If we remove "header.h", the .d file refers to a nonexistent
prerequisite and make complains that it has no way to build header.h,
which is needed by whatever.o.

Now here is the idea. I think we can stick with the more efficient
system where we generate the .d as a side effect of compiling the .o
in a single compiler invocation.

We have a rule which updates .d files, but the body does this:

$(dep_dir)$(1)%.d : $(1)%.c $(alldepends) | $(dep_dir)$(1)
> $@
touch $<

The .d file is truncated to zero length, and its time stamp is touched,
and the .c file (first prerequiste $<) is touched, to force the .o
to rebuild.

I think that, then, in the .d file, all we need is the .d dependencies:

whatever.d: whatever.c whatever.h ...

We don't need the .o. Whenever whatever.c or whatever.h or other files
change, the .d file itself is out of date, and so the update rule
will file, blowing away that file, and touching the .c file.
So the .c file is forced to rebuild, and in so doing it will
regenerate the .d file.

I will experiment with this to see what, if any, unforseen stumbling
blocks come up.

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

On Sunday, 13 August 2023 at 07:19:19 UTC+1, David Brown wrote:
> 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.
>
I've spent hours on make files. Not ones written by me. Ones written by other
people which fall over. To be fair usually things do work as expected, out
of the box. But not always.

Whilst I've written make files, generally I don't find the system useful.
If my projects compile under Linux, then usually they are portable. So
gcc *.c should do it, and I don't see the point in make. If they are non-portable,
they go on Windows. CMake is a blessing as it frees you from the need to distribute
a Visual Studio project file.

On 12/08/2023 13:12, Bart wrote:
> 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.
>

I find people like it once it is written.

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

That particular project takes a minute and a half to compile on my
laptop (it's faster on my main machine). It's 373 compilations, perhaps
40% of it C++. Too long for convenience.

My makefiles handle more than just avoiding redundant compilations. It
is also where all the flags are set (I need many), getting the right
compiler (on many different host machines), doing "resource compiling", etc.

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

My experience is that such manual builds are tedious and error-prone.
The reality is that people /don't/ keep good track of what needs
rebuilt, and they either get obscure problems from failing to re-compile
as needed, or they have a habit of rebuilding everything all the time.

Computers are good at tedious work. They are good at tracking this kind
of small detail. Why not let the computer do the work here? All it
takes is a little googling and a willingness to learn - makefiles have a
somewhat cryptic syntax, but it is not actually that hard if you are
methodical, and you don't have to write them often.

On 11/08/2023 12:17, Bart wrote:
> 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.
>

No, I am merely saying you can use folders to organise code so that you
have project files in one place. If you choose to fill a single
directory with piles of junk, old files, broken files, and other crap so
that you can barely remember what was actual useful code, that's your
choice.

Most people doing serious development work use some kind of version
control system. And they try to keep their files organised. If you
choose to be unlike most developers, that's your choice. I can only
advise you, not force you.

> It's not the job of a language or even a build scheme to tell users how
> to organise their stuff.
>

No, indeed. Programmers generally prefer to keep things organised no
matter which language they use.

>
> Look, just do things your way, and let others use their own approaches.
> I've actually been doing this stuff for longer than you.
>

Longer does not mean better. Often it means set in your ways, and
unwilling to look at alternatives.

On 2023-08-13, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> Now here is the idea. I think we can stick with the more efficient
> system where we generate the .d as a side effect of compiling the .o
> in a single compiler invocation.
>
> We have a rule which updates .d files, but the body does this:
>
> $(dep_dir)$(1)%.d : $(1)%.c $(alldepends) | $(dep_dir)$(1)
> > $@
> touch $<
>
> The .d file is truncated to zero length, and its time stamp is touched,
> and the .c file (first prerequiste $<) is touched, to force the .o
> to rebuild.
>
> I think that, then, in the .d file, all we need is the .d dependencies:
>
> whatever.d: whatever.c whatever.h ...
>
> We don't need the .o. Whenever whatever.c or whatever.h or other files
> change, the .d file itself is out of date, and so the update rule
> will file, blowing away that file, and touching the .c file.
> So the .c file is forced to rebuild, and in so doing it will
> regenerate the .d file.
>
> I will experiment with this to see what, if any, unforseen stumbling
> blocks come up.

It's looking good, except I made these changes.

1. If the .d file is being updated because it doesn't exist,
then don't bother with the > $@ command. It only risks failing
due to missing directory components. When the .o file is
built, it takes care of the dependency on the directory to be
created, which is where the .d lives. When updating the .d,
we cannot assume the directory exists.

2. Don't touch the .c file --- blow off the .o file!

In my Makefile it looks like this

# Truncate out-of-date dependency files and remove the corresponding .o.
%.d:
$(call SH,if [ -e $@ ]; then > $@ ; fi)
$(call SH,rm -f ${@:.d=.o})

In the compiler command, I now have:

-MMD -MT ${@:.o=.d}

The target is just the .d file, no .o.

Everything is building fine incrementally, and I tried the
case where a header file is removed; it works too.

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

On Sun, 13 Aug 2023 00:18:28 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Whilst I've written make files, generally I don't find the system useful.
> If my projects compile under Linux, then usually they are portable. So
> gcc *.c should do it, and I don't see the point in make.

If all you need is C compilation and compiling everything doesn't take too
long then yes , gcc <options> *.c is fine and make would be an
unnecessary complication. But even then you would need alternatives to
things like make install or make test like writing separate scripts.

On Sat, 12 Aug 2023 16:37:07 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 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)?

I've never given it much thought and I'm content to use the terms (or
any other related) in the same manner as the specification(s) for
the language I'm using.

On 2023-08-13, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-13, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> Now here is the idea. I think we can stick with the more efficient
>> system where we generate the .d as a side effect of compiling the .o
>> in a single compiler invocation.
>>
>> We have a rule which updates .d files, but the body does this:
>>
>> $(dep_dir)$(1)%.d : $(1)%.c $(alldepends) | $(dep_dir)$(1)
>> > $@
>> touch $<
>>
>> The .d file is truncated to zero length, and its time stamp is touched,
>> and the .c file (first prerequiste $<) is touched, to force the .o
>> to rebuild.
>>
>> I think that, then, in the .d file, all we need is the .d dependencies:
>>
>> whatever.d: whatever.c whatever.h ...
>>
>> We don't need the .o. Whenever whatever.c or whatever.h or other files
>> change, the .d file itself is out of date, and so the update rule
>> will file, blowing away that file, and touching the .c file.
>> So the .c file is forced to rebuild, and in so doing it will
>> regenerate the .d file.
>>
>> I will experiment with this to see what, if any, unforseen stumbling
>> blocks come up.
>
> It's looking good, except I made these changes.
>
> 1. If the .d file is being updated because it doesn't exist,
> then don't bother with the > $@ command. It only risks failing
> due to missing directory components. When the .o file is
> built, it takes care of the dependency on the directory to be
> created, which is where the .d lives. When updating the .d,
> we cannot assume the directory exists.
>
> 2. Don't touch the .c file --- blow off the .o file!
>
> In my Makefile it looks like this
>
> # Truncate out-of-date dependency files and remove the corresponding .o.
> %.d:
> $(call SH,if [ -e $@ ]; then > $@ ; fi)
> $(call SH,rm -f ${@:.d=.o})
>
> In the compiler command, I now have:
>
> -MMD -MT ${@:.o=.d}
>
> The target is just the .d file, no .o.
>
> Everything is building fine incrementally, and I tried the
> case where a header file is removed; it works too.

No; there is something that I'm certain is wrong.

When you have this in foo.d:

foo.d: foo.c foo.h common.h

and, say, common.h is there because foo.h includes it, and suppose
common.h is removed and foo.h edited not to refer to it.

Here is what is wrong:

Make tries to update foo.d via the %.d rule, but notices that the
common.h prerequisite is missing and cannot be made. Make then gives up
on the pattern rule entirely and doesn't run the recipe.

Since it doesn't run the recipe, the foo.o file is not removed.

Since there are only .d dependencies, foo.o is only considered with
regard to foo.c and looks up-to-date (foo.c has not been touched).

Putting the foo.o target in the .d file won't fix it; the
rule which truncates .d isn't run and so there will be a problem
that foo.o cannot be made due to a missing common.h that cannot
be made.

Come to think of it, I don't understand how David's rules avoid
a similar problem; perhaps they don't? If a prerequisite is removed,
the same thing will happen: the pattern rule for updating the .d
file will be dropped, and so the compile job will run into the
dependency problem.

If the rules don't solve that problem, they are no better than
the naive way of just generating .d together with .o.

The way to solve the problem may be to run a script which sweeps
through the dependencies and identifies those which have
a missing prerequisite, blowing those away and the .o file.
This happens from some $(shell ...) command before the .d files
are read, so no rule for updating .d files is required.

Another solution is to have dummy rules that cause missing
headers to be ignored:

https://stackoverflow.com/questions/23964228/make-ignoring-prerequisite-that-doesnt-exist

That could fix the flaw in the scheme I'm investigating, too.

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

On Sunday, August 13, 2023 at 9:19:19 AM UTC+3, David Brown wrote:
> 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.

$(foreach src, $(C_SRCS) $(CXX_SRCS) $(ASM_SRCS) \
,$(eval \
$(call src2obj_rule_template,$(src),$(OBJ_ROOT_DIR)/$(strip \
$(if \
$(findstring ../,$(src)), \
$(notdir $(basename $(src))), \
$(basename $(src)) \
) \
)) \
) \
)

Above is the macro I have in a few of my makefiles.
I still can tell *what* it does, but not *how*. I could not probably
tell *how* 3 hours after I finished writing it.
It easily beats perl in write-only contest and could give a fare
fight to APL.

On Sunday, August 13, 2023 at 10:18:38 AM UTC+3, Malcolm McLean wrote:
> On Sunday, 13 August 2023 at 07:19:19 UTC+1, David Brown wrote:
> > 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.
> >
> I've spent hours on make files. Not ones written by me. Ones written by other
> people which fall over. To be fair usually things do work as expected, out
> of the box. But not always.
>
> Whilst I've written make files, generally I don't find the system useful.
> If my projects compile under Linux, then usually they are portable. So
> gcc *.c should do it, and I don't see the point in make.

That's because a command line is not your primary dev environment.
You develop with IDE and make is merely a tool to compile on also-run
OSes after sorces are ready and stable.
In your scenario make indeed has no advantages over simple
(but well-structured) build script.

> If they are non-portable,
> they go on Windows. CMake is a blessing as it frees you from the need to distribute
> a Visual Studio project file.

Bart <bc@freeuk.com> writes:
> On 26/07/2023 21:55, Ben Bacarisse wrote:
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>> And in C one can write
>>> mid = low + (high-low)/2 ;
>>>
>>> and not worry about overflow either. I find the latter easier to reason
>>> about too.
>>
>> That can overflow using signed ints. In truth it was a bad example
>> because BCPL pointer arithmetic is not really signed or unsigned -- it
>> just works. And in C one could use unsigned offsets and not worry about
>> overflow.
>
> I thought unsigned overflow in C was just well-defined in the
> language, not that it was rendered impossible!
>
> If I run this code:
>
> #include <stdio.h>
>
> int main(void) {
> unsigned int low = 0xC0000000;
> unsigned int high = 0xE0000000;
> unsigned int mid = (low + high)/2;
>
> printf("%X\n", mid);
> }
>
> I'd really expected `mid` here to have the value 0xD0000000, instead
> it prints out 0x50000000.
>
> So, that's nothing to worry about?
>
> OK ....
>
> BTW if I change the types to 'unsigned long long int` (phew, there's a
> reason people write 'u64' for short!), then it magically gives the
> value I expect. That's OK too when behaviour changes dramatically like
> that?
>
> Nothing at all to do with overflow, because that's impossible of course...

What's wrong with:

unsigned int low = 0xC0000000;
unsigned int high = 0xE0000000;
unsigned int mid = (low | high) + (low & high)/2;

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 13/08/2023 12:53, Phil Carmody wrote:
> Bart <bc@freeuk.com> writes:
>> On 26/07/2023 21:55, Ben Bacarisse wrote:
>>> Spiros Bousbouras <spibou@gmail.com> writes:
>>>> And in C one can write
>>>> mid = low + (high-low)/2 ;
>>>>
>>>> and not worry about overflow either. I find the latter easier to
reason
>>>> about too.
>>>
>>> That can overflow using signed ints. In truth it was a bad example
>>> because BCPL pointer arithmetic is not really signed or unsigned -- it
>>> just works. And in C one could use unsigned offsets and not worry
about
>>> overflow.
>>
>> I thought unsigned overflow in C was just well-defined in the
>> language, not that it was rendered impossible!
>>
>> If I run this code:
>>
>> #include <stdio.h>
>>
>> int main(void) {
>> unsigned int low = 0xC0000000;
>> unsigned int high = 0xE0000000;
>> unsigned int mid = (low + high)/2;
>>
>> printf("%X\n", mid);
>> }
>>
>> I'd really expected `mid` here to have the value 0xD0000000, instead
>> it prints out 0x50000000.
>>
>> So, that's nothing to worry about?
>>
>> OK ....
>>
>> BTW if I change the types to 'unsigned long long int` (phew, there's a
>> reason people write 'u64' for short!), then it magically gives the
>> value I expect. That's OK too when behaviour changes dramatically like
>> that?
>>
>> Nothing at all to do with overflow, because that's impossible of
course...
>
> What's wrong with:
>
> unsigned int low = 0xC0000000;
> unsigned int high = 0xE0000000;
> unsigned int mid = (low | high) + (low & high)/2;

To get a value between A and B? Almost everything.

And that's when I assumed it gave the expected answer. Actually it
results in 0x40000000, even further away than 0x50000000 is.

So, 'everything'.

You anyway can't convert arbitrary arithmetic expressions into odd
combinations of arithmetic and logical, that will leave people wandering
what the hell it is you're trying to do.

The point of my example is that a certain result was expected from
(A+B)/2, which it failed to deliver, but when such failures are
encountered using signed versions of A and B, then it is UB.

On Sunday, 13 August 2023 at 11:44:33 UTC+1, Michael S wrote:
> On Sunday, August 13, 2023 at 10:18:38 AM UTC+3, Malcolm McLean wrote:
> > On Sunday, 13 August 2023 at 07:19:19 UTC+1, David Brown wrote:
> > > 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.
> > >
> > I've spent hours on make files. Not ones written by me. Ones written by other
> > people which fall over. To be fair usually things do work as expected, out
> > of the box. But not always.
> >
> > Whilst I've written make files, generally I don't find the system useful.
> > If my projects compile under Linux, then usually they are portable. So
> > gcc *.c should do it, and I don't see the point in make.
> That's because a command line is not your primary dev environment.
> You develop with IDE and make is merely a tool to compile on also-run
> OSes after sorces are ready and stable.
> In your scenario make indeed has no advantages over simple
> (but well-structured) build script.
>
Actually one big advantage of the gcc *.c method is that you can easily
toggle options on and off . For example clang has an address santizer.
It slows down the program significantly so you don't want it on by default,
But you do want to do a few runs with the sanitzer on to check for memory
errors.
(I know that in make you can set up a "debug" target. But you might also
want -pedantic on or off. For instance if you're taking in some code from
someone else, you might need to switch pedantic off to get it working, then
switch it on to make it compliant, then switch it off again to make the
compile instructions simple for the users).

In article <87h6p35faz.fsf@fatphil.org>,
Phil Carmody <pc+usenet@asdf.org> wrote:
....
>What's wrong with ...

Any post (to any sort of "technical" forum) that contains the totally dumb
phrase "What's wrong with ..." can and should be discounted by 100%.

Thank you. Now back to your regularly scheduled programming.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Pedantic

Phil Carmody <pc+usenet@asdf.org> writes:

> Bart <bc@freeuk.com> writes:
>> On 26/07/2023 21:55, Ben Bacarisse wrote:
>>> Spiros Bousbouras <spibou@gmail.com> writes:
>>>> And in C one can write
>>>> mid = low + (high-low)/2 ;
>>>>
>>>> and not worry about overflow either. I find the latter easier to reason
>>>> about too.
>>>
>>> That can overflow using signed ints. In truth it was a bad example
>>> because BCPL pointer arithmetic is not really signed or unsigned -- it
>>> just works. And in C one could use unsigned offsets and not worry about
>>> overflow.
>>
>> I thought unsigned overflow in C was just well-defined in the
>> language, not that it was rendered impossible!
>>
>> If I run this code:
>>
>> #include <stdio.h>
>>
>> int main(void) {
>> unsigned int low = 0xC0000000;
>> unsigned int high = 0xE0000000;
>> unsigned int mid = (low + high)/2;
>>
>> printf("%X\n", mid);
>> }
>>
>> I'd really expected `mid` here to have the value 0xD0000000, instead
>> it prints out 0x50000000.
>>
>> So, that's nothing to worry about?
>>
>> OK ....
>>
>> BTW if I change the types to 'unsigned long long int` (phew, there's a
>> reason people write 'u64' for short!), then it magically gives the
>> value I expect. That's OK too when behaviour changes dramatically like
>> that?
>>
>> Nothing at all to do with overflow, because that's impossible of course...
>
> What's wrong with:
>
> unsigned int low = 0xC0000000;
> unsigned int high = 0xE0000000;
> unsigned int mid = (low | high) + (low & high)/2;

Did you mean (low | high)/2 + (low & high)/2 ?

--
Ben.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>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 Burroughs medium systems BPL compiler describes the term
LITERAL as follows:

Numeric Literal

A numeric literal is defined as an item composed of characters
chosen from the digits 0 through 9, the plus sign or minus sign
and the decimal point.

Non-Numeric Literal
A non-numeric Literal may be composed of any allowable character.
The beginning and ending of a non-numeric literal is denoted by
a quotation mark.

Undigit Numeric Literals
Hexidecimal values 10 through 15 are represented as A through F and
must be bound by @ signs when used. For example, hexadecimal 11
would be literalized by @B@. A hexadecimal literal cannot exceed
99 digits. Hexadecimal values 10 through 15, when enclosed in
percent signs (%), will represent numeric literals in byte format,
for example %F2% would cause a one-byte literal to be generated.

http://bitsavers.org/pdf/burroughs/MediumSystems/Software/5024789_BPL_7.2_198708.pdf

<snip>

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

No. But then I managed to avoid the 360 family for the most part
being a burroughs employee.

Michael S <already5chosen@yahoo.com> writes:
>On Sunday, August 13, 2023 at 10:18:38=E2=80=AFAM UTC+3, Malcolm McLean wro=

>> Whilst I've written make files, generally I don't find the system useful.=
>=20
>> If my projects compile under Linux, then usually they are portable. So=20
>> gcc *.c should do it, and I don't see the point in make.
>
>That's because a command line is not your primary dev environment.
>You develop with IDE and make is merely a tool to compile on also-run
>OSes after sorces are ready and stable.=20

Can you rephrase that last sentence? I can't make head nor tail
of it.

Makefiles are valuable throughout the development process.

Do you people ever develop complex applications with dozens
or hundreds of source files?

On Sunday, 13 August 2023 at 16:53:49 UTC+1, Scott Lurndal wrote:
> Michael S <already...@yahoo.com> writes:
> >On Sunday, August 13, 2023 at 10:18:38=E2=80=AFAM UTC+3, Malcolm McLean wro=
>
>
> >> Whilst I've written make files, generally I don't find the system useful.=
> >=20
> >> If my projects compile under Linux, then usually they are portable. So=20
> >> gcc *.c should do it, and I don't see the point in make.
> >
> >That's because a command line is not your primary dev environment.
> >You develop with IDE and make is merely a tool to compile on also-run
> >OSes after sorces are ready and stable.=20
>
> Can you rephrase that last sentence? I can't make head nor tail
> of it.
>
> Makefiles are valuable throughout the development process.
>
> Do you people ever develop complex applications with dozens
> or hundreds of source files?
>
Dozens, yes. But not hundreds.

David Brown <david.brown@hesbynett.no> writes:
>On 12/08/2023 13:12, Bart wrote:

>
>> 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.
>>
>
>That particular project takes a minute and a half to compile on my
>laptop (it's faster on my main machine). It's 373 compilations, perhaps
>40% of it C++. Too long for convenience.

My current project takes well over an hour to build on a single-core
system. With 32 cores and parallel make (-j32), that's reduced to
less than ten minutes (quicker if not using -O3, since once source file
takes 6 minutes itself to build with -O3, two minutes with -O0).

Somewhere over two million lines of C and C++ in several hundred
source files.

Without makefiles and dependency checking, the project would likely
not be feasible.

David Brown <david.brown@hesbynett.no> writes:
>On 11/08/2023 12:17, Bart wrote:
>> On 11/08/2023 07:43, David Brown wrote:

>> Look, just do things your way, and let others use their own approaches.
>> I've actually been doing this stuff for longer than you.
>>
>
>Longer does not mean better. Often it means set in your ways, and
>unwilling to look at alternatives.

And I seriously doubt the "longer than you" bit.

On 13/08/2023 16:53, Scott Lurndal wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Sunday, August 13, 2023 at 10:18:38=E2=80=AFAM UTC+3, Malcolm
McLean wro=
>
>
>>> Whilst I've written make files, generally I don't find the system
useful.=
>> =20
>>> If my projects compile under Linux, then usually they are portable.
So=20
>>> gcc *.c should do it, and I don't see the point in make.
>>
>> That's because a command line is not your primary dev environment.
>> You develop with IDE and make is merely a tool to compile on also-run
>> OSes after sorces are ready and stable.=20
>
> Can you rephrase that last sentence? I can't make head nor tail
> of it.

It seems perfectly clear to me.

> Makefiles are valuable throughout the development process.
>
> Do you people ever develop complex applications with dozens
> or hundreds of source files?

You people don't seem to understand the line between developer and user.

The user usually wants ready-to-run binaries, preferably as monolithic
executables.

If that is not practical and a binary needs to be created from source,
then the files and directory structure needed to make that possible
effortlessy, and with few failure points, are NOT the exact same huge,
sprawling mess that the developer has to work with:

* The directory structure is irrelevant

* Static analysis is irrelevant; the software has been debugged and
is working

* Makefile dependencies are irrelevant: eveything has to be built
from source anyway

When an EXE is provided, whoever created it has already targeted the
user's platform. One step back from EXE, the minimal source bundle
needed to build that EXE can simililary be configured to that same platform.

The result is a more streamlined process with less chance of failure.

On 13/08/2023 17:02, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/08/2023 12:17, Bart wrote:
>>> On 11/08/2023 07:43, David Brown wrote:
>
>>> Look, just do things your way, and let others use their own approaches.
>>> I've actually been doing this stuff for longer than you.
>>>
>>
>> Longer does not mean better. Often it means set in your ways, and
>> unwilling to look at alternatives.
>
> And I seriously doubt the "longer than you" bit.

Why would you doubt that?

On 13/08/2023 17:02, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 12/08/2023 13:12, Bart wrote:
>
>>
>>> 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.
>>>
>>
>> That particular project takes a minute and a half to compile on my
>> laptop (it's faster on my main machine). It's 373 compilations, perhaps
>> 40% of it C++. Too long for convenience.
>
> My current project takes well over an hour to build on a single-core
> system. With 32 cores and parallel make (-j32), that's reduced to
> less than ten minutes

You don't get a 32x speedup then?

> (quicker if not using -O3, since once source file
> takes 6 minutes itself to build with -O3, two minutes with -O0).
>
> Somewhere over two million lines of C and C++ in several hundred
> source files.
>
> Without makefiles and dependency checking, the project would likely
> not be feasible.

Two million lines doesn't sound that huge. With -O0 that would take,
what, 12-15 minutes on one core? About 2.5K lines second; a rather
sluggish compiler then.

I guess that must be due to C++? Or loads of header files?

Because I get 15-20Klps for gcc on a machine that is undoubtedly slower
than yours (it's faster under WSL).

I don't believe your source files are that small either: 2M lines over
1000 files would average 2K lines per file.

On 13/08/2023 17:48, Bart wrote:
> On 13/08/2023 17:02, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 12/08/2023 13:12, Bart wrote:
>>
>>>
>>>> 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.
>>>>
>>>
>>> That particular project takes a minute and a half to compile on my
>>> laptop (it's faster on my main machine). It's 373 compilations,
perhaps
>>> 40% of it C++. Too long for convenience.
>>
>> My current project takes well over an hour to build on a single-core
>> system. With 32 cores and parallel make (-j32), that's reduced to
>> less than ten minutes
>
> You don't get a 32x speedup then?
>
>> (quicker if not using -O3, since once source file
>> takes 6 minutes itself to build with -O3, two minutes with -O0).
>>
>> Somewhere over two million lines of C and C++ in several hundred
>> source files.
>>
>> Without makefiles and dependency checking, the project would likely
>> not be feasible.
>
> Two million lines doesn't sound that huge. With -O0 that would take,
> what, 12-15 minutes on one core? About 2.5K lines second; a rather
> sluggish compiler then.
>
> I guess that must be due to C++? Or loads of header files?
>
> Because I get 15-20Klps for gcc on a machine that is undoubtedly slower
> than yours (it's faster under WSL).
>
> I don't believe your source files are that small either: 2M lines over
> 1000 files would average 2K lines per file.

I created a new folder with 1000 .c files each containing a 2000-line
function.

Plus a 1001st file containing a main() function.

It took Tiny C - /on Windows/ - 3 seconds to turn that lot into an
executable (26MB of source code into 34MB of binary), using tcc *.c.

So having 'hundreds' of files by itself is not a bottleneck.

I then tried it with `gcc *.c`. After 330 seconds, it failed with being
unable to run 'collect2.exe'.

On WSL, 'gcc *.c' took 180 seconds, producing a 34MB executable.

I can't say I am surprised that you [SL but also you in general] use all
means possible, like complex makefile dependencies, to say nothing of
utilising 32 cores, to get anywhere near reasonable build times. But the
underlying problem is not being addressed.

If using -O0 is viable, then look at a faster compiler. Both tcc and gcc
(when it managed it) produced 34MB executables for my test.

Bart <bc@freeuk.com> writes:
>On 13/08/2023 17:02, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 12/08/2023 13:12, Bart wrote:
>>
>>>
>>>> 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.
>>>>
>>>
>>> That particular project takes a minute and a half to compile on my
>>> laptop (it's faster on my main machine). It's 373 compilations, perhaps
>>> 40% of it C++. Too long for convenience.
>>
>> My current project takes well over an hour to build on a single-core
>> system. With 32 cores and parallel make (-j32), that's reduced to
>> less than ten minutes
>
>You don't get a 32x speedup then?

Compiler workloads are generally I/O bound. And as I pointed out,
there is one source file that takes six minutes (although that one
is mostly CPU-bound optimizing the intermediate representation
tree).

>
>> (quicker if not using -O3, since once source file
>> takes 6 minutes itself to build with -O3, two minutes with -O0).
>>
>> Somewhere over two million lines of C and C++ in several hundred
>> source files.
>>
>> Without makefiles and dependency checking, the project would likely
>> not be feasible.
>
>Two million lines doesn't sound that huge. With -O0 that would take,
>what, 12-15 minutes on one core? About 2.5K lines second; a rather
>sluggish compiler then.

Ah, I was off by a factor of three. I hadn't checked recently

$ sloccount . (subdirectory names anonymized)

SLOC Directory SLOC-by-Language (Sorted)
7097238 include ansic=7056951,cpp=40287
884599 tests python=748519,ansic=82789,asm=34873,cpp=18013,sh=405
881989 dir cpp=599779,ansic=281116,python=466,sh=324,asm=304
133020 dir2 cpp=132978,python=42
132319 dir3 cpp=130832,python=1487
25866 tools python=16894,cpp=4300,sh=1900,ansic=1459,perl=1205,
ruby=108
16754 gen ansic=16754
10640 dir7 cpp=10640
8190 common cpp=8190
2024 dir4 cpp=2024
2020 top_dir cpp=2020
1430 dir5 cpp=1430
560 dir6 cpp=560

Totals grouped by language (dominant language first):
ansic: 7439069 (80.84%)
cpp: 956171 (10.39%)
python: 767580 (8.34%)
asm: 35177 (0.38%)
sh: 2629 (0.03%)
perl: 1205 (0.01%)
ruby: 108 (0.00%)

Total Physical Source Lines of Code (SLOC) = 9,201,939
Development Effort Estimate, Person-Years (Person-Months) = 2,904.71 (34,856.56)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 11.09 (133.05)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 261.98
Total Estimated Cost to Develop = $ 392,387,299
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

>
>I guess that must be due to C++? Or loads of header files?
>
>Because I get 15-20Klps for gcc on a machine that is undoubtedly slower
>than yours (it's faster under WSL).
>
>I don't believe your source files are that small either: 2M lines over
>1000 files would average 2K lines per file.

There are a number of C++ source files larger than that, yes.

The bulk of the include files are machine generated, which makes the
cost estimate by David's sloccount unreliable.

Compiled with the GNU Compiler Collection.