On 10/01/2024 19:57, bart wrote:
> On 10/01/2024 15:51, David Brown wrote:
>> On 10/01/2024 15:31, bart wrote:
>
>> It is almost entirely useless, except for the very, very few people
>> who /need/ a C compiler that is very small.  In the days of 3.5"
>> floppy disks for rescue disks, it was useful.  In the days of 16 GB
>> USB flash devices costing pennies, it is irrelevant.
>
> 16 GB can hold a great deal of useful DATA: images, audio and video for
> example. It also tends to be consumed sequentially.

What the *beep* are you talking about? Does your compiler consist of 1
MB of program and 16 GB of video about how much better it is than
everything else?

The prime use of tcc, when it had a use, was for rescue disks and other
situations when you needed to boot from small mediums and have a running
system of some sort without installing on a hard disk. That was
originally a floppy, so tiny tools were vital. Then boot CDs became
popular - size was no longer an issue unless you wanted a mini CD. By
the time DVD's were common for the job, size of tools was irrelevant.

I've just checked my main IT supplier - the /cheapest/ USB stick they
have is 32 GB.

On 10/01/2024 19:24, bart wrote:
> On 10/01/2024 18:39, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>> [...]
>>>> Yet, the entire application can be built with
>>>> $ make
>>>
>>> I bet you can't. There's something missing. Unless the implicit file
>>> that make uses happens to be in that '$' directory. Usually you have
>>> to navigate to the project first.
>>
>> That '$' is a shell prompt, not a directory.
>>
>> Yes, you have to "cd" (like "chdir" on Windows) to the project directory
>> before typing "make".  You also have to make sure the computer is
>> powered on, login, launch a shell, and maybe one or two other things
>> before you get to that point.
>
> You're missing the point. SL is making a big deal about the fact that
> you can type 'make' without providing any apparent input. But that input
> is provided when you use 'cd' to get the relevant folder.
>
> Or do you think that the 'make' command provided will build that
> specific project irrespective of the CWD?

Let me put it another way; how does:

$ make

know it is to build that project, and not any other? The default input
is presumably "./makefile", with the key bit being that ".".

So, when claiming that you only need to type one thing to start the
process, it is disingenuous to leave out that part out.

After all, if you wanted to build project A, and, separately, project B,
you can't do both of them like this:

$ make
$ make

We've covered this before. While I quite like sensible defaults, where C
compilers tend to be sticklers for dotting all the Is, 'make' goes a
little too far the other way.

Before typing 'make', you'd better be sure you're in the right place!

bart <bc@freeuk.com> writes:
> On 10/01/2024 19:24, bart wrote:
>> On 10/01/2024 18:39, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>>> [...]
>>>>> Yet, the entire application can be built with
>>>>> $ make
>>>>
>>>> I bet you can't. There's something missing. Unless the implicit file
>>>> that make uses happens to be in that '$' directory. Usually you have
>>>> to navigate to the project first.
>>>
>>> That '$' is a shell prompt, not a directory.
>>>
>>> Yes, you have to "cd" (like "chdir" on Windows) to the project directory
>>> before typing "make".  You also have to make sure the computer is
>>> powered on, login, launch a shell, and maybe one or two other things
>>> before you get to that point.
>> You're missing the point. SL is making a big deal about the fact
>> that you can type 'make' without providing any apparent input. But
>> that input is provided when you use 'cd' to get the relevant folder.
>> Or do you think that the 'make' command provided will build that
>> specific project irrespective of the CWD?
>
> Let me put it another way; how does:
>
> $ make
>
> know it is to build that project, and not any other? The default input
> is presumably "./makefile", with the key bit being that ".".

Yes, you've correctly answered your own question.

(Note that I wrote "Makefile", not "makefile". Those are distinct file
names on some but not all systems. "make" happens to recognize both,
something I glossed over before. GNU "make" also recognizes
"GNUmakefile", which is rarely used and not generally recommended.)

> So, when claiming that you only need to type one thing to start the
> process, it is disingenuous to leave out that part out.
>
> After all, if you wanted to build project A, and, separately, project
> B, you can't do both of them like this:
>
> $ make
> $ make
>
> We've covered this before. While I quite like sensible defaults, where
> C compilers tend to be sticklers for dotting all the Is, 'make' goes a
> little too far the other way.
>
> Before typing 'make', you'd better be sure you're in the right place!

Again, I'm sure Scott felt, and I wholeheartedly agree, that this was so
obvious that it didn't need to be mentioned -- about as obvious as the
need to turn on the computer, make sure the project directory is
present, and so on.

You didn't find it obvious. That's ok.

You've now learned that "make" works in the current directory by
default, reading "makefile" or "Makefile" by default -- and you're
acting as if learning things is painful to you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 10/01/2024 19:55, David Brown wrote:
> On 10/01/2024 19:57, bart wrote:
>> On 10/01/2024 15:51, David Brown wrote:
>>> On 10/01/2024 15:31, bart wrote:
>>
>>> It is almost entirely useless, except for the very, very few people
>>> who /need/ a C compiler that is very small.  In the days of 3.5"
>>> floppy disks for rescue disks, it was useful.  In the days of 16 GB
>>> USB flash devices costing pennies, it is irrelevant.
>>
>> 16 GB can hold a great deal of useful DATA: images, audio and video
>> for example. It also tends to be consumed sequentially.
>
> What the *beep* are you talking about?  Does your compiler consist of 1
> MB of program and 16 GB of video about how much better it is than
> everything else?
>
> The prime use of tcc, when it had a use, was for rescue disks and other
> situations when you needed to boot from small mediums and have a running
> system of some sort without installing on a hard disk.  That was
> originally a floppy, so tiny tools were vital.  Then boot CDs became
> popular - size was no longer an issue unless you wanted a mini CD.  By
> the time DVD's were common for the job, size of tools was irrelevant.
>
> I've just checked my main IT supplier - the /cheapest/ USB stick they
> have is 32 GB.
>

I'm starting to wonder how dense you can be. But I know that's not the
the case; just unreceptive to certain concepts or unwilling to consider
them.

You are claiming that there is no point in limiting the size of code,
because after all you can buy 16GB or 32GB memory sticks.

So I'm not sure what your point is. Does the prevalence of very cheap
storage make it OK to have code that is 10, 100 or 1000 times bigger
than it need be?

Apparently so, according to you. Because of course there are no
consequences of that.

BTW these are some programs which are part of my gcc:

nasm.exe 1.4MB
ld.exe 1.5MB
as.exe 1.6MB

The first one, perhaps first two, will just fit onto one floppy, which I
think is 1.44MiB. The last is just over.

So three standalone programs that are still, in 2024, at floppy disk
scale. Why is that, given that you can buy 32,000MB storages devices for
'pennies'?

Note that I did not write these programs. I don't have a monopoly on
writing smallish, self-contained applications.

Will you also dismiss those apps for being too small to be of
consequence? Or will you admit that sometimes the scale of a task isn't
great enough to warrant a huge executable?

On 2024-01-10, bart <bc@freeuk.com> wrote:
> So, when claiming that you only need to type one thing to start the
> process, it is disingenuous to leave out that part out.

That's just knowing where the project is. That's something external to
the project; it's not a build secret hidden in the project itself, but
likely something the user themselves chose.

It's the same for any project, in any language using any build
procedure; they all have a location, and the first step is usually
changing to that location. Some users will cd to the project root even
before looking at any instructions.

(Perhaps the instructions will tell them smoething else, like
create a build directory somewhere, change to /that/ directory and
from the reference some build script in the unpacked tree.)

> Before typing 'make', you'd better be sure you're in the right place!

The instructions for that project can't even tell you what that is.

It's "wherever you unpacked/cloned the project".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/01/2024 21:43, Kaz Kylheku wrote:
> On 2024-01-10, bart <bc@freeuk.com> wrote:
>> So, when claiming that you only need to type one thing to start the
>> process, it is disingenuous to leave out that part out.
>
> That's just knowing where the project is. That's something external to
> the project; it's not a build secret hidden in the project itself, but
> likely something the user themselves chose.
>
> It's the same for any project, in any language using any build
> procedure; they all have a location, and the first step is usually
> changing to that location. Some users will cd to the project root even
> before looking at any instructions.
>
> (Perhaps the instructions will tell them smoething else, like
> create a build directory somewhere, change to /that/ directory and
> from the reference some build script in the unpacked tree.)
>
>> Before typing 'make', you'd better be sure you're in the right place!
>
> The instructions for that project can't even tell you what that is.
>
> It's "wherever you unpacked/cloned the project".
>

I once claimed that with the build schemes I prefer, you usually have to
type only two things:

mm prog # my language

mcc @prog # C; also works across compilers

bcc -auto prog # my older compiler for projects written
# to certain rules

But 'make' was claimed to be superior because you only had to type one
thing:

make

Never mind that 'makefile' might contains 100s or even 1000s of lines in
cryptic syntax that you have to write first, while, in my first example,
no such file is needed. And in the second, it is a mere list of source
files.

At least with my schemes, I can do:

mm prog1
mm prog2
mm \loc\prog3

All from the same place. Also, if you are in the wrong location, it will
likely pick up the error, as there will be no 'prog1'. With make, it'll
spend the next 30 minutes building the wrong project!

(On one project that came up a few months ago, there were two makefiles,
one inside a nested folder. But github or something only showed the the
nested folder, or something like that.

It caused confusion, and made things go badly wrong, things that would
have been picked up if 'make' needed the name of an input, as you surely
wouldn't have used the same name for both.

This seems common in Unix: let's call every input file 'makefile', and
every output file 'a.out'!)

On 1/10/24 19:57, bart wrote:

> The above tries to compile hello.c with gcc. The first attempt doesn't
> work. The second does, as no error is displayed. But what exactly has it
> compiled it to? As there is no file called 'hello.exe.

o ____ _____ _____ __ __
o | _ \ |_ _| | ___| | \/ |
o | |_) | | | | |_ | |\/| |
o | _ < | | | _| | | | |
o |_| \_\ |_| |_| |_| |_|
o

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

On 10/01/2024 23:30, tTh wrote:
> On 1/10/24 19:57, bart wrote:
>
>> The above tries to compile hello.c with gcc. The first attempt doesn't
>> work. The second does, as no error is displayed. But what exactly has
>> it compiled it to? As there is no file called 'hello.exe.
>
>   o     ____    _____   _____   __  __
>   o    |  _ \  |_   _| |  ___| |  \/  |
>   o    | |_) |   | |   | |_    | |\/| |
>   o    |  _ <    | |   |  _|   | |  | |
>   o    |_| \_\   |_|   |_|     |_|  |_|
>   o
>

I see. It doesn't matter how complex, unfriendly, inconvenient or
error-prone using a piece of software is, it's all fine so long as you
tell the user:

R T F M?

That makes up for designing it properly?

Instead of getting rid of unnecessary hoops you have to jump through,
you'd just write a thicker instruction manual and sell more training
courses. (And force people to use 'make' - another dozen hoops.)

Plus of course you can command more pay for mastering that contrived
complexity.

What /I/ do is strive to get rid of those hoops.

On 2024-01-10, bart <bc@freeuk.com> wrote:
> This is what I mean by user-friendly:
>
> c:\c>gcc hello
> C:\tdm\bin\ld.exe: cannot find hello: No such file or directory
> collect2.exe: error: ld returned 1 exit status
>
> c:\c>gcc hello.c
>
> c:\c>hello
> 'hello' is not recognized as an internal or external command,
> operable program or batch file.
>
> c:\c>gcc hello.c -hello
> gcc: error: unrecognized command-line option '-h'
>
> c:\c>gcc hello.c -ohello

It's been explained already that the Unix people had the same idea
that there should be a "<command> hello" which infers that a hello
program can be made from a hello.c (or updated, if it is older).

They designed a separate program called make for doing this kind of
inference, and made it a language where you can program your own rules.

Having put that prerequisite-inferencing behavior into make, they
weren't about to replicate that job into other tools, like cc.
That goes against their one-job-one-tool principle.

GCC comes from the GNU project, which decided to clone the Unix user
space. Thus, the GNU project provides a make program. If you have the
GNU system installed all together, as it is intended to be, you should
be able to type "make hello".

If you have only "gcc" but no "make", you've not installed all the
GNU development stuff.

(I'm of the opinion that a tool which infers prerequisite files from
targets, and the necessary build commands, is better than repeating that
logic in the implementation of every compiler-like tool.)

Fledgling compiler projects which are not part of a Unix replacement
project do not bundle a make tool. So it makes sense that they try
to wedge some of those behaviors and use cases into their compiler
driver program.

> Please don't talk to me about user-friendly, you don't seem to have a clue.

You don't seem to get that nothing in this area qualifies as being even
remotely "user-friendly".

For starters, none of it is even user-facing.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/10/2024 5:36 PM, bart wrote:
> On 10/01/2024 21:43, Kaz Kylheku wrote:
>> On 2024-01-10, bart <bc@freeuk.com> wrote:
>>> So, when claiming that you only need to type one thing to start the
>>> process, it is disingenuous to leave out that part out.
>>
>> That's just knowing where the project is. That's something external to
>> the project; it's not a build secret hidden in the project itself, but
>> likely something the user themselves chose.
>>
>> It's the same for any project, in any language using any build
>> procedure; they all have a location, and the first step is usually
>> changing to that location. Some users will cd to the project root even
>> before looking at any instructions.
>>
>> (Perhaps the instructions will tell them smoething else, like
>> create a build directory somewhere, change to /that/ directory and
>> from the reference some build script in the unpacked tree.)
>>
>>> Before typing 'make', you'd better be sure you're in the right place!
>>
>> The instructions for that project can't even tell you what that is.
>>
>> It's "wherever you unpacked/cloned the project".
>>
>
> I once claimed that with the build schemes I prefer, you usually have to type only two things:
>
>     mm prog                 # my language
>
>     mcc @prog               # C; also works across compilers
>
>     bcc -auto prog          # my older compiler for projects written
>                             # to certain rules
>
> But 'make' was claimed to be superior because you only had to type one thing:
>
>     make

As hobby programmers, we were taught the first thing you typed was:

make -n

as this would be a simulation, and it would give you some idea what
would happen next. If someone had made an "a.out" mistake, for the
very simplest cases, you could spot it.

However, modern packaging techniques, "make" is seldom ready to run.

I do have one package on disk here, which is from the old days.
And is suited to showing what make used to work like.

/mnt/d/xv-3.10a$ make -n
echo ""
echo " Did you remember to 'make depend' first?"
echo ""
echo " building xv ..."
echo ""
make: *** No rule to make target '/usr/include/X11/Xos.h', needed by 'xv.o'. Stop.

/mnt/d/xv-3.10a$ make -n depend
makedepend -- -I/usr/local/include -I/usr/local -Dusl -DUSL -DSVR4 -Di386
-DWINTIF -DSCHEMES_95 -DNARROWPROTO -DSVR4 -DDOJPEG -DDOTIFF -DDOPDS
-- xv.c xvevent.c xvroot.c xvmisc.c xvimage.c xvcolor.c xvsmooth.c
xv24to8.c xvgif.c xvpm.c xvinfo.c xvctrl.c xvscrl.c xvalg.c xvgifwr.c
xvdir.c xvbutt.c xvpbm.c xvxbm.c xvgam.c xvbmp.c xvdial.c xvgraf.c
xvsunras.c xvjpeg.c xvps.c xvpopup.c xvdflt.c xvtiff.c xvtiffwr.c xvpds.c
xvrle.c xviris.c xvgrab.c vprintf.c xvbrowse.c xvtext.c xvpcx.c xviff.c
xvtarga.c xvxpm.c xvcut.c xvxwd.c xvfits.c bggen.c vdcomp.c xcmap.c

After some more fiddling, and the make depend has run, now we try make -n again.

/mnt/d/xv-3.10a$ make -n
echo ""
echo " Did you remember to 'make depend' first?"
echo ""
echo " building xv ..."
echo ""
cc -O -Xa -Dasm=__asm -DANSICPP -I/usr/local/include -I/usr/local -Dusl -DUSL -DSVR4 -Di386 -DWINTIF -DSCHEMES_95 -DNARROWPROTO -DSVR4 -DDOJPEG -DDOTIFF -DDOPDS -c -o xv.o xv.c
.... lines deleted
cc -O -Xa -Dasm=__asm -DANSICPP -I/usr/local/include -I/usr/local -Dusl -DUSL -DSVR4 -Di386 -DWINTIF -DSCHEMES_95 -DNARROWPROTO -DSVR4 -DDOJPEG -DDOTIFF -DDOPDS -c -o xvfits.o xvfits.c
rm -f xv
cc -o xv -O -Xa -Dasm=__asm -DANSICPP xv.o xvevent.o xvroot.o xvmisc.o xvimage.o xvcolor.o xvsmooth.o xv24to8.o xvgif.o xvpm.o xvinfo.o xvctrl.o xvscrl.o xvalg.o xvgifwr.o xvdir.o xvbutt.o xvpbm.o xvxbm.o xvgam.o xvbmp.o xvdial.o xvgraf.o xvsunras.o xvjpeg.o xvps.o xvpopup.o xvdflt.o xvtiff.o xvtiffwr.o xvpds.o xvrle.o xviris.o xvgrab.o vprintf.o xvbrowse.o xvtext.o xvpcx.o xviff.o xvtarga.o xvxpm.o xvcut.o xvxwd.o xvfits.o -lXext -lX11 -L/usr/local/lib -ljpeg -L/usr/local/lib -ltiff -lm -lsocket -lnsl -lgen
cc -O -Xa -Dasm=__asm -DANSICPP -I/usr/local/include -I/usr/local -Dusl -DUSL -DSVR4 -Di386 -DWINTIF -DSCHEMES_95 -DNARROWPROTO -DSVR4 -DDOJPEG -DDOTIFF -DDOPDS -c -o bggen.o bggen.c
rm -f bggen
cc -o bggen -O -Xa -Dasm=__asm -DANSICPP bggen.o -lXext -lX11 -L/usr/local/lib -ljpeg -L/usr/local/lib -ltiff -lm -lsocket -lnsl -lgen
cc -O -Xa -Dasm=__asm -DANSICPP -I/usr/local/include -I/usr/local -Dusl -DUSL -DSVR4 -Di386 -DWINTIF -DSCHEMES_95 -DNARROWPROTO -DSVR4 -DDOJPEG -DDOTIFF -DDOPDS -c -o vdcomp.o vdcomp.c
rm -f vdcomp
cc -o vdcomp -O -Xa -Dasm=__asm -DANSICPP vdcomp.o -lXext -lX11 -L/usr/local/lib -ljpeg -L/usr/local/lib -ltiff -lm -lsocket -lnsl -lgen
cc -O -Xa -Dasm=__asm -DANSICPP -I/usr/local/include -I/usr/local -Dusl -DUSL -DSVR4 -Di386 -DWINTIF -DSCHEMES_95 -DNARROWPROTO -DSVR4 -DDOJPEG -DDOTIFF -DDOPDS -c -o xcmap.o xcmap.c
rm -f xcmap
cc -o xcmap -O -Xa -Dasm=__asm -DANSICPP xcmap.o -lXext -lX11 -L/usr/local/lib -ljpeg -L/usr/local/lib -ltiff -lm -lsocket -lnsl -lgen
cc -O -Xa -Dasm=__asm -DANSICPP -I/usr/local/include -I/usr/local -Dusl -DUSL -DSVR4 -Di386 -DWINTIF -DSCHEMES_95 -DNARROWPROTO -DSVR4 -DDOJPEG -DDOTIFF -DDOPDS -c -o xvpictoppm.o xvpictoppm.c
rm -f xvpictoppm
cc -o xvpictoppm -O -Xa -Dasm=__asm -DANSICPP xvpictoppm.o -lXext -lX11 -L/usr/local/lib -ljpeg -L/usr/local/lib -ltiff -lm -lsocket -lnsl -lgen

You may be able to tell from that, what the output executables
will be, if the make finishes. That is an old package, which
someone restored (like putting a coat of wax on a Bentley).

Soon, we won't be able to run that any more, when Wayland is all we've got,
and they quickly torch and set fire to XWayland.

Paul

On 2024-01-10, bart <bc@freeuk.com> wrote:
> On 10/01/2024 21:43, Kaz Kylheku wrote:
>> On 2024-01-10, bart <bc@freeuk.com> wrote:
>>> So, when claiming that you only need to type one thing to start the
>>> process, it is disingenuous to leave out that part out.
>>
>> That's just knowing where the project is. That's something external to
>> the project; it's not a build secret hidden in the project itself, but
>> likely something the user themselves chose.
>>
>> It's the same for any project, in any language using any build
>> procedure; they all have a location, and the first step is usually
>> changing to that location. Some users will cd to the project root even
>> before looking at any instructions.
>>
>> (Perhaps the instructions will tell them smoething else, like
>> create a build directory somewhere, change to /that/ directory and
>> from the reference some build script in the unpacked tree.)
>>
>>> Before typing 'make', you'd better be sure you're in the right place!
>>
>> The instructions for that project can't even tell you what that is.
>>
>> It's "wherever you unpacked/cloned the project".
>>
>
> I once claimed that with the build schemes I prefer, you usually have to
> type only two things:
>
> mm prog # my language

You mean: "cd /path/to/proj/project; mm prog", right?

Would you say that the instructions for a microwave oven are
"disingenuous" because they say things like type [1][5][Start]
to cook something for 15 seconds, without telling you that you
must first walk to the kitchen, and you must be doing this to that
specific microwave oven's keypad, and not some unrelated remote
control?

> mcc @prog # C; also works across compilers
>
> bcc -auto prog # my older compiler for projects written
> # to certain rules
>
> But 'make' was claimed to be superior because you only had to type one
> thing:
>
> make
>
> Never mind that 'makefile' might contains 100s or even 1000s of lines in

There doesn't have to be a makefile. In a directory where there is
nothing but prog.c, "make prog" will run "cc prog.c -o prog".
>
> It caused confusion, and made things go badly wrong, things that would
> have been picked up if 'make' needed the name of an input, as you surely
> wouldn't have used the same name for both.

But in "mm prog1", "prog1" isn't the name of an input; it's an output.

> This seems common in Unix: let's call every input file 'makefile', and
> every output file 'a.out'!)

The fixed name of the makefile is a great idea. If I could change
anything, I would call it ".makefile".

A filesystem directory is an object. It has properties, like
modification time and permissions. It's also a dictionary of
entries; those entries are its properties.

The "Makefile" property of a directory gives the build rules for
the project files in that directory.

That's the right way to think about it: the rules belong to a directory
and so are associated with it by a fixed property name.

If directory properties are expressed as directory entries, it's nice
if those entries use dotted names (in my opinion).

Make programs have a -f option to pick a different name other than
makefile, Makefile or the others that they search for by default.

Make programs also have a -C option to use another directory:

make -C /path/to/project

this means "change to /path/to/projects" and make the default
target there. (According to the rules associated with that directory,
which are in "makefile", or "Makefile", or else some other names
recognized by that make implementation.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/10/2024 2:10 AM, David Brown wrote:
> On 10/01/2024 08:40, Chris M. Thomasson wrote:
>> On 1/9/2024 9:28 PM, Kaz Kylheku wrote:
>>> On 2024-01-10, tTh <tth@none.invalid> wrote:
>>>> On 1/10/24 01:40, Bart wrote:
>>>>> An easy compiler is one where you just do:
>>>>>
>>>>>      gcc prog
>>>>>
>>>>> and not, at the very least:
>>>>>
>>>>>      gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>>>
>>>>> Meanwhile I routinely test C programs on half a dozen compilers. I
>>>>> can't
>>>>> be bothered with all this crap.
>>>>
>>>>      So do as all of us do : put this crap in a Makefile or
>>>>      a shell script, and forget about it.
>>>
>>> Please don't get Bart started on makefiles!
>>>
>>
>> Don't get me started about freaking out for some minutes when I failed
>> to use a god damn tab! My makefile would not work. God damn it! Ahhhh,
>> that was around 20 years ago.
>
> The author of "make" described the distinction between tabs and spaces
> to be his worst mistake ever - but use of the tool took off too quickly
> for him to change it.

Well, shit happens! lol. Jesting here. ;^)

> The difference between Bart and everyone else is that when other people
> make a tab mistake, they learn from it - and even 20 years on, you still
> remember.

Oh my I sure do remember it, David! It managed to ingrain itself firmly
into my mind. I was getting a bit pissed saying why the f**k wont this
god damn makefile work!!!! GRRRRRR! I can remember it clearly. Fwiw, I
just got dropped off at my house from a party, and decided to create a
program that generated some makefiles for my AppCore project at the
time, don't ask why. I might of been a bit boooozzyy. Yikes!

> Bart seems to forget things seconds after someone tells him
> how to use any program that he has not written himself.  (It takes him a
> little longer to forget how his own programs and languages work.)
>

No shit? Bard helped me with some of my C code before. He is a nice guy.

:^)

On 1/10/2024 7:10 PM, Chris M. Thomasson wrote:
> On 1/10/2024 2:10 AM, David Brown wrote:
[...]
>> Bart seems to forget things seconds after someone tells him how to use
>> any program that he has not written himself.  (It takes him a little
>> longer to forget how his own programs and languages work.)
>>
>
> No shit? Bard helped me with some of my C code before. He is a nice guy.

Oops! I meant Bart not Bard. Sorry everybody! ;^o Damn typos (tabs),
lol! ;^o

>
> :^)

On 1/10/2024 11:55 AM, David Brown wrote:
> On 10/01/2024 19:57, bart wrote:
>> On 10/01/2024 15:51, David Brown wrote:
>>> On 10/01/2024 15:31, bart wrote:
>>
>>> It is almost entirely useless, except for the very, very few people
>>> who /need/ a C compiler that is very small.  In the days of 3.5"
>>> floppy disks for rescue disks, it was useful.  In the days of 16 GB
>>> USB flash devices costing pennies, it is irrelevant.
>>
>> 16 GB can hold a great deal of useful DATA: images, audio and video
>> for example. It also tends to be consumed sequentially.
>
> What the *beep* are you talking about?  Does your compiler consist of 1
> MB of program and 16 GB of video about how much better it is than
> everything else?
>
> The prime use of tcc, when it had a use, was for rescue disks and other
> situations when you needed to boot from small mediums and have a running
> system of some sort without installing on a hard disk.  That was
> originally a floppy, so tiny tools were vital.  Then boot CDs became
> popular - size was no longer an issue unless you wanted a mini CD.  By
> the time DVD's were common for the job, size of tools was irrelevant.

Comic relief: That interesting game Phantasmagoria had seven CD's. ;^)

>
> I've just checked my main IT supplier - the /cheapest/ USB stick they
> have is 32 GB.
>

On 1/10/2024 5:14 PM, bart wrote:
> On 10/01/2024 23:30, tTh wrote:
>> On 1/10/24 19:57, bart wrote:
>>
>>> The above tries to compile hello.c with gcc. The first attempt
>>> doesn't work. The second does, as no error is displayed. But what
>>> exactly has it compiled it to? As there is no file called 'hello.exe.
>>
>>    o     ____    _____   _____   __  __
>>    o    |  _ \  |_   _| |  ___| |  \/  |
>>    o    | |_) |   | |   | |_    | |\/| |
>>    o    |  _ <    | |   |  _|   | |  | |
>>    o    |_| \_\   |_|   |_|     |_|  |_|
>>    o
>>
>
> I see. It doesn't matter how complex, unfriendly, inconvenient or
> error-prone using a piece of software is, it's all fine so long as you
> tell the user:
>
>   R T F M?
>
> That makes up for designing it properly?
>
> Instead of getting rid of unnecessary hoops you have to jump through,
> you'd just write a thicker instruction manual and sell more training
> courses. (And force people to use 'make' - another dozen hoops.)

Did you ever buy any Invisiclue booklets? Infocom games?

>
> Plus of course you can command more pay for mastering that contrived
> complexity.
>
> What /I/ do is strive to get rid of those hoops.
>
>
>
>
>
>

On 1/10/2024 11:16 AM, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 10/01/2024 14:51, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> My original implementation for Windows used these two files only:
>>>>
>>>> bcc.exe (about 1MB)
>>>
>>>
>>> Why do you think anyone here cares?
>>
>> Why do you think anyone cares about your makefiles?
>
> What makes you think I care if anyone cares about my makefiles?
>

No shit. ;^o

On 1/9/2024 2:37 PM, James Kuyper wrote:
> Bart <bc@freeuk.cm> writes:
>> On 09/01/2024 21:15, Keith Thompson wrote:
>>> Bart <bc@freeuk.cm> writes:
>>> [...]
>>>> I did then try to fix that, but stopped because of interactions with
>>>> actual zero-length arrays (I would need to be fully immersed to make
>>>> the changes).
>>>>
>>>> Then the next day I found that C doesn't even /have/ zero-length
>>>> arrays: you can't have an empty array; how about that? I thought C
>>>> was zero-based!
>>> [...]
>>> Have you considered learning the language before trying to implement
>>> it?
>>
>> Which version of C do you suggest; the one where:
>>
>> #include <stdio.h>
>>
>> int main(void) {
>> int A[0];
>> int B[]={};
>>
>> printf("%zu\n", sizeof(A));
>> printf("%zu\n", sizeof(B));
>> }
>>
>> compiles fine with tcc, gcc and clang, and displays 0 for the sizes?
>>
>> Or the one where those produce warnings? Or the one where it actually fails?
>>
>> So, if C doesn't have zero-length arrays, why don't I get a fatal error?
>
> 2 Reasons.
> First of all, the only thing that the C standard requires for such code
> is a diagnostic message. It doesn't require that the code compile, and
> it also doesn't require that it not compile. If an implementation
> chooses to create an executable from such code, and if you choose to
> execute it, the standard imposes no requirements on what behavior will
> occur when you do so.

Spooky! Yikes!

>
> The fact that you didn't get the required diagnostic message is because
> none of those programs conforms to any version of the C standard in it's
> default mode. Since you've made it clear that putting them into
> conforming mode is too complicated for you to understand, you're stuck
> with non-conforming behavior. You could, with equal (lack of)
> justification, use a fortran compiler, which also fails to conform to
> the C standard.

On 1/10/2024 10:13 AM, bart wrote:
> On 10/01/2024 14:49, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 10/01/2024 03:14, Bart wrote:
>>>> On 10/01/2024 02:00, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.cm> writes:
>>>>>> On 10/01/2024 00:05, Keith Thompson wrote:
>>>>>>> Bart <bc@freeuk.cm> writes:
>>>>>
>>>>>> An easy compiler is one where you just do:
>>>>>>
>>>>>>      gcc prog
>>>>>>
>>>>>> and not, at the very least:
>>>>>>
>>>>>>      gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>>>
>>>>>
>>>>> $ functions c
>>>>> function c
>>>>> {
>>>>>     gcc -o "$1" -std=c11 -pedantic-errors "$1".c
>>>>> }
>>>>> $ cat a.c
>>>>> #include <stdio.h>
>>>>>
>>>>> int
>>>>> main(int argc, const char **argv, const char **envp)
>>>>> {
>>>>>
>>>>>       printf("Hello World\n");
>>>>>
>>>>>       return 0;
>>>>> }
>>>>> $ c a
>>>>> $ ./a
>>>>> Hello World
>>>>>
>>>>> Can't get any more concise than that.
>>>>
>>>> Great. Now tell the gcc people that's what it should do ANYWAY.
>>>
>>> But it is /not/ what gcc should do.
>>>
>>> You seem to be mixing up "what Bart wants" with "what countless other
>>> people want".  Write your own tools to revolve around your own selfish
>>> needs if that's your preference, but don't expect everyone else to
>>> change their worlds to suit /you/.
>>>
>>>
>>> Scott wrote that as an example that might suit you.
>>
>>> I am confident that
>>> the compiler options he mostly uses are different from that - and that
>>> he uses a variety of different options and different times, and that
>>> they are different from the options /I/ use or anyone else uses.
>>
>> Indeed.  I use a Makefile and the Makefile.defs include alone has 373
>> lines - something sure to piss Bart off.   Of course, the project
>> has:
>>
>> SLOC    Directory       SLOC-by-Language (Sorted)
>> 7316068 include         ansic=7274603,cpp=41465
>> 899374  tests
>> python=763294,ansic=82789,asm=34873,cpp=18013,sh=405
>> 885492  io              cpp=603113,ansic=281285,python=466,sh=324,asm=304
>> 133342  processor       cpp=131855,python=1487
>> 133153  3rd_party       cpp=133033,sh=78,python=42
>> 26803   tools
>> python=17834,cpp=4300,sh=1903,ansic=1459,perl=1199,
>>                          ruby=108
>> 16754   gen             ansic=16754
>> 10955   platform        cpp=10955
>> 8392    common          cpp=8392
>> 5290    bin             cpp=5118,python=172
>> 2204    cpc             cpp=2204
>> 1883    top_dir         cpp=1883
>> 1430    noc             cpp=1430
>> 560     shim            cpp=560
>>
>> SLOC doesn't include whitespace or comments.
>>
>> That's about 10 million lines of code across several hundred source
>> and include files.
>>
>> Yet, the entire application can be built with
>>
>> $ make
>
> I bet you can't.

Hummm... Are you sure about that?

> There's something missing. Unless the implicit file
> that make uses happens to be in that '$' directory. Usually you have to
> navigate to the project first.
>
> So of the two parts a typical build needs: the program, script or
> process that is launched to do the work, and the input needed, one has
> already been provided.
>
> A more sensible way would be to require:
>
>    make inputfile
>
> Then you could build stuff from anywhere.
>
> BTW well done for discovering that, if a build sequence requires
> multiple commands to be executed, you can put those into a 'script' that
> requires a single invocation.
>
> Just as long as you realise that this isn't doing away with those
> multiple steps, it's hiding them away not simplifying, and adding ONE
> MORE step to the process.
>
> The stuff I do is genuine simplification.
>

On 10/01/2024 21:49, bart wrote:
> On 10/01/2024 19:55, David Brown wrote:
>> On 10/01/2024 19:57, bart wrote:
>>> On 10/01/2024 15:51, David Brown wrote:
>>>> On 10/01/2024 15:31, bart wrote:
>>>
>>>> It is almost entirely useless, except for the very, very few people
>>>> who /need/ a C compiler that is very small.  In the days of 3.5"
>>>> floppy disks for rescue disks, it was useful.  In the days of 16 GB
>>>> USB flash devices costing pennies, it is irrelevant.
>>>
>>> 16 GB can hold a great deal of useful DATA: images, audio and video
>>> for example. It also tends to be consumed sequentially.
>>
>> What the *beep* are you talking about?  Does your compiler consist of
>> 1 MB of program and 16 GB of video about how much better it is than
>> everything else?
>>
>> The prime use of tcc, when it had a use, was for rescue disks and
>> other situations when you needed to boot from small mediums and have a
>> running system of some sort without installing on a hard disk.  That
>> was originally a floppy, so tiny tools were vital.  Then boot CDs
>> became popular - size was no longer an issue unless you wanted a mini
>> CD.  By the time DVD's were common for the job, size of tools was
>> irrelevant.
>>
>> I've just checked my main IT supplier - the /cheapest/ USB stick they
>> have is 32 GB.
>>
>
> I'm starting to wonder how dense you can be. But I know that's not the
> the case; just unreceptive to certain concepts or unwilling to consider
> them.
>
> You are claiming that there is no point in limiting the size of code,
> because after all you can buy 16GB or 32GB memory sticks.

I am claiming that the size of a compiler is rarely of any relevance.
The point of tcc being small was for situations where you might need a C
compiler, but have very little space - primarily for *nix rescue disks
or bootup systems. This is no longer a relevant use-case.

There are almost no circumstances where you would need a C
implementation, where you could use a C implementation that took 1 MB of
space on a disk, and where you could not equally well use a C
implementation that took 1 GB of space on the disk.

Can you describe even a single situation where the 1 MB toolchain would
work and the 1 GB would not? I don't care about which you /prefer/, or
how long it would take to download or install, or how long it takes to
run, or the flags it has, or how easy it is to use, or whether you think
the extra space or features are unnecessary. Describe to me the
circumstances for which a 1 MB tcc toolchain would work but a 1 GB gcc
toolchain would not.

Imagine someone wrote a program called "tcc" that accepted the same
command line flags and options as the tcc compiler, then called gcc with
appropriate flags and options so that gcc matched exactly in terms of
the code it accepted and rejected, and how it treated the code. Under
what circumstances would that "fake" tcc be unusable while "real" tcc
works fine?

>
> So I'm not sure what your point is. Does the prevalence of very cheap
> storage make it OK to have code that is 10, 100 or 1000 times bigger
> than it need be?

On what basis do you claim gcc (or some other tool) is orders of
magnitude bigger than it needs to be?

Let's take a real example. I have an installation of a complete
gcc-based toolchain for 32-bit ARM, hosted on 64-bit Linux. I have many
such installations, but we'll pick one - release
gcc-arm-none-eabi-10-2020-q4-major. (You can download it yourself for
Windows hosting if you like.) The download was about 150 Mb, unpacked
it is 725 MB on my disk.

Of those 725 Mb, 68 Mb is documentation - because for /real/ tools,
documentation is important. And for /real/ tools, user convenience is
vastly more important than disk space, so the documentation is in
several different formats, letting users choose what they prefer.

In the "bin" directory, there is about 60 MB of programs - there is not
just a compiler, but there are many programs that are useful to at least
some toolchain users. As well as the main C compiler, there is an
assembler, linker, C++ compiler, stand-alone C preprocessor, debugger,
profiler, code coverage tools, object code analysis and dump tools, and
many others. No single user will use all of them, but each tool will be
helpful to someone.

Then there are some 150 MB of libraries and sub-programs for the
compiler - the actual C compiler is about 25 MB. (C++ and LTO are other
25 MB each.) That's vastly bigger than tcc - but gcc is a vastly more
powerful compiler and does vastly more. Again, no one user uses all the
features, but pretty much every feature is used by someone. Also in
this directory is the "compiler support" libraries for the targets -
software floating point, startup code, C++ runtime support, in multiple
versions for some 20+ different 32-bit ARM architectures. That's
another 50 MB.

There's 20 MB of header files (by far the biggest bulk is from C++), and
then about 430 MB of library files - again for countless versions and
variants of ARM devices, for C and C++, for big full-featured libraries
and small, space-saving libraries, for debug libraries, for different
ABI versions, and so on.

That breakdown should give you some idea of the space used - the space
/needed/ - be real toolchains. You seem to imagine that the gcc
developers are merely incompetent and write 1000 times too many lines of
code.

You fail to realise that you write your little tools for one person on
one target, to work with source code written by one person for one kind
of application, with no idea or concern about code optimisation, safety,
quality control, testing, differing user experience and needs,
debugging, user choices. Of course your little tools are tiny compared
to real-world tools. (tcc /was/ written to be used by other people -
but it was intentionally designed to be limited and inflexible so that
it could be as small as possible.)

Now, I'm sure a toolchain could be made with equal features to gcc and a
quarter of the size. But doing so would be far more work - there is no
point in finding some smart way to optimise the target libraries when
disk space is free. As a user, I'd much rather the developers spent
their time on something more useful than saving me a couple of pence
worth of disk space.

>
> Apparently so, according to you. Because of course there are no
> consequences of that.

No, there are no /significant/ consequences. So it doesn't matter.

>
> BTW these are some programs which are part of my gcc:
>
>    nasm.exe   1.4MB
>    ld.exe     1.5MB
>    as.exe     1.6MB
>
> The first one, perhaps first two, will just fit onto one floppy, which I
> think is 1.44MiB. The last is just over.
>
> So three standalone programs that are still, in 2024, at floppy disk
> scale. Why is that, given that you can buy 32,000MB storages devices for
> 'pennies'?

Do you imagine the developers took the size of a floppy into account
when they made these programs? Is that what you are trying to suggest?
These are small, in comparison to a C compiler, because they are simple,
in comparison to a C compiler.

>
> Note that I did not write these programs. I don't have a monopoly on
> writing smallish, self-contained applications.
>
> Will you also dismiss those apps for being too small to be of
> consequence? Or will you admit that sometimes the scale of a task isn't
> great enough to warrant a huge executable?
>

WTF are you on about? Sometimes you spout the most incredible rubbish.
In what twisted fantasy world does "I don't care if a useful
feature-filled program takes a lot of disk space" imply "Small programs
are irrelevant" ?

On 11/01/2024 04:10, Chris M. Thomasson wrote:
> On 1/10/2024 2:10 AM, David Brown wrote:
>> On 10/01/2024 08:40, Chris M. Thomasson wrote:
>>> On 1/9/2024 9:28 PM, Kaz Kylheku wrote:
>>>> On 2024-01-10, tTh <tth@none.invalid> wrote:
>>>>> On 1/10/24 01:40, Bart wrote:
>>>>>> An easy compiler is one where you just do:
>>>>>>
>>>>>>      gcc prog
>>>>>>
>>>>>> and not, at the very least:
>>>>>>
>>>>>>      gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>>>>
>>>>>> Meanwhile I routinely test C programs on half a dozen compilers. I
>>>>>> can't
>>>>>> be bothered with all this crap.
>>>>>
>>>>>      So do as all of us do : put this crap in a Makefile or
>>>>>      a shell script, and forget about it.
>>>>
>>>> Please don't get Bart started on makefiles!
>>>>
>>>
>>> Don't get me started about freaking out for some minutes when I
>>> failed to use a god damn tab! My makefile would not work. God damn
>>> it! Ahhhh, that was around 20 years ago.
>>
>> The author of "make" described the distinction between tabs and spaces
>> to be his worst mistake ever - but use of the tool took off too
>> quickly for him to change it.
>
> Well, shit happens! lol. Jesting here. ;^)
>
>
>> The difference between Bart and everyone else is that when other
>> people make a tab mistake, they learn from it - and even 20 years on,
>> you still remember.
>
> Oh my I sure do remember it, David! It managed to ingrain itself firmly
> into my mind. I was getting a bit pissed saying why the f**k wont this
> god damn makefile work!!!! GRRRRRR! I can remember it clearly. Fwiw, I
> just got dropped off at my house from a party, and decided to create a
> program that generated some makefiles for my AppCore project at the
> time, don't ask why. I might of been a bit boooozzyy. Yikes!
>
>
>> Bart seems to forget things seconds after someone tells him how to use
>> any program that he has not written himself.  (It takes him a little
>> longer to forget how his own programs and languages work.)
>>
>
> No shit? Bard helped me with some of my C code before. He is a nice guy.
>

I'm sure Bart /is/ a nice guy. And he is a smart guy. But he has some
deep-rooted and obsessive hatreds and prejudices that have blocked all
sense of logic, rationality or factual considerations in regard to some
topics. His fanaticism against C, gcc, development tools and *nix make
him blind, incapable of understanding other posts, information and
opinions, and unable to think straight or make a coherent argument. He
sees everything on these topics as black or white, for him or against
him, and warps everything other people say to fit that mould.

As long as none of his triggers are activated, we get along fine. I'm
sure if I met him in person, we could spent a pleasant time together
discussing the pros and cons of different 80's and 90's home computers,
why the modern Doctor Who will never live up to the originals, how
pointless and overly commercial football has become, and lots of other
topics. We could probably even chat about politics and religion without
conflict. I'd /like/ to be able to talk to him in a comfortable and
friendly manner about C, development tools, OS's, and the rest, but I
fear it is not likely to happen.

On 11/01/2024 02:46, Kaz Kylheku wrote:
> On 2024-01-10, bart <bc@freeuk.com> wrote:

>> I once claimed that with the build schemes I prefer, you usually have to
>> type only two things:
>>
>> mm prog # my language
>
> You mean: "cd /path/to/proj/project; mm prog", right?

Well, it could be done as:

mm <proglocation>

Which in my typical projects, might mean typing:

mm \cx\cc

This creates \cx\cc.exe, a new version of my C compiler. You can argue
whether path and file components of a filespec counts as one thing or two.

Here, I should point out that what I am talking about with build systems
is the means to create ONE new executable file (.exe or .dll, or .so
and, um, just "." I guess on Linux!).

While 'make' conflates several kinds of processes:

* Building individual binaries
* Building multiple binaries
* Installing applications
* Etc

It is in building individual binaries many compilers or languages are
weak on. Most open source projects I want to build, that are guarded by
'make', have only a single output file.

Getting back to the example above, creating a new production version of
my C compiler, requires an additional step: replacing the production
'mcc.exe' compiler with the new 'cc.exe'.

It's done with a 2-line batch file.

>> But 'make' was claimed to be superior because you only had to type one
>> thing:
>>
>> make
>>
>> Never mind that 'makefile' might contains 100s or even 1000s of lines in
>
> There doesn't have to be a makefile. In a directory where there is
> nothing but prog.c, "make prog" will run "cc prog.c -o prog".

OK, so just like:

mcc prog

At least someone recognises the utility of doing that rather than the
gcc palaver. They don't even need the extension!

Yet when I build that convenience into the compiler, people come down on
me like a ton of bricks.

Talk about hypocrisy.

However, this 'make prog' is not quite what it seems:

* If you need any extra options like '-lm', it won't put them in

* If you decide to make it explicit, like 'make prog.c', it won't work.
Because 'prog' has to be the name of the output, not the input.

* If you have sources files prog.x and prog.y for languages X and Y, you
can't control which one it will build

So it's more of a parlour trick.

>> It caused confusion, and made things go badly wrong, things that would
>> have been picked up if 'make' needed the name of an input, as you surely
>> wouldn't have used the same name for both.
>
> But in "mm prog1", "prog1" isn't the name of an input; it's an output.
>
>> This seems common in Unix: let's call every input file 'makefile', and
>> every output file 'a.out'!)
>
> The fixed name of the makefile is a great idea. If I could change
> anything, I would call it ".makefile".

I think it's a terrible idea. It's like me deciding that when I type:

mcc

by itself, it will automatically compile xyzzy.c, every time. What it
actually does is a bit saner, it shows some help text:

MCC C Compiler 9-Jan-2024 23:33:19
Usage:
mcc prog[.c] # Compile prog.c to prog.exe
mcc -help # Show options
mcc -info # Further info

Even this, gcc can't get right; typing just 'gcc' shows:

gcc: fatal error: no input files
compilation terminated.

(It's actually worse than that: it shows 'gcc' in a light-grey colour,
the same colour my console background, so it's invisible. After that, it
changes the background to black for the error message itself, but
doesn't change it back. Very amateurish.)

On 11/01/2024 03:11, Chris M. Thomasson wrote:
> On 1/10/2024 7:10 PM, Chris M. Thomasson wrote:
>> On 1/10/2024 2:10 AM, David Brown wrote:
> [...]
>>> Bart seems to forget things seconds after someone tells him how to
>>> use any program that he has not written himself.  (It takes him a
>>> little longer to forget how his own programs and languages work.)
>>>
>>
>> No shit? Bard helped me with some of my C code before. He is a nice guy.
>
> Oops! I meant Bart not Bard. Sorry everybody! ;^o Damn typos (tabs),
> lol! ;^o

It makes a change from Brat, Part, and (for some reason) Bob, which I've
been called in the past, because people can't get the head around 'Bart'.

On 11/01/2024 11:44, bart wrote:
> On 11/01/2024 02:46, Kaz Kylheku wrote:
>> On 2024-01-10, bart <bc@freeuk.com> wrote:
>
>>> I once claimed that with the build schemes I prefer, you usually have to
>>> type only two things:
>>>
>>>       mm prog                 # my language
>>
>> You mean: "cd /path/to/proj/project; mm prog", right?
>
> Well, it could be done as:
>
>    mm <proglocation>
>
> Which in my typical projects, might mean typing:
>
>    mm \cx\cc
>
> This creates \cx\cc.exe

This behaviour is shared with the C compiler 'mcc'.

However, it is different from other C compilers, where if you do:

cc path/prog.c

it produces an executable, say prog.exe, in the current directory, not
at path/prog.exe. Same if creating an object file.

What are the reasons for that?

Because it sounds like it will cause all sorts of issues, for example:

gcc -c /abc/a.c
gcc -c /def/a.c

These two distinct sources files.

The two invocations will produce two different object files, both called
a.o, and both stored in the current directory. The second will overwrite
the first.

Products like NASM work like mine.

Don't tell me: you have to use 'make' to paper over all the deficiences
in these world-class tools that appear to be written by 12-year-olds.

On 10/01/2024 21:20, bart wrote:
> On 10/01/2024 19:24, bart wrote:
>> On 10/01/2024 18:39, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>>> [...]
>>>>> Yet, the entire application can be built with
>>>>> $ make
>>>>
>>>> I bet you can't. There's something missing. Unless the implicit file
>>>> that make uses happens to be in that '$' directory. Usually you have
>>>> to navigate to the project first.
>>>
>>> That '$' is a shell prompt, not a directory.
>>>
>>> Yes, you have to "cd" (like "chdir" on Windows) to the project directory
>>> before typing "make".  You also have to make sure the computer is
>>> powered on, login, launch a shell, and maybe one or two other things
>>> before you get to that point.
>>
>> You're missing the point. SL is making a big deal about the fact that
>> you can type 'make' without providing any apparent input. But that
>> input is provided when you use 'cd' to get the relevant folder.
>>
>> Or do you think that the 'make' command provided will build that
>> specific project irrespective of the CWD?
>
> Let me put it another way; how does:
>
>   $ make
>
> know it is to build that project, and not any other? The default input
> is presumably "./makefile", with the key bit being that ".".

Yes, that's the usual way for non-trivial uses. (For simple cases, the
build-it rules are good enough, given a target.) You can give make an
explicit makefile ("make -f proj.make") or it will try to find the
default one in the current directory. For gnu make (there are /many/
other "make" implementations), it will try "GNUmakefile", "makefile",
then "Makefile".

>
> So, when claiming that you only need to type one thing to start the
> process, it is disingenuous to leave out that part out.

No. Your makefile (or cmake files, or bake files, or whatever build
system you use) are part of your project - they are part of the source.

>
> After all, if you wanted to build project A, and, separately, project B,
> you can't do both of them like this:
>
>    $ make
>    $ make

I think most people here assume the reader is familiar with the very
basics of working a computer. But if you want it spelt out, you would
generally do :

$ cd ~/projects/project_a
$ make
$ cd ~/projects/project_b
$ make

Does that answer your question?

If the two projects are closely connected, you might have them organised
as sub-directories of "project". Then at the top-level, you could have
a makefile with:

all : project_a project_b
..PHONY : project_a project_b

project_a :
$(MAKE) -C project_a

project_b :
$(MAKE) -C project_b

Then you can build project_a by going to the project_a directory and
typing "make", or going to the top-level project directory and typing
"make project_a", or going to the top-level project directory and typing
"make" to build project_a and project_b, together. (This is often
particularly nice when using parallel make to make use of all the cores
in your expensive computer.)

>
> We've covered this before. While I quite like sensible defaults, where C
> compilers tend to be sticklers for dotting all the Is, 'make' goes a
> little too far the other way.
>
> Before typing 'make', you'd better be sure you're in the right place!
>

The same is true of getting undressed, and indeed most things in life.

On 11/01/2024 12:24, David Brown wrote:
> On 10/01/2024 21:20, bart wrote:

>> Before typing 'make', you'd better be sure you're in the right place!
>>
>
> The same is true of getting undressed, and indeed most things in life.
>

You might remember a discussion last autumn about building Lua 5.4.

There was a lot of confusion since the sources you got from googling
'github lua', and also I think from the releases from that github site,
and sources obtained via 'lua.org', were different.

The latter had an extra directory level compared with github, and two
makefiles rather than one:

c:\xxx\lua-5.4.6>dir makefile*/s
Directory of c:\xxx\lua-5.4.6
02/05/2023 20:06 3,150 Makefile

Directory of c:\xxx\lua-5.4.6\src
03/02/2023 10:43 7,685 Makefile

Github had only the latter level.

Since both have the same name and both can be invoked with:

make

it meant no error was reported (like: 'no such makefile'), it just went
wrong.

Here, having to specify the name of a file, /and/ ensuring those two
input files weren't identically named, could have saved a lot trouble by
detecting the discrepancy sooner.