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.

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

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

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

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

>>
>> 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. You have to define
set of dependences between modules (and you may need to do that
manually, so it can be error prone).

But to ME, that is not important, because, for example:

(1) I'm using it to debug a just-downloaded open-source project which
has to be compiled from scratch anyway. So that complexity is
unnecessary, yet it can cause failures

(2) The compilers I like to use are super-fast (like 0.5-1.0 million
lines per second), so compiling from scratch is more or less instant
anyway

(My main compiler can build each of my 30-50Kloc language projects in
about the same time duration as one of the shorter notes in 'Flight of
the Bumblebee' played at 170bpm, ie. some 85ms.)

On Wednesday, 9 August 2023 at 12:43:06 UTC+1, David Brown wrote:
> On 09/08/2023 05:23, Malcolm McLean wrote:
>
> > CMake is an alternative to make.
> It is a "meta-build" tool, aimed at a higher level than make, and which
> generates scripts or control files for various uses - makefiles, MSVC
> project files, and others. For some kinds of project, that might be a
> good choice - sometimes it makes sense to separate the tasks of
> calculating dependencies and settings, and actually controlling the
> build. But since on many platforms CMake depends on make, it is not an
> alternative. And CMake is not flexible enough for many uses - when I
> have looked at it, it was not remotely flexible enough to do the kinds
> of things I do with make. Many people use CMake, so it must have
> merits, but it is not a replacement for make.
>
CMake has a "generator", which is their word for target output format.
So you can use it to generate Xcode or Visual Studio files, or make files.
The two big advantages are that you don't have to ship an Xcode or
Visual Studio project file. CMake generates it for your client. And the
Cmkae scripts are easier to read and maintain than makefiles.
> > It can generate make files, in fact that's the
> > default. Which means that if you ship a project with a CMake script, you
> > wouldn't normally provide a make file. CMake found a niche largely because
> > make files are too difficult to use. The other reason is that the big IDEs
> > rejected makefiles as their format for describing how to build projects.
> Every IDE of any quality can handle projects that are built using
> external makefiles. An IDE that won't run "make" at the press of a
> hotkey is as useful as an IDE that can't handle ASCII format test files.
>
> But if you have an external manually written makefile, that is not
> project management - so usually you also then have to make an IDE
> project to describe the source files, include search paths, pre-defined
> macros, etc. That can be a duplicate of work (though good makefiles
> find the source files and dependencies mostly automatically), and
> duplication can lead to mistakes.
>
My point is that when the first IDEs came out, they could have said "the project
description file will be a makefile, maybe with added comments to represent
information needed by the iDE but not by the compiler". They opted not to
do this.
>
> The norm AFIK for build systems controlled by IDEs is make - they
> generate makefiles automatically based on your project settings, dialog
> boxes for choosing compiler flags, etc. Such systems can work
> reasonably well, though a well-made manual makefile is often much better
> at calculating dependency information for large projects.
>
There's a big difference between automatic scripts and ones written by humans.
If something goes wrong with the automatic script, whilst a human programmer
might have to look at it, basically the problem is almost certainly in the program
which generated the script. So it doesn't matter too much if the script is
unreadable. As long as the generating program is well-structured and
debuggable.
>
> Some IDEs may generate CMake files, then run CMake, then make - I have
> (unsurprisingly) not used all IDEs.
>
> CMake, as far as I understand it, is popular when you want a project to
> build on Linux with gcc and Windows with MSVC - that is its niche.
>
Which is exactly Baby X.
>
> So if you are part of a development team, and your team is rejecting
> "make" on the basis of "it's too hard to understand", your development
> team is in a /lot/ of trouble. New management - or at least training
> for the management - should be number one priority until the job is run
> by people that understand about using the best tools for the job, and
> training people in the jobs that need done. (Of course, if CMake really
> is a better choice for your project, that's fine - make is not the only
> tool in the box.)
>
I don't think you understand how you come over sometimes.
No one at work wants to use make for managing resources. You don't know
better than we do how to set up our development process.
>
> > It works.
> Your evidence for that is ... what? You need users and feedback to
> establish that. And maybe your XML is turning away potential users - it
> would turn me away, certainly.
>
I've written a test program which internationises a string. So the system works
from a narrow technical point of view. The question is about the softer
considerations of what people actually want to use.
> > The question is whether it's a good approach to the problem.
> Indeed. (My criticism here is intended as constructive, to suggest
> better choices.)
> > As I said, the user of Baby X will be mostly hobby programmers.
> If your description of it is accurate, why are you limiting it like
> that? Many professional developers would like better simple
> cross-platform gui tools and toolkits. And if it is not better than
> existing options, why bother with it at all? The only time it makes
> sense to target hobby users alone is if the existing alternatives are
> hugely complex, or hugely expensive, and that is not the case here.
> Professionals also like "easy to use".
>
We use Qt for one of our products. Not one that I work on personally.
But one of the developers told me that he had had a 12 hour build.
Of course the Qt product is super polished, and he is being paid for
those twelve hours. So it's worth it for us. But for hobby programming
it's probably not. Baby X will build in a few seconds.
> > So the
> > emphasis is on making things easy to use. Adding alternative translations
> > under an <international> tag is easy to do.
> >
> No, the translation system is /not/ easy to use, and horrendous to maintain.
>
> Look, imagine a developer wanted French and German translations. It's
> just a single programmer, but he has a couple of friends who speak those
> languages. With your solution, these two friends are mixing and editing
> the same file, at the same time, while the programmer is simultaneously
> modifying the file for other purposes. It is absolute madness. Do you
> not understand that the French translations need to go in one file, and
> the German translations need to go in a different file, and there is
> /no/ circumstances in which it is a good idea to mix them all together
> in one horrible XML file?
>
Yes but think of someone who lives inFrance, and speaks French as his native
language and English as a second language, but no others. He'll like the idea
that he can toggle his Baby X program between English and French. But he
can't afford to send off the strings to a professional translator to get in
other languages. For him, the system as it stands is ideal (I think, I'm open
to suggestions).
>
> Anyone trying to use your tool for something more than a "Hello world"
> program will write their own pre-processor to generate your XML file!
>
That would be a disaster and destroy the main point of the resource compiler.
However no such program can support every type of processing you might need.
It can resize images, but not do gamma correction, for example.
>
> > However I fully accept that there might be a far better approach. Keith
> > Thompson has made some constructive suggestions.
> >
> Yes - when standard formats and tools exist, use them.
> > XML has some advantages over an ad-hoc line-based format. The parser needs
> > work as it's currently too basic. But XML should be familiar to most programmers.
> >
> XML is familiar as a concept of hatred by most programmers - something
> forced upon them by clueless management and marketing people who think
> it is a great buzzword. Almost nobody chooses XML voluntarily.
>
Ah, so you are a Bart. But XML rather than C is the target of ire.
In my view, XML is ideal for a resource compiler script format.

On Wednesday, August 9, 2023 at 2:43:06 PM UTC+3, David Brown wrote:
> On 09/08/2023 05:23, Malcolm McLean wrote:
> > On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
> >> On 08/08/2023 19:04, Malcolm McLean wrote:
> >>> On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
> >>>> On 08/08/2023 18:04, Malcolm McLean wrote:
> >>>>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
> >>>>>> On 05/08/2023 14:08, Malcolm McLean wrote:
> >>>>>>
> >>>>>>> This is the problem of course. The Baby X API expects data in a certain format.
> >>>>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
> >>>>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
> >>>>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
> >>>>>>> images.
> >>>>>>
> >>>>>> It would make a lot of sense to have a program that took data in common
> >>>>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
> >>>>>> whatever format suits Baby X.
> >>>>>>
> >>>>> "Data" means, "that which is given". People programming applications are given
> >>>>> resources in many formats. They might steal a PNG from the web, get a JPEG
> >>>>> commissioned from a paid artist, knock up their own SVG.
> >>>>> Now of course it's possible to convert all these into a common format like PNG
> >>>>> which is powerful enough to hold all thse formats without loss. But you've lost
> >>>>> the link with the original data. So when the artist comes back with a second
> >>>>> version of the JPEG, you've got to run ImageMagick again. And I don't have
> >>>>> ImageMagick installed on the Mac I'm writing this on (there's a program called
> >>>>> sips which does similar things).
> >>>>> A resouce pipeline with lots of stages, each one requiring a separate third party
> >>>>> program, is quite fragile. It works for as long as your Linux machine is all set up
> >>>>> with the dependencies, which will be the case for the duration of the project.
> >>>>> But if you archive it, and dust it off years later, will things still be intact? And
> >>>>> will you know which are the intermediate files, and which are the original data?
> >>>> It looks like there is someone else in this group who could benefit from
> >>>> understanding "make" and/or other build tools. And if you can't use a
> >>>> Mac for development, scrap the expensive toy and install a usable
> >>>> system. (Of course, you /can/ use a Mac for development - you just need
> >>>> to know how to use your tools.)
> >>>>
> >>> 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 is a "meta-build" tool, aimed at a higher level than make, and which
> generates scripts or control files for various uses - makefiles, MSVC
> project files, and others. For some kinds of project, that might be a
> good choice - sometimes it makes sense to separate the tasks of
> calculating dependencies and settings, and actually controlling the
> build. But since on many platforms CMake depends on make, it is not an
> alternative. And CMake is not flexible enough for many uses - when I
> have looked at it, it was not remotely flexible enough to do the kinds
> of things I do with make. Many people use CMake, so it must have
> merits, but it is not a replacement for make.
> > It can generate make files, in fact that's the
> > default. Which means that if you ship a project with a CMake script, you
> > wouldn't normally provide a make file. CMake found a niche largely because
> > make files are too difficult to use. The other reason is that the big IDEs
> > rejected makefiles as their format for describing how to build projects..
> Every IDE of any quality can handle projects that are built using
> external makefiles. An IDE that won't run "make" at the press of a
> hotkey is as useful as an IDE that can't handle ASCII format test files.
>
> But if you have an external manually written makefile, that is not
> project management - so usually you also then have to make an IDE
> project to describe the source files, include search paths, pre-defined
> macros, etc. That can be a duplicate of work (though good makefiles
> find the source files and dependencies mostly automatically), and
> duplication can lead to mistakes.
>

No, simply no.
Good makefile finds "other" dependencies mostly automatically, but
makes no attempts to figure out source files.

> The norm AFIK for build systems controlled by IDEs is make - they
> generate makefiles automatically based on your project settings, dialog
> boxes for choosing compiler flags, etc. Such systems can work
> reasonably well, though a well-made manual makefile is often much better
> at calculating dependency information for large projects.
>
> Some IDEs may generate CMake files, then run CMake, then make - I have
> (unsurprisingly) not used all IDEs.
>
> CMake, as far as I understand it, is popular when you want a project to
> build on Linux with gcc and Windows with MSVC - that is its niche.
> >>
> >> One thing that "make" is particularly good at is chains of processes.
> >> It is straightforward to say that "picture.o" is compiled from
> >> "picture.c" which is resource-compiled from "picture.bmp" which is
> >> converted from "picture.jpg". I sometimes have that kind of thing in
> >> makefiles for building documentation, where the graphics files I want to
> >> add to my LaTeX documents might need conversions or manipulations from
> >> the originals.
> >>
> >>> But it's unmaintainable.
> >>
> >> Not for people who are familiar with it.
> >>
> > Many programmers might start a new project only once every two years. And
> > it might not be their job to write the makefile. So they are not going to be very
> > familiar with make. Maintainable software needs to be maintainable by people
> > who don't have a deep familarity with it. I can debug Cmake scripts despite
> > not really knowing the CMake language, because it's close enough to a normal
> > procedural programming language for someone who can program but doesn't
> > know CMake specifically to follow along.
> People need to know how to use their tools. Within any development
> group, you need people who can handle the different parts of the
> development process. Sometimes people can do it all, sometimes there
> are specialists in the group. So someone might be an expert at git,
> someone at make, different programmers can handle different languages,
> and others are good at design, documentation, testing, and all the other
> aspects of software development. Anyone who thinks that "understands C"
> is the be-all and end-all of making and maintaining a software project
> in C is doomed to failure.
>
> So if you are part of a development team, and your team is rejecting
> "make" on the basis of "it's too hard to understand", your development
> team is in a /lot/ of trouble. New management - or at least training
> for the management - should be number one priority until the job is run
> by people that understand about using the best tools for the job, and
> training people in the jobs that need done. (Of course, if CMake really
> is a better choice for your project, that's fine - make is not the only
> tool in the box.)
> >>
> >> Certainly complicated makefiles are harder to deal with than simple
> >> ones. It's a powerful tool with many features, and takes time and
> >> effort to learn. But complicated ones can reduce maintenance - my
> >> makefiles do not need modification as files are added or removed from a
> >> project, or dependencies on headers change - it is all handled
> >> automatically.
> >>
> >>> Baby X is mainly for small hobby type programs. It's easier to use than
> >>> the raw X11 interface, and it's far lighter weight than Qt or GTK. It also
> >>> ports to Windows. So most of the users will be bedroom programmers
> >>> who will set up the internationalisation strings themselves, rather than
> >>> employing professional translators.
> >> That is a hopeless attitude to take. You are simply guaranteeing that
> >> people will not use it for internationalisation - or that they will hate
> >> the tool when they try to use it. Targeting hobby users is not an
> >> excuse for bad design. I would suggest you remove all traces of
> >> internationalisation until you have found a way to make it work. (And
> >> drop the XML format while you are at it - a simple one line, one command
> >> text format would be vastly easier for everyone.)
> >>
> > It works.
> Your evidence for that is ... what? You need users and feedback to
> establish that. And maybe your XML is turning away potential users - it
> would turn me away, certainly.
> > The question is whether it's a good approach to the problem.
> Indeed. (My criticism here is intended as constructive, to suggest
> better choices.)
> > As I said, the user of Baby X will be mostly hobby programmers.
> If your description of it is accurate, why are you limiting it like
> that? Many professional developers would like better simple
> cross-platform gui tools and toolkits. And if it is not better than
> existing options, why bother with it at all? The only time it makes
> sense to target hobby users alone is if the existing alternatives are
> hugely complex, or hugely expensive, and that is not the case here.
> Professionals also like "easy to use".
> > So the
> > emphasis is on making things easy to use. Adding alternative translations
> > under an <international> tag is easy to do.
> >
> No, the translation system is /not/ easy to use, and horrendous to maintain.
>
> Look, imagine a developer wanted French and German translations. It's
> just a single programmer, but he has a couple of friends who speak those
> languages. With your solution, these two friends are mixing and editing
> the same file, at the same time, while the programmer is simultaneously
> modifying the file for other purposes. It is absolute madness. Do you
> not understand that the French translations need to go in one file, and
> the German translations need to go in a different file, and there is
> /no/ circumstances in which it is a good idea to mix them all together
> in one horrible XML file?
>
> Anyone trying to use your tool for something more than a "Hello world"
> program will write their own pre-processor to generate your XML file!
> > However I fully accept that there might be a far better approach. Keith
> > Thompson has made some constructive suggestions.
> >
> Yes - when standard formats and tools exist, use them.
> > XML has some advantages over an ad-hoc line-based format. The parser needs
> > work as it's currently too basic. But XML should be familiar to most programmers.
> >
> XML is familiar as a concept of hatred by most programmers - something
> forced upon them by clueless management and marketing people who think
> it is a great buzzword. Almost nobody chooses XML voluntarily.

On Wednesday, 9 August 2023 at 13:35:18 UTC+1, Michael S wrote:
> On Wednesday, August 9, 2023 at 2:43:06 PM UTC+3, David Brown wrote:
> >
> > But if you have an external manually written makefile, that is not
> > project management - so usually you also then have to make an IDE
> > project to describe the source files, include search paths, pre-defined
> > macros, etc. That can be a duplicate of work (though good makefiles
> > find the source files and dependencies mostly automatically), and
> > duplication can lead to mistakes.
> >
> No, simply no.
> Good makefile finds "other" dependencies mostly automatically, but
> makes no attempts to figure out source files.
>
A major motivation was to avoid unnecessary compilations by only compiling
source which had changed. That's still maybe relevant for massive projects..
But I rebuilt the Baby X resource compiler from scratch, and counted.
"One, two, three .." and it was done. For a program of that size, this is no longer
an issue.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[regarding choice of possible outputs for %a format]

>>>> [T]here is a subtle point that deserves mentioning. If a
>>>> 'double' value is printed using %a, and the same value is
>>>> converted to a 'long double' and printed using %La, in most cases
>>>> the digits (and exponents) of the outputs will be different.
>>>
>>> That does indeed happen in the libc printf I'm using. I am almost
>>> tempted to look at the code to see why that is done. Maybe there
>>> is an obvious reason for it, but I can't think of one off the top
>>> of my head.
>>
>> It happens because of the formats of double and long double. For
>> most non-zero values (and not inf or NaN), a double has 52 bits
>> of significand plus an implied '1' at the top, giving 53 bits
>> overall. Converting to long double gives 64 bits of significand
>> only now the high-order '1' is explicit (ie, 64 bits overall).
>> So double has one bit for the leading digit (always 1) plus 13
>> groups of four bits, whereas long double has four bits for the
>> leading digit (always between 8 and F) plus 15 groups of four
>> bits.
>
> I'd forgotten that Intel long doubles use bit 63 explicitly. So
> you are saying it's just for simplicity -- just dump the nibbles.
> You make it sound almost inevitable, but compatible output, with a
> leading "0x1.", could have been generated. However, there's a lot
> of sense in just dumping the nibbles. For one thing, you get the
> hex values you'd see for if you were to examine memory in a
> debugger.

My guess is the motivation is to make the output more convenient
for a human reader, like in your last sentence. The C standard
has a footnote pointing out that "Binary implementations can
choose the hexadecimal digit to the left of the decimal-point
character so that subsequent digits align to nibble (4-bit)
boundaries." Another benefit, presumably incidental, is that in
most cases we can tell from the output whether the value being
printed came from a double or a long double, which can be
helpful.

>> If you see a %a output whose leading digit is between 8 and F,
>> probably what was done is the double value was converted to a
>> long double, so the long double value could just be funneled
>> through the code for the long double case.
>
> I was wondering why an implementation would do that. Of course,
> you then loose the advantage of getting the hex digits you'd see
> in memory.

Right. Another difference is that a subnormal double would turn
into a normal long double, which effectively takes away a degree
of freedom for how subnormal double values are output. (Note
that for a subnormal input the output is allowed to have the
leading digit be zero.)

On 09/08/2023 13:48, Malcolm McLean wrote:
> On Wednesday, 9 August 2023 at 13:35:18 UTC+1, Michael S wrote:
>> On Wednesday, August 9, 2023 at 2:43:06 PM UTC+3, David Brown wrote:
>>>
>>> But if you have an external manually written makefile, that is not
>>> project management - so usually you also then have to make an IDE
>>> project to describe the source files, include search paths, pre-defined
>>> macros, etc. That can be a duplicate of work (though good makefiles
>>> find the source files and dependencies mostly automatically), and
>>> duplication can lead to mistakes.
>>>
>> No, simply no.
>> Good makefile finds "other" dependencies mostly automatically, but
>> makes no attempts to figure out source files.
>>
> A major motivation was to avoid unnecessary compilations by only
compiling
> source which had changed. That's still maybe relevant for massive
projects.
> But I rebuilt the Baby X resource compiler from scratch, and counted.
> "One, two, three .." and it was done. For a program of that size,
this is no longer
> an issue.

You have a faster machine than I do.

Building your BBX project with gcc 13.2 on Windows takes 11 seconds for
-O0, and 37 seconds for -O3.

My bcc takes just over a second.

(BTW there's an annoying bug in gcc. I put all the files in an @ file,
so it includes lines like this:

freetype\ttapi.c

as is normal for paths on Windows. But gcc ignores the backslash. I have
to write it as /.)

On 09/08/2023 11:58, Bart wrote:
> On 09/08/2023 11:36, Richard Harnden wrote:
>> On 09/08/2023 11: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.
>>>
>>> Now here make does not need an extension. 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?
>>>
>>> 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....
>>>
>>> Besides, there are issues here; make will not supply the -lm flag
>>> when it is needed for example.
>>>
>>> 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.
>>>
>>>  > 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?
>>>
>>>
>>
>> It just does it ...
>>
>> $ >test_c++.cpp
>> $ make test_c++
>> g++     test_c++.cpp   -o test_c++
>>
>> $ >test_c.c
>> $ make test_c
>> cc     test_c.c   -o test_c
>
> That doesn't address my points.
>
> Here file name are different. So:
>
> * What happens if there is both test.c and test.cpp?

The .c will override the .cpp, but I'm sure you can overide the default
suffixes.

Why whould you have a test.c and a test.cpp anyway? How would you know
where your test.exe came from?

>
> * What happens if first you want compiler X for test.c and then you want
> compiler Y for test.c?

$ CC=gcc CFLAGS="-std=c99 -W -Wall -Wextra -O2" make test
gcc -std=c99 -W -Wall -Wextra -O2 test.c -o test
$ rm test
$ CC=g++ make test
g++ test.c -o test

Or it quickly becomes easier to just create an actual Makefile:

$ cat Makefile
default: test_X test_Y test

test_X: test.c
gcc -O2 test.c -o test_X

test_Y: test.c
g++ -O2 test.c -o test_Y

clean:
-rm test_X test_Y test

$ make
gcc -O2 test.c -o test_X
g++ -O2 test.c -o test_Y
cc test.c -o test

On 09/08/2023 13: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.
>
> The suggestion was that it addresses some of my concerns with running
> command-line compilers like gcc:
>
> * You have to supply the extension (I hate that)
>
> * 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).
>
> It's a nice demo, but it's not practical, because my requirements for
> simple cross-compiler builds are diverse.
>
>
> >>
> >> 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. 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

>
> But to ME, that is not important, because, for example:
>
> (1) I'm using it to debug a just-downloaded open-source project which
>     has to be compiled from scratch anyway. So that complexity is
>     unnecessary, yet it can cause failures
>
> (2) The compilers I like to use are super-fast (like 0.5-1.0 million
>     lines per second), so compiling from scratch is more or less instant
>     anyway
>
> (My main compiler can build each of my 30-50Kloc language projects in
> about the same time duration as one of the shorter notes in 'Flight of
> the Bumblebee' played at 170bpm, ie. some 85ms.)
>
>
>

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:
>> > On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
>> >> On 08/08/2023 18:04, Malcolm McLean wrote:
>> >>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
>> >>>> On 05/08/2023 14:08, Malcolm McLean wrote:
>> >>>>
>> >>>>> This is the problem of course. The Baby X API expects data in a certain format.
>> >>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
>> >>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
>> >>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
>> >>>>> images.
>> >>>>
>> >>>> It would make a lot of sense to have a program that took data in common
>> >>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
>> >>>> whatever format suits Baby X.
>> >>>>
>> >>> "Data" means, "that which is given". People programming applications are given
>> >>> resources in many formats. They might steal a PNG from the web, get a JPEG
>> >>> commissioned from a paid artist, knock up their own SVG.
>> >>> Now of course it's possible to convert all these into a common format like PNG
>> >>> which is powerful enough to hold all thse formats without loss. But you've lost
>> >>> the link with the original data. So when the artist comes back with a second
>> >>> version of the JPEG, you've got to run ImageMagick again. And I don't have
>> >>> ImageMagick installed on the Mac I'm writing this on (there's a program called
>> >>> sips which does similar things).
>> >>> A resouce pipeline with lots of stages, each one requiring a separate third party
>> >>> program, is quite fragile. It works for as long as your Linux machine is all set up
>> >>> with the dependencies, which will be the case for the duration of the project.
>> >>> But if you archive it, and dust it off years later, will things still be intact? And
>> >>> will you know which are the intermediate files, and which are the original data?
>> >> It looks like there is someone else in this group who could benefit from
>> >> understanding "make" and/or other build tools. And if you can't use a
>> >> Mac for development, scrap the expensive toy and install a usable
>> >> system. (Of course, you /can/ use a Mac for development - you just need
>> >> to know how to use your tools.)
>> >>
>> > 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.

In the same sense that 'imake' was an alternative to 'make'. They both
are pre-processors that generate makefiles.

>
>XML has some advantages over an ad-hoc line-based format.

Having used 'ant' (a java make analog) a couple decades ago, the only advantages of XML
are machine readability. There's no human advantage.

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.

But this just generates output for a makefile. I can instead do this
with my C compiler:

c:\c>bcc -auto cipher
1 Compiling cipher.c to cipher.asm (Pass 1)
* 2 Compiling hmac.c to hmac.asm (Pass 2)
* 3 Compiling sha2.c to sha2.asm (Pass 2)
Assembling to cipher.exe

It determines the other modules given only the lead module, and produces
a working executable (it took 1/20th of a second). But it only works
with modules tidily written as .h/.c pairs (ie. how I would write C code).

(If I try it with Malcolm's BBX project, it can only detect 25 of the 43
modules by following includes starting from the main module.

gcc -MM will detect all 43 files, but then, 43 files had to be submitted!)

Again, who needs a stinkin' make file?

On 09/08/2023 15:00, The Doctor wrote:
> IS rust dependant on C?

If you mean written in C, then no. It was originally written in OCaml
then self-hosted.

If you mean does it partly depend on tools, OSes, libraries and
infra-structure written in whole or part in C, or with interfaces
expressed in C, then so do most things.

On Wednesday, 9 August 2023 at 14:44:42 UTC+1, Scott Lurndal wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> >XML has some advantages over an ad-hoc line-based format.
> Having used 'ant' (a java make analog) a couple decades ago, the only advantages of XML
> are machine readability. There's no human advantage.
>
I think there is.
The <international> tag takes a list of children with a "language" attribute, for example.
That's natural and intuitive and arises out of XML syntax. If I used a line per resource
format, I'd then have to invent something to represent internationalized strings, which
the user would have no way of knowing in advance.
And all attributes including numbers are quoted. This is a bit of nuisance, of course,
but it's better than some being quoted, some being raw. Which you'd tend to get with
a fomat that was just invented on the spot.
The rule that you have attributes and content is very handy for comment tags.
The user can either specify a text file, or he can enter the comment in the XML. Whilst
Then whilst everyone sane will use one line per tag, XML rules and not unstated
special dormat rules dictate whitespace.
The each tag has to be declared, so it's easy to get a list of supported tags and
document them.

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.

> XML has some advantages over an ad-hoc line-based format. The parser
> needs work as it's currently too basic. But XML should be familiar to
> most programmers.

That's not as much of an advantage as one might think. Programmers know
the /syntax/ of XML, but every application of it uses a different schema.
Since all of the elements and possible attributes need to be documented,
one might as well (often) just document a simpler syntax.

--
Ben.

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.
Sub-directories exist for a reason.

This is not gcc's or make's fault.

>
> But this just generates output for a makefile. I can instead do this
> with my C compiler:
>
>   c:\c>bcc -auto cipher
>      1 Compiling cipher.c     to cipher.asm       (Pass 1)
>   *  2 Compiling hmac.c       to hmac.asm         (Pass 2)
>   *  3 Compiling sha2.c       to sha2.asm         (Pass 2)
>   Assembling to cipher.exe
>
> It determines the other modules given only the lead module, and produces
> a working executable (it took 1/20th of a second). But it only works
> with modules tidily written as .h/.c pairs (ie. how I would write C code).
>
> (If I try it with Malcolm's BBX project, it can only detect 25 of the 43
> modules by following includes starting from the main module.
>
> gcc -MM will detect all 43 files, but then, 43 files had to be submitted!)
>
> Again, who needs a stinkin' make file?
>
>

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.

So you write input for Lex, which produces a lexer, instead of writing
the lexer.

I would however question having a dependency on a big program like CMake
(I'm waiting for it to install as I type this), to build a project of 43
C modules.

Hmm, it's stuck at 58% install. (Drums fingers...) 67%. Jesus. Wouldn't
it faster to just the filenames out manually? Certainly using *.c etc
would be far quicker! 78%... It's a good thing I have an SSD!

...

...

...

OK!! 7300 files, 125 folders and 112MB poorer, it's ready to go.

I follow instructions for this project, and I get this:

-------------------------------
c:\bbx\build>cmake ..
CMake Deprecation Warning at CMakeLists.txt:5 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.

Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.

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? The cmakelists.txt file doesn't mention
it. (And copying make.exe to nmake.exe gives other errors. Is it even
supposed to run make? You said it only generated input for it.)

Anyway I won't waste any more time with it. This is not even as bad as
using a sledgehammer to crack a nut; it can't even find the sledgehammer
after waiting weeks for it to arrive!

Doubtless DB will stay I'm just incompetent. I don't think it's me
that's incompetent.

On 2023-08-09, 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.

Oh, I misunderstood the context of that question of yours then. :/

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

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. File get copied or left over or duplicated. Some get
deleted. I might unzip .c files into a location that already has some .c
files. I might have several differently named versions of a module, and
will choose one for a project.

It's a very crude and unreliable alternative a proper build system, and
places restrictions on what you can do.

> Sub-directories exist for a reason.

Yeah, I should have 243 subdirectories for those myriad throwaway
programs instead.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Wednesday, 9 August 2023 at 14:44:42 UTC+1, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> >XML has some advantages over an ad-hoc line-based format.
>> Having used 'ant' (a java make analog) a couple decades ago, the only advantages of XML
>> are machine readability. There's no human advantage.
>>
>I think there is.
>The <international> tag takes a list of children with a "language" attribute, for example.
>That's natural and intuitive and arises out of XML syntax. If I used a line per resource
>format, I'd then have to invent something to represent internationalized strings, which
>the user would have no way of knowing in advance.

As has been pointed out to you, there are current
mechanisms to support I18n and L10n; specifically
gettext (et alia) and locales.

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?

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.

>File get copied or left over or duplicated. Some get
>deleted.

> I might unzip .c files into a location that already has some .c
>files.

Reminds me of the old joke:

Patient: Doctor, it hurts whenever I drink coffee.
Doctor: Try taking the spoon out of the mug, before you drink.

On Wednesday, 9 August 2023 at 16:48:21 UTC+1, Scott Lurndal wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >On Wednesday, 9 August 2023 at 14:44:42 UTC+1, Scott Lurndal wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> >XML has some advantages over an ad-hoc line-based format.
> >> Having used 'ant' (a java make analog) a couple decades ago, the only advantages of XML
> >> are machine readability. There's no human advantage.
> >>
> >I think there is.
> >The <international> tag takes a list of children with a "language" attribute, for example.
> >That's natural and intuitive and arises out of XML syntax. If I used a line per resource
> >format, I'd then have to invent something to represent internationalized strings, which
> >the user would have no way of knowing in advance.
> As has been pointed out to you, there are current
> mechanisms to support I18n and L10n; specifically
> gettext (et alia) and locales.
>
I'm certainly not the first person to internationalize a program.
But gettext() doesn't appear to be the solution, for example. I'm not saying no-one
should use it. But it's not going to work for Baby X.

On 2023-08-09, Bart <bc@freeuk.com> 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.
>
> Now here make does not need an extension.

Since the thing you want to make is called "prog", yes, that's
what you ask to be made.

Make has a default set of suffix rules. One of them is how to make
an unsuffixed file from a .c file.

> And make presumably can build
> any source code of any language?

No; just a few things associated with Unix.

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

It doesn't. Make is specified by POSIX, which applies to Unix-like
systems.

Someone creating a distribution of POSIX-like tools that run in
Windows has to deal with this problem as an extension. Perhaps
by patching their selected Make (such as GNU Make) to have
a rule for building a .exe from a .c.

It's highly likely that the compiler partially handles the issue; i.e.
that cc -o prog will make a prog.exe.

However, if a make rule thinks it is building prog, but the
recipe builds prog.exe, the recipe has not satisfied the rule.
Make continues to think that a prog file is missing and thus
needs sot be updated; so "make prog" will always execute the
compiler.

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

The behavior of make, in the absence of a Makefile, is governed
by its default rules, that's all.

Those rules don't go away even if you do have a Makefile,
and Makefiles sometimes exploit that. There is a standard way to clear
the database, which is to declare an empty list of suffixes,
like this:

.SUFFIXES:

> Besides, there are issues here; make will not supply the -lm flag when
> it is needed for example.
>
> 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.)

Yes; with GNU Make, you need the -B option to unconditionally make
the targets.

> Or you need to compile first with -O0 and then when -O3.
>
> > 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?

You could use make to have a single rule such that when you type "make
prog", it builds it with all those commands, producing: prog-bcc,
prog-tcc, prog-gcc-O3, ... with timings.

That would not be a better solution compared to a simple script.

In GNU Make that could look like:

# template of rule for building with different compilers
# $(1) is the base name.

define rule_template
..PHONY $(1):

$(1):
bcc $(1); mv $(1) $(1).tcc
tcc $(1).c; mv $(1) $(1).tcc
gcc $(1).c -o $(1).gcc
gcc -O3 $(1).c -o $(1).gcc.03
endef

# For each goal specified on the command line, instantiate
# the above rule.

$(foreach target,$(MAKECMDGOALS),$(eval $(call rule_template,$(target))))

Run, showing it's working as far as dispatching the right recipe
commands:

$ make foo
bcc foo; mv foo foo.tcc
/bin/sh: 1: bcc: not found
mv: cannot stat 'foo': No such file or directory
Makefile:19: recipe for target 'foo' failed
make: *** [foo] Error 1
!2!
$ make bar
bcc bar; mv bar bar.tcc
/bin/sh: 1: bcc: not found
mv: cannot stat 'bar': No such file or directory
Makefile:19: recipe for target 'bar' failed
make: *** [bar] Error 1
!2!

That's pretty complicated compared to just a script that takes foo or bar as an
argument. So while make can help, it's not the best tool for this exact job.

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

On 2023-08-09, Bart <bc@freeuk.com> wrote:
> On 09/08/2023 11:36, Richard Harnden wrote:
>> On 09/08/2023 11:22, Bart wrote:
>>> So how does make help here?
>>>
>>>
>>
>> It just does it ...
>>
>> $ >test_c++.cpp
>> $ make test_c++
>> g++     test_c++.cpp   -o test_c++
>>
>> $ >test_c.c
>> $ make test_c
>> cc     test_c.c   -o test_c
>
> That doesn't address my points.
>
> Here file name are different. So:
>
> * What happens if there is both test.c and test.cpp?

One of the two will be found according to some search order.

If you don't like it, you just have to roll up your sleeves
and write some rules.

>
> * What happens if first you want compiler X for test.c and then you want
> compiler Y for test.c?

Either write rules, or do it externally:

make cc=X test; mv test test.X
make cc=Y test; mv test test.Y

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

On 2023-08-09, Bart <bc@freeuk.com> 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.
>
> The suggestion was that it addresses some of my concerns with running
> command-line compilers like gcc:
>
> * You have to supply the extension (I hate that)
>
> * 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).
>
> It's a nice demo, but it's not practical, because my requirements for
> simple cross-compiler builds are diverse.

That demo fits the use case of someone who has a foo.c file and
wants a ./foo runnable program.

The demo does that without any Makefile being required.

Make can do "anything", particularly GNU Make; but you have to
learn how to use it. For your use case, a script would be a lot easier.

If you care about saving keystrokes, why wouldn't you have a script with
a one-letter name like c (compile) where if you type c foo, it builds
foo.c with a dozen compilers and code generation combinations, times
everything, and saves the executables under different names?

You're moving the goalposts. "make foo" solves the "cc foo.c -o foo"
inconvenience, and that's it. It doesn't have to solve the problem
of compiling foo in a dozen ways; those are inconveniences you invented
yourself, best dealt with by a script.

Your use case has gone beyond the point where "tcc foo.c" producing
"foo" continues to be helpful, because the result is that all your
compiler commands are targetint the same name. And "tcc foo.c"
is longer than "c foo", the invocation of the script that will do
all that is necessary with multiple compilers.

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

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.
>
> > XML has some advantages over an ad-hoc line-based format. The parser
> > needs work as it's currently too basic. But XML should be familiar to
> > most programmers.
> That's not as much of an advantage as one might think. Programmers know
> the /syntax/ of XML, but every application of it uses a different schema.
> Since all of the elements and possible attributes need to be documented,
> one might as well (often) just document a simpler syntax.
>
I haven't integrated chat GTP into the resource compiler yet. So the script files
have to be in a rigid format rather than one designed primarily for the needs
of humans. And yes, you do need to document the XML elements.But it forces
everything into one consistent pattern.