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.

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

On 09/08/2023 16:50, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 09/08/2023 15:18, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>
>> CMake Error at CMakeLists.txt:9 (project):
>> Running
>>
>> 'nmake' '-?'
>>
>> failed with:
>>
>> The system cannot find the file specified
>>
>>
>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
>> -- Configuring incomplete, errors occurred!
>>
>> -------------------------------
>>
>> Where does 'nmake' come from?
>
> How can you not know that with your windows background? Are you
> completely incapable of doing a simple internet search?

Do you even know what I'm asking?

'nmake' I vaguely remember being something to do with MS tools.

But what does it have to do with CMake? It's not mentioned in the input,
and you'd think that within its 7300-file, 112MB installation it would
have included everything needed to do its job.

Which seems to be primarily in turning this input:

file( GLOB BBX_COMMON src/*.c )
file( GLOB BBX_COMMONH src/*.h )
file( GLOB BBX_FREETYPE src/freetype/*.c )
file( GLOB BBX_FREETYPEH src/freetype/*.h )
file( GLOB BBX_SAMPLERATE src/samplerate/*.c )
file( GLOB BBX_SAMPLERATEH src/samplerate/*.h )

into data for a makefile. I could even make a stab at that myself, if it
wasn't simpler to just feed that info straight to the compiler.

So, you're the expert, why is it invoking 'nmake' here? What
functionality could possibly not already be included in that substantial
installation that it needs yet more outside help?

And why is it invoking any kind of 'make' program at all given that it's
job to is prepare make input and not actually run make?

The build instructions here are:

cmake ..
make # not nmake

So, what did I do wrong? How about telling me something useful instead
of insults?

On 09/08/2023 16:52, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 09/08/2023 15:48, Richard Harnden wrote:
>>> On 09/08/2023 15: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.
>>>
>>> Then you have too many unrelated things in that directory.
>>
>> That happens.
>
> No, it doesn't. Except, perhaps to you

So, it's a restriction. You are forcing people to use specific working
practices, in that they can't have different versions of any modules in
the same place, or files belonging to different programs. Because a dumb
build system that uses *.c will just blindly include everything.

You can't have 2 files for program A and 3 files program B in the same
folder.

If I had a program with even two modules, I would specify a build
instructions as:

cc one.c two.c

I would NEVER say:

cc *.c

because I have no idea what other crap people might have lying around
when they want to casually build some throwaway program with the
internet. It would be irresponsible.

But I expect all you guys only ever build single module programs as:

cc *.c

anyway. You don't need to bother with the filename, because there will
of course only be the ONE C file in the directory, right?

On 2023-08-09, David Brown <david.brown@hesbynett.no> wrote:
> On 09/08/2023 01:24, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>>> You can't really support Unicode but not support internationalisation,
>>> however.
>> [...]
>>
>> An application could show all its application-defined messages in
>> English, but still handle and display arbitrary text in any language.
>> A word processor that uses English for all its messages and commands
>> can still be used to write a novel in French.
>>
>
> And some words in English need non-ASCII characters to be spelt
> correctly, such as naïve or café. People's names might have non-ASCII

Nope; the correct spelling of "naive" is exactly that, and that's
how it appears in dictionaries.

Only a few lunatic, like at the New Yorker, insist on
spellings like "coöperation".

I can't find clear references on this topic, but somehow, I seem to be
carrying an old impression from somewhere that the use of the diaeresis
for native words is just something that became fashinable in the 1800's.

I.e. it's not simply archaic, but a revival of a passing Victorian
era fad.

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

On 2023-08-09, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-09, David Brown <david.brown@hesbynett.no> wrote:
>> On 09/08/2023 01:24, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> [...]
>>>> You can't really support Unicode but not support internationalisation,
>>>> however.
>>> [...]
>>>
>>> An application could show all its application-defined messages in
>>> English, but still handle and display arbitrary text in any language.
>>> A word processor that uses English for all its messages and commands
>>> can still be used to write a novel in French.
>>>
>>
>> And some words in English need non-ASCII characters to be spelt
>> correctly, such as naïve or café. People's names might have non-ASCII
>
> Nope; the correct spelling of "naive" is exactly that, and that's
> how it appears in dictionaries.
>
> Only a few lunatic, like at the New Yorker, insist on
> spellings like "coöperation".
>
> I can't find clear references on this topic, but somehow, I seem to be
> carrying an old impression from somewhere that the use of the diaeresis
> for native words is just something that became fashinable in the 1800's.
>
> I.e. it's not simply archaic, but a revival of a passing Victorian
> era fad.

A search of Google Books reveals some older uses. E.g. coöperation
appears in the work _Aime at an Up-shot for Infant Baptisme by the Good
Will of Christ, as Priest, Prophet and King, to Fill the Earth with His
Glory_ by one Henry Whistler, dated 1653.

It does seem that the frequency of the word took off in the mid
nineteenth century.

For what it's worth, Ngram Viewer comparison between
coöperation,cooperation,co-operation:

https://books.google.com/ngrams/graph?content=coöperation%2C+cooperation%2C+co-operation&year_start=1600&year_end=2019&corpus=en-2019&smoothing=3

According to this, the diseased version of the word with the
rash/measles over the second "o" flatlinews before around 1825;
it's vanishingly rare compared to the other two. The plain
version "cooperation" was fairly frequent before 1650, and a bit
more so than "co-operation".

This could be completely hokey, but it's what we got.

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

On 08/08/2023 18:31, Malcolm McLean wrote:
> On Tuesday, 8 August 2023 at 17:18:10 UTC+1, David Brown wrote:
>>
>> But do not mistake an understanding of the language and tools for an
>> unbridled fanboy love of all aspects of C. Most of us have things we
>> dislike about the language and common tools - though most of us enjoy
>> using C, or we'd probably not be in this group.
>>
> Yes. I'm a great fan. I woke up at about 4.00 last night and spent the
> whole early morning chasing memory leaks. (I finally managed to
> get valgrind working on a virtual Linux machine). Half of them were
> due to failure to free a string holding a file extension, usually only of
> five bytes (I included the dot, and the null, and three for the extension
> itself). I did think, why didnt I just use C++ and an std::string. Or even
> just knock up some Python scripts.

If you had used Python of C++ strings, you might not have arbitrarily
and inappropriately restricted yourself to three character file extensions.

>
> But the thing is, the C code will likely last practically forever. The C++
> code won't. The CMake script I wrote a few days ago has already been
> deprecated, by the way. It contains a minimum version, and the CMake
> people plan to break compatibility with that version. So it's a good job
> the program can be compiled with a single simple commandline call to gcc.
>

Bart <bc@freeuk.com> writes:

> On 09/08/2023 15:18, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
>>>> On 08/08/2023 19:04, Malcolm McLean wrote:
>>>>> Bart's right about make. If it actually worked properly we wouldn't
>>>>> need CMake.
>>>>
>>>> "make" works perfectly well for its purpose. CMake is a different tool,
>>>> doing a different job. In fact, CMake generates makefiles for use by
>>>> "make" (as well as project files for MSVC, and other types of build
>>>> system). CMake is a higher level tool. ("make" can, in combination
>>>> with compilers like gcc, do a fair amount of higher level work as well,
>>>> such as tracking dependencies and files automatically.)
>>>>
>>> CMake is an alternative to make. It can generate make files, in fact
>>> that's the default.
>>
>> Are you being serious, or has the discussion become so antagonistic that
>> you feel you must deafened this position to the point of absurdity?
>>
>> A tool, X, that generates input for some other tool, Y, is not an
>> alternative to Y. Lex generates input for a C compiler. Lex is not an
>> alternative to a C compiler. Your resource compiler generates input for
>> a C compiler. It is not an alternative to a C compiler. Such tools
>> offer and alternative to writing some (or all) of the input for tool Y.
>
> Maybe he means writing Cmake files as an alternative to writing make
> files.

Of course he does. That's why the statement about the tools (rather
than their inputs) is wrong.

--
Ben.

On 08/08/2023 19:04, Michael S wrote:
> On Tuesday, August 8, 2023 at 7:38:59 PM UTC+3, David Brown wrote:
>> On 08/08/2023 17:09, Bart wrote:

>>> The next one is, how does 'make' know what C compiler I want to use? At
>>> one point I had half a dozen.
>> Clearly these "computah" things are a bit advanced for you. May I
>> recommend an iPad? Or a TV? Because now I am sure you are trolling.
>
> In context of your own remark of few posts above: "(remember, gcc originates
> in a world where people can happily write "make prog" to get the same effect
> - saving a keystroke!)" I find Bart's question perfectly legitimate.
>

That's not an unreasonable interpretation.

In the world where gcc originates, systems always have a standard system
C compiler, accessed as "cc". So that is normally your answer. But you
can choose to override it, such as by setting the CC environment
variable. On systems where gcc is the standard compiler, "cc" points to
"gcc". This is all pretty standard for *nix development.

Alternatively, and this is the method I invariably use myself, "make"
knows which C compiler you want because you tell it in your makefile.
That is also what you want if you are testing multiple compilers.

Bart <bc@freeuk.com> writes:
>[...]
> That doesn't address my points.
>
> Here file name are different. So:
>
> * What happens if there is both test.c and test.cpp?
>
> * What happens if first you want compiler X for test.c and then you
> want compiler Y for test.c?

Why are you asking us? You told us that one of your recent gcc-based
installations include a make command. It probably has documentation for
make as well. Try it yourself.

(Personally, I don't often use make without a Makefile, but it can be a
convenient shortcut.)

--
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 09/08/2023 12:22, Bart wrote:
> On 09/08/2023 03:04, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >
> >> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
> >>>
> >>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
> >>> variable to the name of the compiler:
> >>>
> >>> CC=bcc
> >>> ...
> >>> %.o: %.c
> >>> @$(QUIET) || echo " COMPILE $<"
> >>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
> >>>
> >> Exactly,
> >> Bart is right.
> >
> > You are deliberately ignoring the context.  Bart wants gcc prog.c to
> > write to prog, but in the computer world I inhabit, you do that with
> > make prog.
>
> This is a good example of double standards.
>
> I've complained in the past about having to supply the .c extension to a
> /C/ compiler.
>

There are few things you /haven't/ complained about.

But you might like to remember that the gcc project is a "compiler
collection". The "gcc" executable is a driver program handling C, C++,
Fortran, D, Ada, Go, and perhaps more (I lose track of them all, and it
depends on the version and which languages are built). It might be a
silly idea to have "prog.c" and "prog.cpp" in the same directory, but
it's the user's right to be silly.

> Now here make does not need an extension. And make presumably can build
> any source code of any language?
>

To a fair extent, yes. When you write "make prog", "prog" is the
/executable/, not the source file. Most "make" installations have an
extensive set of default rules that can work well for many people,
configurable with environment variables like CC and CFLAGS. These rules
are used to say how to make an executable from a C file, a C++ file, a
Fortran file, etc. "make" checks each rule in order, until it finds one
that suits.

This is all well documented in the manual for GNU make, or in any
reference for *nix or POSIX which covers standard POSIX make.

> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?
>

It has its default set of rules. The first match is used (I don't know
the priority - it's rarely relevant).

> How does it know that it has to produce (on Windows) prog.exe?
>

That will depend on your packaging of tools - Windows does not follow
POSIX standards, and does not have such tools as standard. But if you
have something like msys2, Cygwin, or WSL, it is likely that the make
rules, the default environment variables, and the files and links in
/usr/bin will result in the same compiler being used as you get with
plain "gcc" in the appropriate shell.

> Wasn't there a huge subthread about people not wanting gcc to
> double-guess the name of the executable, even for a single module, so
> that a.out or a.exe would be the most acceptable result?
>

gcc doesn't guess any names. Nor does make. But make follows a set of
rules (default rules, and/or the rules you give it in a makefile) to
determine precisely (not by guesswork) a set of possible source files
and compile and link commands needed to get the executable you asked for.

> And yet, that is considered common-sense with 'make'? Hmmm....
>

No - as usual, you misunderstand, probably wilfully.

> Besides, there are issues here; make will not supply the -lm flag when
> it is needed for example.
>

How would it know if the flag were needed? It would know if you tell
it. If the compile and/or link commands that you want are anything
other than the default ruleset, you write a makefile (or at least change
the appropriate environment variables). Unlike you, "make" does not
guess or make stuff up, it follows documented rules.

> And if you do 'make prog' a second time, it will not run the compiler
> again.

Of course not. That's part of the point.

> (Sometimes, you are timing how long the compilation takes!

Then, as always, you have to understand a bit about what you are doing.
It's not rocket science - delete the program, run "touch" on the source,
or use "make -B".

> Or
> maybe there's a time-stamp inside the program.)
>

What difference do you think that makes?

> Or you need to compile first with -O0 and then when -O3.
>

Set your CFLAGS as you want.

> > because he hates make almost as much as he hates C, so he adds another
> > twist -- what about all the compilers I have installed?  Well, on my
> > system (hardly a special one) the answer for make-haters is, say,
> >
> >    CC=tcc make prog
> >
> > Now you can put CC=tcc into a one-line makefile or say "export CC=tcc"
> > if you plan to do a lot of tcc builds but I expect even that will result
> > in a lot of fainting and clutching at pearls with the horrid complexity
> > of it all.
>
> When comparing different compilers I might do:
>
>    bcc prog
>    tcc prog.c
>    gcc prog.c
>    gcc prog.c -O3
>
>    dmc prog.c           in the past
>    lcc prog.c
>    cl prog.c
>
> (All of these produce prog.exe - except gcc which produces a.exe,
> obviously, because that's the most useful choice, right?!)
>
> So how does make help here?
>
>

Only a perverse masochist would want to have the same output file for
all of these, as they would be impossible to test. So you would have a
makefile such as :

prog.bcc : prog.c
bcc prog

prog.gcc0 : prog.c
gcc -O0 prog.c -o prog.gcc0

prog.gcc3 : prog.c
gcc -O3 prog.c -o prog.gcc3

and so on.

Then type "make", and you'll get all the programs. Or "make prog.gcc0"
to get just one. And every time you change your source, "make" is all
you need. It's all about putting in a tiny effort now, and saving lots
of effort ever after.

Bart <bc@freeuk.com> writes:

> On 09/08/2023 03:04, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>>>>
>>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>>>> variable to the name of the compiler:
>>>>
>>>> CC=bcc
>>>> ...
>>>> %.o: %.c
>>>> @$(QUIET) || echo " COMPILE $<"
>>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>>>>
>>> Exactly,
>>> Bart is right.
>>
>> You are deliberately ignoring the context. Bart wants gcc prog.c to
>> write to prog, but in the computer world I inhabit, you do that with
>> make prog.
>
> This is a good example of double standards.
>
> I've complained in the past about having to supply the .c extension to a
> /C/ compiler.
>
> Now here make does not need an extension.

I call it consistency. A compiler is given the file to process, make is
given the file to build (AKA "make").

> And make presumably can build any
> source code of any language?
>
> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?
>
> How does it know that it has to produce (on Windows) prog.exe?

I don't think you really want to know the answers to these questions.
For one thing, it's trivial to find out for yourself. For another, you
aren't going to use make yourself, so I would not be using my time to
help you. You are just hoping that the answers will show just how awful
make is for your particular needs.

> Wasn't there a huge subthread about people not wanting gcc to double-guess
> the name of the executable, even for a single module, so that a.out or
> a.exe would be the most acceptable result?
>
> And yet, that is considered common-sense with 'make'? Hmmm....

Yes, it makes sense. What you give is the relevant file name -- what to
compile (for a compiler) or what make (for make).

> Besides, there are issues here; make will not supply the -lm flag when it
> is needed for example.

Oops, there go the goalposts again! make prog was suggested because you
don't like the output file from gcc prog.c. Neither links with -lm.

> And if you do 'make prog' a second time, it will not run the compiler
> again. (Sometimes, you are timing how long the compilation takes! Or maybe
> there's a time-stamp inside the program.)
>
> Or you need to compile first with -O0 and then when -O3.

Yes, yes, we know -- make does not do what you want! Note that I didn't
suggest it to you. Why would I? I know you hate it. I suggested it to
Malcolm who was making a point about make's complexity, unaware,
apparently, that it can have some very simply uses.

>> because he hates make almost as much as he hates C, so he adds another
>> twist -- what about all the compilers I have installed? Well, on my
>> system (hardly a special one) the answer for make-haters is, say,
>>
>> CC=tcc make prog
>>
>> Now you can put CC=tcc into a one-line makefile or say "export CC=tcc"
>> if you plan to do a lot of tcc builds but I expect even that will result
>> in a lot of fainting and clutching at pearls with the horrid complexity
>> of it all.
>
> When comparing different compilers I might do:
>
> bcc prog
> tcc prog.c
> gcc prog.c
> gcc prog.c -O3
>
> dmc prog.c in the past
> lcc prog.c
> cl prog.c
>
> (All of these produce prog.exe - except gcc which produces a.exe,
> obviously, because that's the most useful choice, right?!)

Do you think anyone has said that a.exe is the best choice? I don't.
That's just spin.

> So how does make help here?

There go the goalposts again. Why would it? Mind you, I don't like
your commands since they overwrite the same executable. When comparing
compilers and flags I use a one-line shell function so that the output
file is, for example, 'gcc-O1-prog'.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 9 August 2023 at 15:18:43 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
>> >> On 08/08/2023 19:04, Malcolm McLean wrote:
>> >> > Bart's right about make. If it actually worked properly we wouldn't
>> >> > need CMake.
>> >>
>> >> "make" works perfectly well for its purpose. CMake is a different tool,
>> >> doing a different job. In fact, CMake generates makefiles for use by
>> >> "make" (as well as project files for MSVC, and other types of build
>> >> system). CMake is a higher level tool. ("make" can, in combination
>> >> with compilers like gcc, do a fair amount of higher level work as well,
>> >> such as tracking dependencies and files automatically.)
>> >>
>> > CMake is an alternative to make. It can generate make files, in fact
>> > that's the default.
>> Are you being serious, or has the discussion become so antagonistic that
>> you feel you must deafened this position to the point of absurdity?
>>
>> A tool, X, that generates input for some other tool, Y, is not an
>> alternative to Y. Lex generates input for a C compiler. Lex is not an
>> alternative to a C compiler. Your resource compiler generates input for
>> a C compiler. It is not an alternative to a C compiler. Such tools
>> offer and alternative to writing some (or all) of the input for tool Y.
>>
> If you're writing a compiler, you can do the token extraction in C, or you
> can do in lex. As it happens the lex produces a C output file, but that's not
> really important. It doesn't matter how it works underneath the hood, all
> you're interested in getting the tokens. So lex is an alternative to
> C.

You have a background in philosophy so I can only assume your reluctance
to address what I wrote and your playing fast and loose with categories
is deliberate. I was talking about tools: "lex" and "a C compiler".

--
Ben.

On 09/08/2023 23:15, David Brown wrote:
> On 09/08/2023 12:22, Bart wrote:
>> On 09/08/2023 03:04, Ben Bacarisse wrote:
>> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> >
>> >> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>> >>>
>> >>> 1) Using a make variable in the rule for '.c' -> '.o' and setting
>> the
>> >>> variable to the name of the compiler:
>> >>>
>> >>> CC=bcc
>> >>> ...
>> >>> %.o: %.c
>> >>> @$(QUIET) || echo " COMPILE $<"
>> >>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>> >>>
>> >> Exactly,
>> >> Bart is right.
>> >
>> > You are deliberately ignoring the context. Bart wants gcc prog.c to
>> > write to prog, but in the computer world I inhabit, you do that with
>> > make prog.
>>
>> This is a good example of double standards.
>>
>> I've complained in the past about having to supply the .c extension to
>> a /C/ compiler.
>>
>
> There are few things you /haven't/ complained about.
>
> But you might like to remember that the gcc project is a "compiler
> collection". The "gcc" executable is a driver program handling C, C++,
> Fortran, D, Ada, Go, and perhaps more (I lose track of them all, and it
> depends on the version and which languages are built). It might be a
> silly idea to have "prog.c" and "prog.cpp" in the same directory, but
> it's the user's right to be silly.
>
>> Now here make does not need an extension. And make presumably can
>> build any source code of any language?
>>
>
> To a fair extent, yes. When you write "make prog", "prog" is the
> /executable/, not the source file. Most "make" installations have an
> extensive set of default rules that can work well for many people,
> configurable with environment variables like CC and CFLAGS. These rules
> are used to say how to make an executable from a C file, a C++ file, a
> Fortran file, etc. "make" checks each rule in order, until it finds one
> that suits.
>
> This is all well documented in the manual for GNU make, or in any
> reference for *nix or POSIX which covers standard POSIX make.
>
>> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?
>>
>
> It has its default set of rules. The first match is used (I don't know
> the priority - it's rarely relevant).
>
>> How does it know that it has to produce (on Windows) prog.exe?
>>
>
> That will depend on your packaging of tools - Windows does not follow
> POSIX standards, and does not have such tools as standard. But if you
> have something like msys2, Cygwin, or WSL, it is likely that the make
> rules, the default environment variables, and the files and links in
> /usr/bin will result in the same compiler being used as you get with
> plain "gcc" in the appropriate shell.
>
>> Wasn't there a huge subthread about people not wanting gcc to
>> double-guess the name of the executable, even for a single module, so
>> that a.out or a.exe would be the most acceptable result?
>>
>
> gcc doesn't guess any names. Nor does make. But make follows a set of
> rules (default rules, and/or the rules you give it in a makefile) to
> determine precisely (not by guesswork) a set of possible source files
> and compile and link commands needed to get the executable you asked for.
>
>> And yet, that is considered common-sense with 'make'? Hmmm....
>>
>
> No - as usual, you misunderstand, probably wilfully.
>
>> Besides, there are issues here; make will not supply the -lm flag when
>> it is needed for example.
>>
>
> How would it know if the flag were needed? It would know if you tell
> it. If the compile and/or link commands that you want are anything
> other than the default ruleset, you write a makefile (or at least change
> the appropriate environment variables). Unlike you, "make" does not
> guess or make stuff up, it follows documented rules.
>
>> And if you do 'make prog' a second time, it will not run the compiler
>> again.
>
> Of course not. That's part of the point.
>
>> (Sometimes, you are timing how long the compilation takes!
>
> Then, as always, you have to understand a bit about what you are doing.
> It's not rocket science - delete the program, run "touch" on the source,
> or use "make -B".
>
>> Or maybe there's a time-stamp inside the program.)
>>
>
> What difference do you think that makes?

Maybe that needs to be reflected in the resulting executable.

(My hello programs contain timestamps. I have so many language projects
and versions, I need to ensure a new executable /has/ just been created,
and I'm not running an old version.

Here:

c:\mx>ms hello
Hello World! 00:17:29

c:\mx>ms hello
Hello World! 00:17:31

you can tell that 'ms' (one of my M compilers) is running freshly
compiled sources each time.)

> Only a perverse masochist would want to have the same output file for
> all of these, as they would be impossible to test.

Well, they /are/ the same program! The thing about gcc is that it keeps
using the same output file even for DIFFERENT programs.

Funny how the former irks you, but you're OK with the latter.

Usually you run compile and run, then try another compiler. If they need
to persist or co-exist, then you might think about alternate output
names or locations.

> Then type "make", and you'll get all the programs. Or "make prog.gcc0"
> to get just one. And every time you change your source, "make" is all
> you need. It's all about putting in a tiny effort now, and saving lots
> of effort ever after.
>

You're channeling lots of diverse, ad hoc compilations through a single
program. Instead of doing A or B or C, you invoke make to do A or B or C
for you, but now you have to tell it exactly how or when by editing a
makefile, which is less flexible and less spontaneous.

When scripting is actually needed for a repeated set of invocations,
then everybody understands a shell script, which is just what you type
on the command line, perhaps parametised. Stick that into a file, and
you're done.

Or it can be done using system() calls from any proper language.

You don't need make. And usually the requirements don't stretch to
scripting - you just want a compiler that needs only the minimal
information to do its job: one name following the name of the compiler:

# Invoke File Extension Output Recomp

bcc prog 1 bcc prog c prog.exe Y
tcc prog.c 2 tcc prog c prog.exe Y
gcc prog.c 2 gcc prog c a.exe Y
gcc prog.c -oprog 3 gcc prog c prog.exe Y
make prog 1 ? prog c? prog.exe? ?

The # indicates the number of pieces of information you have to supply.
If all compilers were like mine where # = 1, then there is no advantage
to using make.

Usually you avoid using gcc as much as possible, as there is an annoying
delay while it builds.

Anyway, 'make' is your thing, it's not mine.

If I really thought such a product was useful, I would write one.

(Notice a peculiar thing about the second gcc invocation: it applies a
default extension of '.exe' to '-oprog'. gcc using some minor AI to
infer the name of a missing file extension? What's got into it, and what
on earth is wrong with having to type .exe a gazillion times?

After all it's nearly always invoked from some makefile isn't it? Common
sense is starting to creep in!)

On 10/08/2023 00:01, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 09/08/2023 03:04, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>>>>>
>>>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>>>>> variable to the name of the compiler:
>>>>>
>>>>> CC=bcc
>>>>> ...
>>>>> %.o: %.c
>>>>> @$(QUIET) || echo " COMPILE $<"
>>>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>>>>>
>>>> Exactly,
>>>> Bart is right.
>>>
>>> You are deliberately ignoring the context. Bart wants gcc prog.c to
>>> write to prog, but in the computer world I inhabit, you do that with
>>> make prog.
>>
>> This is a good example of double standards.
>>
>> I've complained in the past about having to supply the .c extension to a
>> /C/ compiler.
>>
>> Now here make does not need an extension.
>
> I call it consistency. A compiler is given the file to process, make is
> given the file to build (AKA "make").

I call it a complete lack of consistency.

When gcc is given a single C file 'prog.c' to compile, it has absolutely
no idea what the executable could possibly be called, so it calls it
a.exe. That's apparently fine.

Now 'make' is given the name of an executable 'prog' (on Windows, not
even 'prog.exe', which confuses it). Now, suddenly, it makes perfect
sense to look for a matching source file called 'prog.c'!

Why does this inference work only one way?

Suppose 'prog.exe' needs two C files to build it; I guess make can't do
that without further info. So there appears to be a special rule when
there is only one C file. But such a rule can't be applied when there is
one C file submitted to gcc.

Consistency, really?

> Oops, there go the goalposts again! make prog was suggested because you
> don't like the output file from gcc prog.c. Neither links with -lm.

If working with Linux and you need -lm, then 'make prog' won't work.
That's just a fact.

(The need for -lm should have been removed decades ago, but that's
another matter.)

> Do you think anyone has said that a.exe is the best choice? I don't.
> That's just spin.

So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the
bullet and make the change. People should speak up more!

> There go the goalposts again. Why would it? Mind you, I don't like
> your commands since they overwrite the same executable. When comparing
> compilers and flags I use a one-line shell function so that the output
> file is, for example, 'gcc-O1-prog'.

So do I, when doing more indepth tests of bigger applications. Although
there the reason is more practical: it takes so damn long to do an
optimised build with gcc!

On 8/9/2023 4:22 PM, Bart wrote:
> On 09/08/2023 23:15, David Brown wrote:
> > On 09/08/2023 12:22, Bart wrote:
> >> On 09/08/2023 03:04, Ben Bacarisse wrote:
> >>  > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>  >
> >>  >> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
> >>  >>>
> >>  >>> 1) Using a make variable in the rule for '.c' -> '.o' and setting
> >> the
> >>  >>> variable to the name of the compiler:
> >>  >>>
> >>  >>> CC=bcc
> >>  >>> ...
> >>  >>> %.o: %.c
> >>  >>> @$(QUIET) || echo " COMPILE $<"
> >>  >>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
> >>  >>>
> >>  >> Exactly,
> >>  >> Bart is right.
> >>  >
> >>  > You are deliberately ignoring the context.  Bart wants gcc prog.c to
> >>  > write to prog, but in the computer world I inhabit, you do that with
> >>  > make prog.
> >>
> >> This is a good example of double standards.
> >>
> >> I've complained in the past about having to supply the .c extension to
> >> a /C/ compiler.
> >>
> >
> > There are few things you /haven't/ complained about.
> >
> > But you might like to remember that the gcc project is a "compiler
> > collection".  The "gcc" executable is a driver program handling C, C++,
> > Fortran, D, Ada, Go, and perhaps more (I lose track of them all, and it
> > depends on the version and which languages are built).  It might be a
> > silly idea to have "prog.c" and "prog.cpp" in the same directory, but
> > it's the user's right to be silly.
> >
> >> Now here make does not need an extension. And make presumably can
> >> build any source code of any language?
> >>
> >
> > To a fair extent, yes.  When you write "make prog", "prog" is the
> > /executable/, not the source file.  Most "make" installations have an
> > extensive set of default rules that can work well for many people,
> > configurable with environment variables like CC and CFLAGS.  These rules
> > are used to say how to make an executable from a C file, a C++ file, a
> > Fortran file, etc.  "make" checks each rule in order, until it finds one
> > that suits.
> >
> > This is all well documented in the manual for GNU make, or in any
> > reference for *nix or POSIX which covers standard POSIX make.
> >
> >> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?
> >>
> >
> > It has its default set of rules.  The first match is used (I don't know
> > the priority - it's rarely relevant).
> >
> >> How does it know that it has to produce (on Windows) prog.exe?
> >>
> >
> > That will depend on your packaging of tools - Windows does not follow
> > POSIX standards, and does not have such tools as standard.  But if you
> > have something like msys2, Cygwin, or WSL, it is likely that the make
> > rules, the default environment variables, and the files and links in
> > /usr/bin will result in the same compiler being used as you get with
> > plain "gcc" in the appropriate shell.
> >
> >> Wasn't there a huge subthread about people not wanting gcc to
> >> double-guess the name of the executable, even for a single module, so
> >> that a.out or a.exe would be the most acceptable result?
> >>
> >
> > gcc doesn't guess any names.  Nor does make.  But make follows a set of
> > rules (default rules, and/or the rules you give it in a makefile) to
> > determine precisely (not by guesswork) a set of possible source files
> > and compile and link commands needed to get the executable you asked
> for.
> >
> >> And yet, that is considered common-sense with 'make'? Hmmm....
> >>
> >
> > No - as usual, you misunderstand, probably wilfully.
> >
> >> Besides, there are issues here; make will not supply the -lm flag when
> >> it is needed for example.
> >>
> >
> > How would it know if the flag were needed?  It would know if you tell
> > it.  If the compile and/or link commands that you want are anything
> > other than the default ruleset, you write a makefile (or at least change
> > the appropriate environment variables).  Unlike you, "make" does not
> > guess or make stuff up, it follows documented rules.
> >
> >> And if you do 'make prog' a second time, it will not run the compiler
> >> again.
> >
> > Of course not.  That's part of the point.
> >
> >> (Sometimes, you are timing how long the compilation takes!
> >
> > Then, as always, you have to understand a bit about what you are doing.
> > It's not rocket science - delete the program, run "touch" on the source,
> > or use "make -B".
> >
> >> Or maybe there's a time-stamp inside the program.)
> >>
> >
> > What difference do you think that makes?
>
> Maybe that needs to be reflected in the resulting executable.
>
> (My hello programs contain timestamps. [...]

Up to what precision?

Bart <bc@freeuk.com> writes:
[...]
> I call it a complete lack of consistency.
>
> When gcc is given a single C file 'prog.c' to compile, it has
> absolutely no idea what the executable could possibly be called, so it
> calls it a.exe. That's apparently fine.
>
> Now 'make' is given the name of an executable 'prog' (on Windows, not
> even 'prog.exe', which confuses it). Now, suddenly, it makes perfect
> sense to look for a matching source file called 'prog.c'!
>
> Why does this inference work only one way?

Because both make and gcc were specifically designed with defaults that
you personally don't like, for the sole purpose of annoying you. You
should avoid using either of them.

[...]

--
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 2023-08-09, Bart <bc@freeuk.com> wrote:
> So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the

If I were to guess, it's because the only person in the world who cares
about it just complains in a newsgroup, that nobody in GCC development
reads.

Plus there are probably scripts out there that depend on a.out
popping out of the compiler.

(The GCC people don't even read the mailing list intended for GCC
patches. In April 2022 I submitted a change (documented and test cased).
Pinged a few times over the following six months. Never got a reply.)

> bullet and make the change. People should speak up more!

People don't speak up until you break stuff. Then they are very loud.

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

On 10/08/2023 01:21, Kaz Kylheku wrote:
> On 2023-08-09, Bart <bc@freeuk.com> wrote:
>> So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the
>
> If I were to guess, it's because the only person in the world who cares
> about it just complains in a newsgroup, that nobody in GCC development
> reads.
>
> Plus there are probably scripts out there that depend on a.out
> popping out of the compiler.

How many depend on a.exe coming out of it?

tcc prog.c on Linux produces a.out as default.

tcc prog.c on Windows produces prog.exe as default. Has that caused many
problems?

gcc on Windows could have done the same. I'm not too worried about
Linux, they have a lot more to contend with anyway.

> (The GCC people don't even read the mailing list intended for GCC
> patches. In April 2022 I submitted a change (documented and test cased).
> Pinged a few times over the following six months. Never got a reply.)
>
>> bullet and make the change. People should speak up more!
>
> People don't speak up until you break stuff. Then they are very loud.

If they can speak up then they can also fix their scripts. After all /I/
have to use special scripts and provide special instructions to get
around that anomaly; what makes those expecting that ridiculous 'a.out'
or 'a.exe' so special?

(And what about the people who have an actual application called
'a.exe', which is then unexpectedly overwritten by somebody using gcc on
a totally unrelated program and possibly an unrelated language! I
already have an actual program called aa.exe.)

On Wednesday, 9 August 2023 at 21:27:58 UTC+1, David Brown wrote:
> On 08/08/2023 18:31, Malcolm McLean wrote:
> > On Tuesday, 8 August 2023 at 17:18:10 UTC+1, David Brown wrote:
> >>
> >> But do not mistake an understanding of the language and tools for an
> >> unbridled fanboy love of all aspects of C. Most of us have things we
> >> dislike about the language and common tools - though most of us enjoy
> >> using C, or we'd probably not be in this group.
> >>
> > Yes. I'm a great fan. I woke up at about 4.00 last night and spent the
> > whole early morning chasing memory leaks. (I finally managed to
> > get valgrind working on a virtual Linux machine). Half of them were
> > due to failure to free a string holding a file extension, usually only of
> > five bytes (I included the dot, and the null, and three for the extension
> > itself). I did think, why didnt I just use C++ and an std::string. Or even
> > just knock up some Python scripts.
>
> If you had used Python of C++ strings, you might not have arbitrarily
> and inappropriately restricted yourself to three character file extensions.
>
Do learn to read. The allocations were of five bytes, because of course
the files had tiny extensions. So usually only five bytes. But of course the
filename comes from the user, and he could pass a massive one as a joke,
or because some automatic process for generating filenames has got out
of control. So the extension is extracted and held in dynamic memory.

Ys, C++ or Python would be far more convenient here, I was making that
point.

On Thursday, 10 August 2023 at 01:21:40 UTC+1, Kaz Kylheku wrote:
> On 2023-08-09, Bart <b...@freeuk.com> wrote:
> > So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the
> If I were to guess, it's because the only person in the world who cares
> about it just complains in a newsgroup, that nobody in GCC development
> reads.
>
When I first used it, I thought it was a bit odd. Especially when the second
run overwrote a.out instead of writing b.out.
>
> Plus there are probably scripts out there that depend on a.out
> popping out of the compiler.
>
Yes. It's hard to change something like that, because you'll break things that
work, but nobody quite understands.

Bart <bc@freeuk.com> writes:

> On 10/08/2023 00:01, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 09/08/2023 03:04, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>>>>>>
>>>>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>>>>>> variable to the name of the compiler:
>>>>>>
>>>>>> CC=bcc
>>>>>> ...
>>>>>> %.o: %.c
>>>>>> @$(QUIET) || echo " COMPILE $<"
>>>>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>>>>>>
>>>>> Exactly,
>>>>> Bart is right.
>>>>
>>>> You are deliberately ignoring the context. Bart wants gcc prog.c to
>>>> write to prog, but in the computer world I inhabit, you do that with
>>>> make prog.
>>>
>>> This is a good example of double standards.
>>>
>>> I've complained in the past about having to supply the .c extension to a
>>> /C/ compiler.
>>>
>>> Now here make does not need an extension.
>>
>> I call it consistency. A compiler is given the file to process, make is
>> given the file to build (AKA "make").
>
> I call it a complete lack of consistency.

Noted.

>> Oops, there go the goalposts again! make prog was suggested because you
>> don't like the output file from gcc prog.c. Neither links with -lm.
>
> If working with Linux and you need -lm, then 'make prog' won't work. That's
> just a fact.

2+2 = 4. That's just a fact.

>> Do you think anyone has said that a.exe is the best choice? I don't.
>> That's just spin.
>
> So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED?

From "I don't think it's the best choice" you go to "everyone thinks
it's bad"? Do you really have no background in party politics?

> Bite the bullet
> and make the change. People should speak up more!

There is too much "speaking up" altogether. I blame the Internet.
People should act or contribute instead. And we should act on things
that matter to us and our communities. You'd need a micrometer to
measure how much I care about the default output file of a C compiler.

--
Ben.

On 2023-08-10, Bart <bc@freeuk.com> wrote:
> On 10/08/2023 01:21, Kaz Kylheku wrote:
> > On 2023-08-09, Bart <bc@freeuk.com> wrote:
> >> So if everyone thinks it's bad, WHY HAS IT NOT BEEN FIXED? Bite the
> >
> > If I were to guess, it's because the only person in the world who cares
> > about it just complains in a newsgroup, that nobody in GCC development
> > reads.
> >
> > Plus there are probably scripts out there that depend on a.out
> > popping out of the compiler.
>
> How many depend on a.exe coming out of it?

That's not easily knowable.
>
> tcc prog.c on Linux produces a.out as default.
>
> tcc prog.c on Windows produces prog.exe as default. Has that caused many
> problems?

If, ever since it had been possible to run "tcc prog.c" on Windows, it
always produced prog.exe, then we know it would not have caused any
problems, since no breaking change took place in that regard!

> gcc on Windows could have done the same.

I think this may have been introduced by MinGW? Not sure how far back
it goes.

I can see that although a.exe is different from a.out, anything from
Unix being ported to Windows that depends on a.out would be easier
to fix to a.exe than to prog.exe, where prog is a variable term that
is derived from the file name.

Like imagine something like this:

for x in $sources; do
compile $x;
frob a.out
fi

porting that to the GNU environment for Windows would just mean
making it do

for x in $sources; do
compile $x;
frob $A_OUT # defined somewhere at the top
fi

Whereas if we have a different behavior on Windows:

for x in $sources; do
compile $x;
if [ $windows ] ; do
frob $x.exe
else
frob a.out
fi
fi

Basically it's not worth doing things too differently in just one
platform port of the compiler. Either fix it everywhere or else
stick with the way it is as much as possible.

I would have made it A.OUT.EXE.

Usually, the .exe something you have to add. Programs ported to
Windows typically define, in their build systems, some variable like
$exe_suffix which expands to .exe on Windows, or else nothing.

a.exe breaks this pattern; it doesn't just add a $exe_suffix
to a.out.

> > (The GCC people don't even read the mailing list intended for GCC
> > patches. In April 2022 I submitted a change (documented and test cased).
> > Pinged a few times over the following six months. Never got a reply.)
> >
> >> bullet and make the change. People should speak up more!
> >
> > People don't speak up until you break stuff. Then they are very loud.
>
> If they can speak up then they can also fix their scripts. After all /I/

If you're going to break users, there has to be relatively big payoff.
Breaking some dinky thing like this is just a gratuitous breakage
that users will perceive as providing no benefit, causing resentment.

Even in your scripts, you will end up choosing a different executable
name since you compile a given .c file with half a dozen different
compilers and code generation options thereof; presumably you want
to retain the executables simultaneously so you can comparatively
disassemble them and whatnot.

It's a very narrow test case.

> have to use special scripts and provide special instructions to get
> around that anomaly; what makes those expecting that ridiculous 'a.out'
> or 'a.exe' so special?

What makes them so special relative to your special scripts is simply
this: those ridiculous anomalies existed first.

That's it.

> (And what about the people who have an actual application called
> 'a.exe', which is then unexpectedly overwritten by somebody using gcc on
> a totally unrelated program and possibly an unrelated language! I
> already have an actual program called aa.exe.)

They would have to be compiling a program in such a way that the
current directory is the installation directory of a.exe,
and they have write permissions to a.exe.

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

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> I would have made it A.OUT.EXE.
[...]

Having more than one '.' in a file name might be a problem for some
(old) systems.

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/18e63b13-ba43-4f5f-a5b7-11e871b71f14

AOUT.EXE would have worked, but A.EXE arguably follows the convention
that the base part of the file name is short for "assembler", with only
the extension being changed because DOS and Windows require it; it could
also be confused with the French word for August.

The choice was arbitrary, and I'm not too bothered about the specifics.

--
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 09/08/2023 14:32, Bart wrote:
> On 09/08/2023 12:05, Dan Purgert wrote:
> > On 2023-08-09, Bart wrote:
> >> On 09/08/2023 03:04, Ben Bacarisse wrote:
>
> >> How does it know then to deal with prog.c and not prog.cpp or prog.ftn?
> >
> > Because you wrote your makefile target such that it's dealing with
> > "prog.c" and not prog.cpp or prog.ftn.  Make isn't intelligent in the
> > case of changing file extensions or similar.  For example, renaming
> > "prog.c" to "prog.cpp" will result in 'file not found' errors when make
> > is trying to run the defined 'gcc prog.c -o prog' command.
>
> I was replying to a post that says you can use 'make' without any
> makefile; give it a filename, not even an extension, and it can
> determine exactly what you want to do, even though it is not specific to
> a language or compiler.
>

You can. Make installations usually have a set of default rules that
work in simple cases.

But if you have a more advanced case, you need at least some rules in
your makefile. Surely this is not a surprise to you.

> The suggestion was that it addresses some of my concerns with running
> command-line compilers like gcc:
>

Make will address /some/ of your complaints with gcc, even without a
makefile. With a makefile, it will address many more.

> * You have to supply the extension (I hate that)

We all feel /so/ sorry for you. Imagine having to type ".c" sometimes -
the horror! If you add up all the Usenet posts you've made complaining
about trivia, it would cover many lifetimes' worth of ".c" or "_t".

>
> * You either have to tell it the name of the output file, or live
>   with having to use a.exe (so you run the compiler on several
>   programs, only the last will have an executable).
>

Do you also complain that your screwdriver doesn't automatically know
which screw you want to turn?

> It's a nice demo, but it's not practical, because my requirements for
> simple cross-compiler builds are diverse.
>

It doesn't matter how spoonfeed you are, you'll always whine.

>
> >>
> >> How does it know that it has to produce (on Windows) prog.exe?
> >
> > It doesn't, unless you have a "_forWin" target that names the output
> > "prog.exe".
> >
> >> [...]
> >> And if you do 'make prog' a second time, it will not run the compiler
> >> again. (Sometimes, you are timing how long the compilation takes! Or
> >> maybe there's a time-stamp inside the program.)
> >
> > Make is written to save compile time.  Why bother re-compiling half a
> > dozen supporting files when all I did was patch out a bug in 'main()'?
>
> Yes, that is one reason that it is so complicated.

Or simple - according to preference and needs.

> You have to define
> set of dependences between modules (and you may need to do that
> manually, so it can be error prone).
>

I do it all automatically. But you'll blow a fuse if I try to tell you how.

On Thursday, August 10, 2023 at 2:01:55 AM UTC+3, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 09/08/2023 03:04, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
> >>>>
> >>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
> >>>> variable to the name of the compiler:
> >>>>
> >>>> CC=bcc
> >>>> ...
> >>>> %.o: %.c
> >>>> @$(QUIET) || echo " COMPILE $<"
> >>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
> >>>>
> >>> Exactly,
> >>> Bart is right.
> >>
> >> You are deliberately ignoring the context. Bart wants gcc prog.c to
> >> write to prog, but in the computer world I inhabit, you do that with
> >> make prog.
> >
> > This is a good example of double standards.
> >
> > I've complained in the past about having to supply the .c extension to a
> > /C/ compiler.
> >
> > Now here make does not need an extension.
>
> I call it consistency. A compiler is given the file to process, make is
> given the file to build (AKA "make").

I disagree.
Consistent design, a.k.a. principle of minimal surprise, would be for basal
utility 'make' to have no built-in rules. On top of it, system can supply one or
more extended utilities, probably implemented as shell scripts, that do have
built-in rules.
Following this path of thought, instead of implicitly named 'makefile' my basal
utility will require explicit name for the input file that holds rules.