On 1/11/2024 2:42 AM, David Brown wrote:
> 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.
>
>

Agreed! I bet you two would have a very kind and nice time reminiscing
about old compilers and interesting times when you were programming hard
on a hard problems. I wish I could be a fly on the wall for that live
correspondence. :^)

On 1/12/2024 1:31 PM, Kaz Kylheku wrote:
> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>> but also build documentation (doxygen, LaTeX,
>>> pandoc, graphviz, etc.), run tests, run "clean", build release zip
>>> files, download to a target board via a debugger, and all sorts of other
>>> bits and pieces according to the needs of the project.  One makefile
>>> beats a dozen scripts.
>>
>> It looks like 'make' is competing with 'bash' then!
>
> Make recipes are actually lines of shell code executed by the shell;
> make does not reimplement a redundant command interpretation.(*)
>
> You can use the SHELL variable to specify an alternative interpreter
> for the make recipe lines.
>
> ---
>
> * GNU Make contains logic for recognizing recipe lines that are
> trivial commands, and eliding the use of the shell for those. So that is
> to say that some simple command like "cc this.c -o this.o -c" is handled
> via fork and exec directly. It must be the case that if SHELL is used
> to specify an alternative interpreter, that logic is suppressed.
>
>>>> That's exactly how I view gcc's UI. Most Linux-derived utilities are
>>>> as bad: you invoke them, and they just apparently hang. Then you
>>>> realise they're waiting for input. Would it kill somebody to get them
>>>> to display a prompt?
>>>
>>> Are you sure you are not exaggerating just a /tiny/ bit?
>>
>> I mainly remember the times when they do hang.
>
> DOS/Windows stuff hangs also:
>
> C:\Users\kazk>findstr foo
> ... "hang" ...
>
> Even Microsoft clued in to the idea that a text filter shouldn't
> spew extraneous diagnostics by default.
>
>> But with 'as', it just sits there. I wonder what it's waiting for; for
>> me to type in ASM code live from the terminal? (If 'as' is designed for
>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember
>> it generating discrete, temporary .s files.)
>
> gcc -pipe works in pipe mode.
>
> The "as" command is intended for compiler use; not only is it not
> an interactive assembler, it doesn't even have particularly good
> diagnostics for batch use. You have to know what you're doing.
>

For my special atomic lib, I used GAS to create an object file, then
just linked them in. all okay.

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

MASM version... :^)

https://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html

On Fri, 12 Jan 2024 22:16:25 +0000, Scott Lurndal wrote:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>bart <bc@freeuk.com> writes:
>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 12/01/2024 13:40, David Brown wrote:
>>>>>> On 12/01/2024 00:20, bart wrote:
>>>>>
>>>>> But with 'as' it just sits there. I wonder what it's waiting for; for
>>>>> me to type in ASM code live from the terminal?
>>>> It does that so you can pipe the assembler source code in to the
>>>> assembler.
>>>> $ cat file.s | as
>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> Yes, I used this as an example pipeline. I don't recall
> if the original as(1) wrote to stdout or always just to
> a.out.

IIRC, Dennis Ritchie told a story about early Unix implemented on a system
without memory protection mechanisms. The language tools of the time took
up a lot of memory when compiling, and could trespass into other user's
process memory space. It became customary, on this system, to holler
"A dot OUT" whenever compiling, to warn the other programmers that the
compiler was in use.

I believe that the compiler suite /always/ wrote an a.out file. But,
it wouldn't have been the assembler (as), but the linker (ld) that
created it.

>>> What might someone expect the output to be? Probably not 'a.out', more
>>> likely hello.o. Why /isn't/ it just hello.o?
>>
>>Partly historical inertia, and partly because "as" can't always know
>>what the output file should be, for example if its input isn't a file.
>
> Yup. a.out is the historical inertia.

--
Lew Pitcher
"In Skills We Trust"

On 1/12/24 18:59, bart wrote:

>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> Using ">" on binary content? That seems off.

Why ?

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

On Fri, 12 Jan 2024 23:04:56 +0000, Lew Pitcher wrote:
[snip]
>
> I believe that the compiler suite /always/ wrote an a.out file. But,
> it wouldn't have been the assembler (as), but the linker (ld) that
> created it.

Looking back into my manuals, it appears that the assembler defaulted
to writing a.out if the assembly did not require any external references.

To quote the "Unix Assembler Reference Manual" for Seventh Edition Unix
"As ... produces an output file that contains relocation information
and a complete symbol table; thus the output is acceptable to the
UNIX link-editor ld, which may be used to combine the outputs of
several assembler runs and to obtain object programs from libraries.
The output format has been designed so that if a program contains
no unresolved references to external symbols, it is executable
without further processing."
and
"The output of the assembler is by default placed on the file a.out
in the current directory; the "-o" flag causes the output to be
placed on the named file."

[snip]
--
Lew Pitcher
"In Skills We Trust"

On 1/9/2024 5:32 PM, Kaz Kylheku wrote:
> On 2024-01-09, Bart <bc@freeuk.cm> wrote:
>> On 09/01/2024 22:37, James Kuyper wrote:
>>
>>> 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,
>>
>> So why doesn't a /C/ compiler put itself into conforming mode?
>
> That's like asking, why don't they just switch to the Tokyo dialect
> in Osaka?

https://youtu.be/yEJCQdee8vk

;^)

>
> Vendors like their dialect of C and promote that in their product.
>
> Users who want to write portable code and be alerted when they stray
> from that program are the ones who have to configure something.
>
> The GNU Coding Standards states it explicitly:
>
> https://www.gnu.org/prep/standards/standards.html#Non_002dGNU-Standards
>
> "For instance, Standard C says that nearly all extensions to C are
> prohibited. How silly! GCC implements many extensions, some of which
> were later adopted as part of the standard. If you want these
> constructs to give an error message as “required” by the standard, you
> must specify ‘--pedantic’, which was implemented only so that we can
> say “GCC is a 100% implementation of the standard”, not because there
> is any reason to actually use it.
>
> There you go; the GNU project doesn't think you have any reason to
> identify situations when your program violates ISO C, such that it
> requires a diagnostic and is not required to be translated.
>
>> Then lots of people who don't bother with those fiddly options don't get
>> the wrong impression about what C actually allows.
>
> What C allows is for dialects which can be called some kind of C.
> Microsoft C, GNU C, ..
>
> If people experiment with GNU C, and thus what GNU C allows, but then
> think C allows it, they are simply wrong; they don't understand the
> difference between a common language and a dialect.
>

On 1/10/2024 7:33 PM, Chris M. Thomasson wrote:
> 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!

You are just experimenting along, make a bug and it infects the
computer. Monkeys banging on keyboards can create a, well, something?...
Just comic relief. Sorry to but in here.

>
>>
>> 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/12/2024 3:48 PM, Chris M. Thomasson wrote:
> On 1/10/2024 7:33 PM, Chris M. Thomasson wrote:
>> 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!
>
> You are just experimenting along, make a bug and it infects the
> computer. Monkeys banging on keyboards can create a, well, something?...
> Just comic relief. Sorry to but in here.
>
>
>>
>>>
>>> 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.
>>
>

https://youtu.be/iLVLfL3QVQQ

;^D

On 1/9/2024 5:05 PM, James Kuyper wrote:
> Bart <bc@freeuk.cm> writes:
>> On 09/01/2024 22:37, James Kuyper wrote:
>>> 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,
>>
>> So why doesn't a /C/ compiler put itself into conforming mode?
>
> You didn't use any C compilers, at least, you didn't use them as C
> compilers. At least two of them (I don't know about tcc) can compile
> standard C, but only if you instruct them to do so. When you fail to
> tell them so, they are not standard C compilers, they are compilers for
> non-standard variants of C.
>
>> It seems THAT is too hard for it to understand!
>>
>> Seriously, why don't they do that?
>
> Because they don't want to. The language that they compile by default is
> a language that they like better than standard C. People like me who
> value standard conformance are sufficiently common that they provide
> options which enable standard conformance, but their target audience
> WANTS support for a C-like language that they like better than standard
> C, and that's what they provide.
>
>> Then lots of people who don't bother with those fiddly options don't
>> get the wrong impression about what C actually allows.
>
> Most people who don't bother checking out the available options are
> generally primarily interested in knowing what the compiler they are
> actually using allows - if they cared about standard conformance, they'd
> check whether the compiler claimed to be standard conforming, and would
> quickly notice that the compiler only makes such claims when invoked
> with particular options. People who don't bother making such checks,
> despite wanting standard conformance, quickly learn that they don't
> actually get it - except for you, of course. That's something you seem
> incapable of learning.

CDECL, ahhh the C ABI. Nice! Lets use it!

On 1/11/2024 4:24 AM, David Brown wrote:
> 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.
>

Comic relief. Bart vs the Makefile:

https://youtu.be/_-5QTdC7hOo

Just kidding around.

On 12/01/2024 21:51, Kaz Kylheku wrote:
> On 2024-01-12, bart <bc@freeuk.com> wrote:
>> On 12/01/2024 18:02, Janis Papanagnou wrote:
>>> On 12.01.2024 18:09, bart wrote:
>>>> On 12/01/2024 16:34, David Brown wrote:
>>>>>>
>>>>>> It looks like 'make' is competing with 'bash' then!
>>>
>>> Why don't you just read about those two tools and learn, instead
>>> of repeatedly spouting such stupid statements of ignorance.
>>
>> Because I've repeatedly said I don't need them. Why can't you accept that?
>
> You do need make, if you're on a Unix-like system and you want to make
> "hello" out of "hello.c" with a command that consists of only two words.

To clarify:

* You have a hypothetical situation where you want to turn hello.c into
hello.exe (I'm going insist on that extension in this example).

* The tool you have generates a.out given the two-word command 'cc hello.c'

* Getting hello.exe requires the three-word command 'cc hello.c -ohello.exe'

The solution apparently is not to make a three-line change to 'cc' to
fix it, but to create a new language and implemention just to provide a
wrapper around the unchanged behaviour of 'cc'.

That sounds barmy.

The astronauts who had to apply the conversion kit to the HST had no
choice. Clearly they would rather have got the mirror in the first place.

But your attitude seems to be that such a sticking-plaster fix is superior.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[91 lines deleted]
>
> Comic relief. Bart vs the Makefile:
>
> https://youtu.be/_-5QTdC7hOo
>
> Just kidding around.

Chris, can you at least snip most of the quoted text when you post a
joke followup?

--
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 1/12/2024 4:24 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> [91 lines deleted]
>>
>> Comic relief. Bart vs the Makefile:
>>
>> https://youtu.be/_-5QTdC7hOo
>>
>> Just kidding around.
>
> Chris, can you at least snip most of the quoted text when you post a
> joke followup?
>

Yeah. I see what you mean. Quote 100 lines to write one. Sorry, a bad
habit indeed. To quote more than necessary. ;^o

On 1/12/2024 4:36 PM, Chris M. Thomasson wrote:
> On 1/12/2024 4:24 PM, Keith Thompson wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[...]
>> Chris, can you at least snip most of the quoted text when you post a
>> joke followup?
[...]
> Yeah. I see what you mean. Quote 100 lines to write one. Sorry, a bad
> habit indeed. To quote more than necessary. ;^o

Sorry to Bart as well, it was just a joke.

bart <bc@freeuk.com> writes:
> On 12/01/2024 21:51, Kaz Kylheku wrote:
>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>> On 12/01/2024 18:02, Janis Papanagnou wrote:
>>>> On 12.01.2024 18:09, bart wrote:
>>>>> On 12/01/2024 16:34, David Brown wrote:
>>>>>>> It looks like 'make' is competing with 'bash' then!
>>>>
>>>> Why don't you just read about those two tools and learn, instead
>>>> of repeatedly spouting such stupid statements of ignorance.
>>>
>>> Because I've repeatedly said I don't need them. Why can't you accept that?
>> You do need make, if you're on a Unix-like system and you want to
>> make
>> "hello" out of "hello.c" with a command that consists of only two words.
>
> To clarify:
>
> * You have a hypothetical situation where you want to turn hello.c
> into hello.exe (I'm going insist on that extension in this example).

OK.

> * The tool you have generates a.out given the two-word command 'cc hello.c'

OK.

> * Getting hello.exe requires the three-word command 'cc hello.c -ohello.exe'

I'd write that as "cc hello.c -o hello.exe". (Unix option parsing
typically allows the argument to an option to be either part of the same
word or a separate word.)

And if I have a single "hello.c" source file and I want to generate an
executable from it, I rarely use "make". I just type something like
"gcc hello.c -o hello". (I might have "hello.cpp" in the same
directory, and I don't know which rule takes precedence. That's not
going to be an issue in a larger project.)

> The solution apparently is not to make a three-line change to 'cc' to
> fix it, but to create a new language and implemention just to provide
> a wrapper around the unchanged behaviour of 'cc'.

No, "make" was not written as a solution to the "problem" of
cc's command-line syntax. Most of us don't think it's a problem.
(Yes, I know you do; no need to say so again.)

It was written as a tool for building large projects by expressing
dependencies, so that if you change one file you can recompile
those files, and only those files, that need to be recompiled.
That is perhaps not quite as important as it once was.

It happens that once you have a working Makefile, it works equally
well either to rebuild a project after a single change, or to build
an entire project from scratch. Someone could probably create
a simpler version of "make" that doesn't look at dependencies,
and that always rebuilds everything. Such a tool would be worse
than "make" for building projects during development, and not
significantly better than "make" for building projects from scratch.

And that's ignoring the "-j" option, which allows "make" to execute
multiple steps in parallel. That works only because "make" knows
about dependencies, and it can result in a full build from scratch
finishing much more quickly. A simple script that just compiles
each file isn't likely to do that. You can typically specify a
maximum number of parallel jobs equal to the number of CPUs on your
build system, e.g., `make -j $(nproc)`.

> That sounds barmy.

To you, I'm sure it does. It isn't.

> The astronauts who had to apply the conversion kit to the HST had no
> choice. Clearly they would rather have got the mirror in the first
> place.
>
> But your attitude seems to be that such a sticking-plaster fix is superior.

I'd like to bring something to your attention. You often make
statements about the attitudes of the people you're having these
discussions with. Those statements are almost always wrong. I'd say
more if I thought you'd be interested.

--
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 12/01/2024 22:22, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/01/2024 18:02, Janis Papanagnou wrote:
>
>>
>>> And this is a crucial feature; for professional non-trivial projects.
>>
>> Come on then, tell me how big your projects are. Are they bigger than
>> Scott Lurndal's 10Mloc example? (Which seems to be mostly Python source
>> code.)
>
> The example shown had 8 million lines of C and C++ code. Less
> than 10% was python.
>
> Granted, a significant fraction of that is generated from yaml descriptions
> of memory mapped registers, yet it is still compiled by the C and C++ compilers.

I misread 700Kloc of Python as 7Mloc (figures should be comma-separated).

Malcolm's BBX project is about 400Kloc of code. But 340Kloc of it is in
one header file that contains data.

That accounts for the executable being about 2MB.

A cold build with mcc takes 2.7 seconds. Subsequent full builds after a
minor change take 1.4 seconds.

If I wanted I can spend a few days removing the ASM intermediates, that
would likely double the speed to 0.7 seconds, and probably 0.5 seconds
if the compiler was optimised.

Tcc is probably already at that, but has some issues with this code.

If you remember, this is the project that needed CMake to produce the
makefile (which didn't work). I build it with:

c:\bbx\src\mcc @bbx

with bbx containing:

*.c freetype/*.c samplerate/*.c

Fun fact 1: 'gcc @bbx' doesn't work. File-globbing (I assume just on
this Windows version ) only works on the command line, not from inside a
file like this.

Fun fact 2: If I get rid of the file-globbing and list the files
individually, gcc requires that \ is used as path separator, not /. I
can also never remember which one it doesn't like. (My mcc accepts either.)

On 13/01/2024 00:47, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:

> It happens that once you have a working Makefile, it works equally
> well either to rebuild a project after a single change, or to build
> an entire project from scratch. Someone could probably create
> a simpler version of "make" that doesn't look at dependencies,
> and that always rebuilds everything. Such a tool would be worse
> than "make" for building projects during development, and not
> significantly better than "make" for building projects from scratch.
>
> And that's ignoring the "-j" option, which allows "make" to execute
> multiple steps in parallel. That works only because "make" knows
> about dependencies, and it can result in a full build from scratch
> finishing much more quickly. A simple script that just compiles
> each file isn't likely to do that. You can typically specify a
> maximum number of parallel jobs equal to the number of CPUs on your
> build system, e.g., `make -j $(nproc)`.

That's a reasonable thing to do. But how does make do it? Can't a
compiler apply the same approach if N files have been submitted?

After all C allows independent compilation of modules. (Something my
language doesn't have; there the granularity is an EXE file, not a module.)

>
>> That sounds barmy.
>
> To you, I'm sure it does. It isn't.
>
>> The astronauts who had to apply the conversion kit to the HST had no
>> choice. Clearly they would rather have got the mirror in the first
>> place.
>>
>> But your attitude seems to be that such a sticking-plaster fix is superior.
>
> I'd like to bring something to your attention. You often make
> statements about the attitudes of the people you're having these
> discussions with. Those statements are almost always wrong. I'd say
> more if I thought you'd be interested.
>

My post was in response to "needing 'make' if you wanted a two-word
command to build 'hello'".

I didn't seriously think that was the reason make was invented.

bart <bc@freeuk.com> writes:
> On 13/01/2024 00:47, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>
>> It happens that once you have a working Makefile, it works equally
>> well either to rebuild a project after a single change, or to build
>> an entire project from scratch. Someone could probably create
>> a simpler version of "make" that doesn't look at dependencies,
>> and that always rebuilds everything. Such a tool would be worse
>> than "make" for building projects during development, and not
>> significantly better than "make" for building projects from scratch.
>> And that's ignoring the "-j" option, which allows "make" to execute
>> multiple steps in parallel. That works only because "make" knows
>> about dependencies, and it can result in a full build from scratch
>> finishing much more quickly. A simple script that just compiles
>> each file isn't likely to do that. You can typically specify a
>> maximum number of parallel jobs equal to the number of CPUs on your
>> build system, e.g., `make -j $(nproc)`.
>
> That's a reasonable thing to do. But how does make do it? Can't a
> compiler apply the same approach if N files have been submitted?

I've never looked into it.

I suppose it could be done, but IMHO compilers are complex enough
without adding logic to perform parallel compilations, especially since
"make" already solves that problem.

> After all C allows independent compilation of modules. (Something my
> language doesn't have; there the granularity is an EXE file, not a
> module.)
>
>>
>>> That sounds barmy.
>> To you, I'm sure it does. It isn't.
>>
>>> The astronauts who had to apply the conversion kit to the HST had no
>>> choice. Clearly they would rather have got the mirror in the first
>>> place.
>>>
>>> But your attitude seems to be that such a sticking-plaster fix is superior.
>> I'd like to bring something to your attention. You often make
>> statements about the attitudes of the people you're having these
>> discussions with. Those statements are almost always wrong. I'd say
>> more if I thought you'd be interested.
>
> My post was in response to "needing 'make' if you wanted a two-word
> command to build 'hello'".

Kaz wrote:
] You do need make, if you're on a Unix-like system and you want to make
] "hello" out of "hello.c" with a command that consists of only two words.

I don't believe he was suggesting that needing a two-word command is a
reasonable requirement.

> I didn't seriously think that was the reason make was invented.

It can be difficult to tell when you're serious.

--
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 12.01.2024 21:59, Keith Thompson wrote:
>
> If you run "command" at a shell prompt, its stdout goes to the terminal
> in which the shell is running. [...]

Not quite. It goes to what stdout has actually been defined. E.g.

exec > ouch
ls -l

So it depends on the context.

Janis

On 12.01.2024 19:53, bart wrote:
> On 12/01/2024 18:10, Janis Papanagnou wrote:
>> On 12.01.2024 18:59, bart wrote:
>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>>
>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>>
>>> Using ">" on binary content?
>>
>> Of course.
>>
>>> That seems off.
>>
>> Why?
>
> Because when you see ">" on a command line, it means redirecting output
> that would normally be shown as text on a console or terminal.

I propose that you try to give up what you think is "normally" and
base your knowledge and opinions on facts. Honestly, it will make
communication generally easier and not make you look like a moron.

>
> But you rarely see pure binary being displayed like that on a text display.

Consider stdin and stdout just as input/output channels and don't
make unnecessary further assumptions that will only mislead you.

(Other aspects had been posted by others already, so I abstain.)

> [...]
>
> However I'm obviously just a bot, so what do I know.

That was actually just a thought that popped up. But after thinking
about it I got aware that AI bots (despite their inherent problems)
are more fact-oriented and operate on a much larger knowledge base.

Janis

On 1/12/2024 8:01 PM, Janis Papanagnou wrote:
> On 12.01.2024 19:53, bart wrote:
>> On 12/01/2024 18:10, Janis Papanagnou wrote:
>>> On 12.01.2024 18:59, bart wrote:
>>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>>>
>>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>>>
>>>> Using ">" on binary content?
>>>
>>> Of course.
>>>
>>>> That seems off.
>>>
>>> Why?
>>
>> Because when you see ">" on a command line, it means redirecting output
>> that would normally be shown as text on a console or terminal.
>
> I propose that you try to give up what you think is "normally" and
> base your knowledge and opinions on facts. Honestly, it will make
> communication generally easier and not make you look like a moron.
>
>>
>> But you rarely see pure binary being displayed like that on a text display.
>
> Consider stdin and stdout just as input/output channels and don't
> make unnecessary further assumptions that will only mislead you.
>
> (Other aspects had been posted by others already, so I abstain.)
>
>> [...]
>>
>> However I'm obviously just a bot, so what do I know.
>
> That was actually just a thought that popped up. But after thinking
> about it I got aware that AI bots (despite their inherent problems)
> are more fact-oriented and operate on a much larger knowledge base.

Oh man, that is mean. AI has some issues. One of them is:

https://www.facebook.com/photo/?fbid=954662645692734&set=a.110008616824812

Afiact, it needs to interact with Wolfram...

On 1/12/2024 8:05 PM, Chris M. Thomasson wrote:
> On 1/12/2024 8:01 PM, Janis Papanagnou wrote:
>> On 12.01.2024 19:53, bart wrote:
>>> On 12/01/2024 18:10, Janis Papanagnou wrote:
>>>> On 12.01.2024 18:59, bart wrote:
>>>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>>>>
>>>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>>>>
>>>>> Using ">" on binary content?
>>>>
>>>> Of course.
>>>>
>>>>> That seems off.
>>>>
>>>> Why?
>>>
>>> Because when you see ">" on a command line, it means redirecting output
>>> that would normally be shown as text on a console or terminal.
>>
>> I propose that you try to give up what you think is "normally" and
>> base your knowledge and opinions on facts. Honestly, it will make
>> communication generally easier and not make you look like a moron.
>>
>>>
>>> But you rarely see pure binary being displayed like that on a text
>>> display.
>>
>> Consider stdin and stdout just as input/output channels and don't
>> make unnecessary further assumptions that will only mislead you.
>>
>> (Other aspects had been posted by others already, so I abstain.)
>>
>>> [...]
>>>
>>> However I'm obviously just a bot, so what do I know.
>>
>> That was actually just a thought that popped up. But after thinking
>> about it I got aware that AI bots (despite their inherent problems)
>> are more fact-oriented and operate on a much larger knowledge base.
>
> Oh man, that is mean. AI has some issues. One of them is:
>
> https://www.facebook.com/photo/?fbid=954662645692734&set=a.110008616824812
>
> Afiact, it needs to interact with Wolfram...
>

No ambiguity. cos(0) = sin(pi/2) wrt the results?

;^)

On 12.01.2024 21:14, bart wrote:
> On 12/01/2024 19:15, Scott Lurndal wrote:
>> [...]
>
> [...]
>
> You guys all deserve medals for being so tolerant.

I think your cynicism is unjustified.

When I read all your (often just annoying) posts in this thread and
could observe then how calm and obliging the audience answered the
posts for a long time - where e.g. my patience would had been at an
end already - I said to myself; what a polite and tolerant audience
this is!

Yes, folks, you are tough guys. You have my due respect. Sincerely.

Janis

On 12.01.2024 21:16, bart wrote:
> On 12/01/2024 19:18, Scott Lurndal wrote:
>>
>> '> name' tells the shell to open 'name' on stdout before executing 'as'.
>
> And without '> name', where does stuff sent to stdout end up?

It depends on the output channel where stdout was directed to
before the command is called. You know that the default is the
terminal, but it depends. That's how it works.

Janis

On 2024-01-13, bart <bc@freeuk.com> wrote:
> On 13/01/2024 00:47, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>
>> It happens that once you have a working Makefile, it works equally
>> well either to rebuild a project after a single change, or to build
>> an entire project from scratch. Someone could probably create
>> a simpler version of "make" that doesn't look at dependencies,
>> and that always rebuilds everything. Such a tool would be worse
>> than "make" for building projects during development, and not
>> significantly better than "make" for building projects from scratch.
>>
>> And that's ignoring the "-j" option, which allows "make" to execute
>> multiple steps in parallel. That works only because "make" knows
>> about dependencies, and it can result in a full build from scratch
>> finishing much more quickly. A simple script that just compiles
>> each file isn't likely to do that. You can typically specify a
>> maximum number of parallel jobs equal to the number of CPUs on your
>> build system, e.g., `make -j $(nproc)`.
>
> That's a reasonable thing to do. But how does make do it? Can't a
> compiler apply the same approach if N files have been submitted?

Yes. And in fact, languages with good module support like Modula-2
don't need external make utilities.
>
> After all C allows independent compilation of modules. (Something my
> language doesn't have; there the granularity is an EXE file, not a module.)

C has no specific syntax for expressing modules. It has translation
units, with preprocessor header files used for interfacing.

Dependencies are useful for incremental compilation (as Keith notes
above). It's a given that when no part of a program is built, we
are going to build all of its modules and so we don't need the
dependencies.

In the GCC world, there are compiler options used to tell the compiler,
for each compiled translation unit, to emit the dependencies that it
encounters. It emits them in the form of a makefile.

For instance, if "foo.c" includes "foo.h" and "bar.h", then when gcc is
compiling it (if given suitable options) will emit a small "foo.d" file
(you can control the name) which looks something like:

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

These *.d files can be included into the makefile.

Once these files exist, there is a dependency graph for the project,
which is accurate, since it comes from the compiler.

It's a hacky system, because, for instance, it will not pick up
situations when a header file is deleted. Say bar.h is deleted and foo.c
edited not to include it. The .d file is still the same and says that
making foo.o requires bar.h. So make will refuse to build foo.o due to a
missing prerequisite. But a correct .d file won't be emitted unless
foo.o is compiled.

In most other situations, it's fine.

A C compiler could, instead of emitting makefile fragments, keep
the dependency information in some repository which it itself
understands, in order to recompile what is necessary.

Only problem is that that compiler would be reimplementing most of make,
probably badly, and every other similar compiler would have to do the
same in order to have the same benefit.

(You'd pretty much want some "libmake" library for this, so as not
to reimplement it from scratch. Should every compiler implement its own
job server/scheduler for handling parallel builds?)

> My post was in response to "needing 'make' if you wanted a two-word
> command to build 'hello'".

In that specific environment, that's what we already have. That two-word
command will do it with the least effort on your part.

You need it if you want to expend no more effort than the two word
command: not write a whole bunch of scripting or other code so
that you then have some other two-word command.

> I didn't seriously think that was the reason make was invented.

Yet, at some point make acquired suffix rules, which infer
prerequisites from targets by pattern. Moreover, someone added
a suffix rule that an X can be made from X.c. Not only that but
from other suffixed files like X.f (Fortran) and whatnot.

So the need was acknowledged; someone found that it would be useful
to build foo from foo.c with a simple "make foo" command, which
doesn't require a makefile to be present.

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