On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:

> A #include directive with <> searches for a "header", which is not
> stated to be a file. A #include directive with "" searches for a file
> in an implementation-defined manner; if that search fails, it tries
> again as if <> had been used.

The trouble with that interpretation is, it would seem to rule out the use
of things like include libraries for user headers. Do you really think
that was the intention?

On Fri, 2 Feb 2024 11:05:22 +0100, David Brown wrote:

> On 02/02/2024 00:30, Lawrence D'Oliveiro wrote:
>
>> Ninja was created as an alternative to Make.
>
> It is an alternative to some uses of make - but by no means all uses.

It gets rid of the overlap when you have a meta-build system generating
the lowest-level build control files (Makefiles).

On Fri, 2 Feb 2024 19:52:45 +0000, bart wrote:

> as -o filename.o filename.as

On *nix systems, we can use “cc” as kind of a “universal” compile command,
not just for C code but for assembler as well, e.g.

cc -c filename.o filename.s

(without preprocessor)

cc -c filename.o filename.S

(with preprocessor)

cc -o filename filename.S

(with preprocessor and linking stages as well).

Can your system offer these options?

On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:

> That's true: only 47 years in computing, and 42 years of evolving,
> implementing and running my systems language.

On how many different platforms?

Seems like your primary experience has been with beating your head against
Microsoft Windows. That’s got to have health implications.

On 02/02/2024 21:23, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 19:52:45 +0000, bart wrote:
>
>> as -o filename.o filename.as
>
> On *nix systems, we can use “cc” as kind of a “universal” compile command,
> not just for C code but for assembler as well, e.g.
>
> cc -c filename.o filename.s
>
> (without preprocessor)
>
> cc -c filename.o filename.S
>
> (with preprocessor)
>
> cc -o filename filename.S
>
> (with preprocessor and linking stages as well).
>
> Can your system offer these options?

What option is that, to have one command 'cc' that can deal with N
different languages?

No. But I can offer a system where you have a choice of N different
compilers or assemblers for the same language:

lc64 filename.c
tcc filename.c
gcc filename.c -ofilename.exe
mcc filename

nasm -fwin64 filename.asm
yasm -fwin64 filename.asm
aa filename -obj
as filename.s -ofilename.o

How do you choose different compilers or assemblers with 'cc'?

I also offer a scheme with my tools where the tool magically knows what
language it is dealing with:

mm filename (filename.m => filename.exe)
mcc filename (filename.c => filename.exe)
aa filename (filename.asm => filename.exe)
qq filename (run filename.q)
pci filename (run filename.pcl)
ms filename (run filename.m)

..m and .q files are lead modules of an application.
..c files are standalone modules

One .asm file normally represents a whole program unless generated from mcc

On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:
>
>> That's true: only 47 years in computing, and 42 years of evolving,
>> implementing and running my systems language.
>
> On how many different platforms?

I started in 1976. I started using Windows for my products in 1995
because all my potential customers could buy an off-the-shelf Windows
PC. Linux was nowhere. Unix was only in academia, I think; nowhere
relevant to me anyway.

My first compiler (not for my language) targetted PDP10. Subsequent ones
generated code for Z80 plus 3 generations of x86.

I started using the C library in 1995 too (via my FFI), as it was
simpler than WinAPI for file-handling.

> Seems like your primary experience has been with beating your head against
> Microsoft Windows. That’s got to have health implications.

That wasn't a serious question was it; you just wanted to have a go at
Windows.

Why do you consider that fair game, but people hate if when anyone
criticises Unix?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>> A #include directive with <> searches for a "header", which is not
>> stated to be a file. A #include directive with "" searches for a file
>> in an implementation-defined manner; if that search fails, it tries
>> again as if <> had been used.
>
> The trouble with that interpretation is, it would seem to rule out the use
> of things like include libraries for user headers. Do you really think
> that was the intention?

I don't know. I imagine an implementation could interpret the word
"file" to include information extracted from libraries. Note that it
doesn't have to correspond to the concept of a "file" used in <stdio.h>;
that refers to files in the execution environment, not the compilation
environment.

--
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 Fri, 2 Feb 2024 22:12:04 +0000, bart wrote:

> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
>
>> Seems like your primary experience has been with beating your head
>> against Microsoft Windows. That’s got to have health implications.
>
> That wasn't a serious question was it; you just wanted to have a go at
> Windows.

You yourself have complained endlessly about build setups that work fine
on *nix systems, but that give you trouble on Windows. It’s like you don’t
see the source of your difficulties right in front of your eyes.

> Why do you consider that fair game, but people hate if when anyone
> criticises Unix?

I don’t care about “Unix” any more, and I doubt many other people do. All
the systems legally entitled to call themselves ”Unix” are dying if not
already dead.

On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote:

> What option is that, to have one command 'cc' that can deal with N
> different languages?

Hint: it uses the filename extension to determine which language, and
which flavour of the language even, it is dealing with.

> No. But I can offer a system where you have a choice of N different
> compilers or assemblers for the same language:

Are their ABIs compatible?

On Fri, 02 Feb 2024 16:09:09 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>
>>> A #include directive with <> searches for a "header", which is not
>>> stated to be a file. A #include directive with "" searches for a file
>>> in an implementation-defined manner; if that search fails, it tries
>>> again as if <> had been used.
>>
>> The trouble with that interpretation is, it would seem to rule out the
>> use of things like include libraries for user headers. Do you really
>> think that was the intention?
>
> I don't know. I imagine an implementation could interpret the word
> "file" to include information extracted from libraries.

Then the distinction between “headers” that are “files”, versus those that
are not, as so carefully worded in the standard (as you pointed out),
becomes meaningless.

On 2024-02-03, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 02 Feb 2024 16:09:09 -0800, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>>
>>>> A #include directive with <> searches for a "header", which is not
>>>> stated to be a file. A #include directive with "" searches for a file
>>>> in an implementation-defined manner; if that search fails, it tries
>>>> again as if <> had been used.
>>>
>>> The trouble with that interpretation is, it would seem to rule out the
>>> use of things like include libraries for user headers. Do you really
>>> think that was the intention?
>>
>> I don't know. I imagine an implementation could interpret the word
>> "file" to include information extracted from libraries.
>
> Then the distinction between “headers” that are “files”, versus those that
> are not, as so carefully worded in the standard (as you pointed out),
> becomes meaningless.

Not any more than the distinction between shell functions, built-in
commands and external commands.

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

On 02/02/2024 18:26, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 02/02/2024 15:18, Scott Lurndal wrote:
>
>>
>> You're saying that anyone not using Unix, not building 10Mloc projects,
>> and not a fan of make, should FOAD?
>
> No. I'm saying that your dislike of make is personal. If you
> don't like it, don't use it. Make your own, nobody is stopping
> you. Just don't brag about how "small", "easy" or "nice" it is
> until it can handle the same job as make.
>

Well no. These are impossible design specifications. Obviously we would
like something which is smaller than make, easier to use, generally
nice, and also supports every single job that "make" supports. But the
only way you can achieve that is to keep the program essentially the
same and fiddle about a bit with the syntax. And at best, that will
achieve a few marginal improvements.

To build a "smaller, easier, nicer" make, if that is the goal (and it's
a very legitimate one), you're going to have to ask what does make do?
What functionality does it have that is rarely used, or which could be
achieved on other ways, or which users can be persuaded isn't really
necessary?" For example make keeps a list of dependencies. But my by no
means untypical machine has six 3.7 Ghz cores. If those dependencies are
going to be hand-written C source files, there's no longer any point in
keeing track of changed dependent files. Back in the day, when make was
written there was. But now, surely we can just submit the whole lot to
the compiler, and maybe we lose a second. And by stripping the
dependencies out of make, we can write a program which is a whole lot
easier to use.

(Unfortunately if you write C++ rather than C, even a 3.7 GHz machine
isn't going to be fast enough. But maybe your users don't use C++).

But that's the way to do it.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 02/02/2024 22:12, bart wrote:
>
> Why do you consider that fair game, but people hate if when anyone
> criticises Unix?
>
Because UNIX systems used to typically cost tens of thousands of
dollars, whilst a PC could be had for under a thousand dollars. So
everyone could have a PC, but if you were given a UNIX system you were a
bit special. And that gave UNIX programmers a sense of superiority.

It's a very silly attitude of course.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 02/02/2024 18:54, Kaz Kylheku wrote:
> On 2024-02-02, bart <bc@freeuk.com> wrote:
>> The way 'as' works IS rubbish.
>
> Pretend a developer of "as" (say, the GNU one) is reading this thread.
>
> What is it that is broken?
>
> Do you have a minimal repro test case of your issue?
>
> What is the proposed fix?
>
>> turn it round and make it about me. There can't possibly be anything
>> wrong with it, whoever says so must be deluded!
>
> A vast amount of code is being compiled daily, passing through as,
> without anyone noticing.
>
It's a constant problem.

It's usually easy enough to knock up a piece of code to do something.
The problem is deploying it. Now of course some code is successfully
deployed, and you can point to that. But if that wasn't the case then
the industry would not exist at all, and, by pointing that out, you are
not really doing anything much to address the problem, which is that
deployment is where our costs are incurred, where the barriers to entry
are, and why a lot of projects fail.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 02/02/2024 18:54, Kaz Kylheku wrote:
>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>> The way 'as' works IS rubbish.
>> Pretend a developer of "as" (say, the GNU one) is reading this
>> thread.
>> What is it that is broken?
>> Do you have a minimal repro test case of your issue?
>> What is the proposed fix?
>>
>>> turn it round and make it about me. There can't possibly be anything
>>> wrong with it, whoever says so must be deluded!
>> A vast amount of code is being compiled daily, passing through as,
>> without anyone noticing.
>>
> It's a constant problem.

OK, maybe *you* can explain why it's a problem.

[...]

--
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 2024-02-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 02/02/2024 18:54, Kaz Kylheku wrote:
>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>> The way 'as' works IS rubbish.
>>
>> Pretend a developer of "as" (say, the GNU one) is reading this thread.
>>
>> What is it that is broken?
>>
>> Do you have a minimal repro test case of your issue?
>>
>> What is the proposed fix?
>>
>>> turn it round and make it about me. There can't possibly be anything
>>> wrong with it, whoever says so must be deluded!
>>
>> A vast amount of code is being compiled daily, passing through as,
>> without anyone noticing.
>>
> It's a constant problem.
>
> It's usually easy enough to knock up a piece of code to do something.
> The problem is deploying it.

I am not sure what you're referring to. The "as" program is successfully
deployed. It meets its requirements and does its job behind the scenes,
without attracting attention.

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

On 03/02/2024 06:13, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>> The way 'as' works IS rubbish.
>>> Pretend a developer of "as" (say, the GNU one) is reading this
>>> thread.
>>> What is it that is broken?
>>> Do you have a minimal repro test case of your issue?
>>> What is the proposed fix?
>>>
>>>> turn it round and make it about me. There can't possibly be anything
>>>> wrong with it, whoever says so must be deluded!
>>> A vast amount of code is being compiled daily, passing through as,
>>> without anyone noticing.
>>>
>> It's a constant problem.
>
> OK, maybe *you* can explain why it's a problem.
>

You snip the explantion than demand another explantion.

I'm sitting at a computer with a C compiler installed. Currently there's
a discussion about make and Bart's ideas for a better make. So I could
look at what Bart is saying and try to write a better make. And likely
it would take a few days and not be too difficult.

But I can't easily deploy that code. I can't communicate with people who
might be interested, get it on their machines, get them to try it out. I
can do it a bit of course. I can put the source on github and I'll get
some downloads. But you'll find that on many systems it won't build, it
won't install, it won't have the correct runtime environment, it's
impossible to distribute binary executables, it needs unaceptable
fiddling with global paths to make it run effectively, if the user
doesn't own the computer the person who does own the computer won't
allow him to run the software. Etc etc. That's where the challenges are.
Far more than actually writing the program.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 03/02/2024 06:13, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>>> The way 'as' works IS rubbish.
>>>> Pretend a developer of "as" (say, the GNU one) is reading this
>>>> thread.
>>>> What is it that is broken?
>>>> Do you have a minimal repro test case of your issue?
>>>> What is the proposed fix?
>>>>
>>>>> turn it round and make it about me. There can't possibly be anything
>>>>> wrong with it, whoever says so must be deluded!
>>>> A vast amount of code is being compiled daily, passing through as,
>>>> without anyone noticing.
>>>>
>>> It's a constant problem.
>> OK, maybe *you* can explain why it's a problem.
>
> You snip the explantion than demand another explantion.

The context was bart's statement that "The way 'as' works IS rubbish".
You seemed to be agreeing that that's "a constant problem".
If you meant something else, never mind.

[snip]

--
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 03/02/2024 08:02, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 03/02/2024 06:13, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>>>> The way 'as' works IS rubbish.
>>>>> Pretend a developer of "as" (say, the GNU one) is reading this
>>>>> thread.
>>>>> What is it that is broken?
>>>>> Do you have a minimal repro test case of your issue?
>>>>> What is the proposed fix?
>>>>>
>>>>>> turn it round and make it about me. There can't possibly be anything
>>>>>> wrong with it, whoever says so must be deluded!
>>>>> A vast amount of code is being compiled daily, passing through as,
>>>>> without anyone noticing.
>>>>>
>>>> It's a constant problem.
>>> OK, maybe *you* can explain why it's a problem.
>>
>> You snip the explantion than demand another explantion.
>
> The context was bart's statement that "The way 'as' works IS rubbish".
> You seemed to be agreeing that that's "a constant problem".
> If you meant something else, never mind.
>
> [snip]
>
I was making the same point that Bart is making, but in a more general
way. I don't use as and I don't know anything about it specifically. But
the pattern with tools like that is that whilst they usually assemble
scripts correctly, they don't make them easy to deploy. That's Bart's
exerience, and it is my experience.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>
>>> A #include directive with <> searches for a "header", which is not
>>> stated to be a file. A #include directive with "" searches for a file
>>> in an implementation-defined manner; if that search fails, it tries
>>> again as if <> had been used.
>>
>> The trouble with that interpretation is, it would seem to rule out the use
>> of things like include libraries for user headers. Do you really think
>> that was the intention?
>
> I don't know. I imagine an implementation could interpret the word
> "file" to include information extracted from libraries. Note that it
> doesn't have to correspond to the concept of a "file" used in <stdio.h>;
> that refers to files in the execution environment, not the compilation
> environment.

To me what the C standard says is clear. A #include "whatever.h"
gets its stuff from a file (assuming of course the appropriate
file can be found, and not revert to the #include <whatever.h>
form). A #include <whatever.h> gets its stuff from a header,
said header perhaps being stored in a file or perhaps not, and if
file-stored then it could be a 1-1 relationship, or a 1-many
relationship, or a many-1 relationship. Since the C standard
doesn't define the term 'header', an implementation is allowed to
actualize it however the implementation chooses (including the
possibility of storing information inside the compiler itself).

bart <bc@freeuk.com> writes:

> On 31/01/2024 00:46, Tim Rentsch wrote:
>
>> Looking over one of my current projects (modest in size,
>> a few thousand lines of C source, plus some auxiliary
>> files adding perhaps another thousand or two), here are
>> some characteristics essential for my workflow (given
>> in no particular order):
>>
>> * have multiple outputs (some outputs the result of
>> C compiles, others the result of other tools)
>>
>> * use different flag settings for different translation
>> units
>>
>> * be able to express dependency information
>>
>> * produece generated source files, sometimes based
>> on other source files
>>
>> * be able to invoke arbitrary commands, including
>> user-written scripts or other programs
>>
>> * build or rebuild some outputs only when necessary
>>
>> * condition some processing steps on successful
>> completion of other processing steps
>>
>> * deliver partially built as well as fully built
>> program units
>>
>> * automate regression testing and project archival
>> (in both cases depending on completion status)
>>
>> * produce sets of review locations for things like
>> program errors or TBD items
>>
>> * express different ways of combining compiler
>> outputs (such as .o files) depending on what
>> is being combined and what output is being
>> produced (sometimes a particular set of inputs
>> will be combined in several different ways to
>> produce several different outputs)
>>
>> Indeed it is the case that producing a complete program is one
>> part of my overall build process. But it is only one step out
>> of many, and it is easy to express without needing any special
>> considerations from the build system.
>
> So, will a specific build of such a project produce a single
> EXE/DLL//SO file? (The // includes the typical file extension of
> Linux executables.)

No, there are several outputs of this kind, including object
files, static libraries, and dynamic libraries, and all for a C
environment. (There are also other outputs but of a different
kind than what you are asking about.)

I have no expectation that you will incorporate these ideas or
capabilities into a tool you are building for yourself. I gave
the list in case other readers might have an interest.

On 03/02/2024 06:30, Kaz Kylheku wrote:
> On 2024-02-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>> The way 'as' works IS rubbish.
>>>
>>> Pretend a developer of "as" (say, the GNU one) is reading this thread.
>>>
>>> What is it that is broken?
>>>
>>> Do you have a minimal repro test case of your issue?
>>>
>>> What is the proposed fix?
>>>
>>>> turn it round and make it about me. There can't possibly be anything
>>>> wrong with it, whoever says so must be deluded!
>>>
>>> A vast amount of code is being compiled daily, passing through as,
>>> without anyone noticing.
>>>
>> It's a constant problem.
>>
>> It's usually easy enough to knock up a piece of code to do something.
>> The problem is deploying it.
>
> I am not sure what you're referring to. The "as" program is successfully
> deployed. It meets its requirements and does its job behind the scenes,
> without attracting attention.
>
>

as is a development tool. So there are two aspects to it. The first is
deploying as itself. It must be available and capable of being invoked
on all machines where it needs to be available. It mustn't refuse to run
correctly because some path somewhere is not set up or it doesn't have
write permission to output an executable, and so on. That may well have
been achieved. Typing "as" into the shell on the computer I'm typing
this on does indeed invoke the program.

But the other side to it that as must make it easy to deploy the actual
useful end user programs that it is used to develop. So if we write an
as script, it must be easy to make that script part of an executable,
place it on the user's machine, and set it up so that the user can
easily run it and play space invaders or achieve whatever else he
ultimately wishes to achieve. And what Bart is saying is that that is
where as is falling down.

I don't use as myself, so it's hard to commment on the specifics. But
from experience with similar systems, this will be where the problems
lie. The complaint sems to be that because of the quirky way in which it
matches up scripts to output executables, it's too hard to package the
scripts so that they are assembled correctly. Since as I say I don't use
as I can't comment on that directly, but I can well believe it.

Of course some software is assembled with as and deployed successfully.
The program wouldn't exist if that wasn't the case.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 03/02/2024 09:05, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:

>>> Indeed it is the case that producing a complete program is one
>>> part of my overall build process. But it is only one step out
>>> of many, and it is easy to express without needing any special
>>> considerations from the build system.
>>
>> So, will a specific build of such a project produce a single
>> EXE/DLL//SO file? (The // includes the typical file extension of
>> Linux executables.)
>
> No, there are several outputs of this kind, including object
> files, static libraries, and dynamic libraries, and all for a C
> environment. (There are also other outputs but of a different
> kind than what you are asking about.)
>
> I have no expectation that you will incorporate these ideas or
> capabilities into a tool you are building for yourself. I gave
> the list in case other readers might have an interest.

OK. You seem fairly level-headed and calm, so I'll try this explanation.

Let's say that 'ccc' (not 'cc') is a C compiler; it only processes C
source files.

All that I am attempting is that for a full build for this 3-file project:

ccc one two three

which takes one.c, two.c and three.c and produces (on Windows say)
one.exe, that you can instead do:

ccc one

for the same job. That would take that particular task (together with
endless dependency lists that you have to determine with extra tools)
out of makefiles.

Here I'm not interested in incremental compilation; this is typically
for a remote build (away from the developer's setup) of a finished,
working program.

It doesn't mean doing away with 'make'; that might still be needed to
orchestrate everything else that might be needed.

Although I'd prefer that those needs were also listed separately, in
comments or readme files, so that people can devise their own solutions
if needed (see, that is now one extra level of flexibility above just
supplying a complex, busy makefile which you just have to blindly trust
will work).

But in simple cases then yes, you just need 'ccc' and a bunch of C
source files.

With my experimental compiler using my #pragma method, I can do exactly
that:

mcc lua 33 files prepended to lua.c

mcc pico 23 files created pico.c

mcc bbx 45 files created bbx.c

mcc cjpeg 54 files prepended to each
mcc djpeg 54 files

In the last example, the two programs shared 46 common .c files. I put
those #pragma lines in a common file that was then #included.

(This makes processing those lines via a script harder, but I've given
up on that idea. In the original makefile, those 46 were compiled into a
..a archive file)

I created a special lead module when there wasn't a clear candidate to
take that role. That module provides the name of the EXE.

OK, the idea works. I will leave it in my compiler, and use it as secret
weapon for my personal use.

Nobody else cares, so everyone please pretend this thread was never
posted, and sorry for wasting your time.

On 03/02/2024 01:29, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 22:12:04 +0000, bart wrote:
>
>> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
>>
>>> Seems like your primary experience has been with beating your head
>>> against Microsoft Windows. That’s got to have health implications.
>>
>> That wasn't a serious question was it; you just wanted to have a go at
>> Windows.
>
> You yourself have complained endlessly about build setups that work fine
> on *nix systems, but that give you trouble on Windows. It’s like you don’t
> see the source of your difficulties right in front of your eyes.

I guess you're not curious about WHY a project that builds easily on
Unix causes problems on Windows?

Please think about it. You are keen to just totally dismiss the problem
and suggest it is Windows that is fault.

But maybe there IS a dependency on some Unix feature that is
unnecessary. Why force Windows users to pointlessly use MSYS2 or go
through a nightmare of cross-compiling via WSL?

Apparently being considerate is not in a Unix programmer's toolkit.

>> Why do you consider that fair game, but people hate if when anyone
>> criticises Unix?
>
> I don’t care about “Unix” any more, and I doubt many other people do. All
> the systems legally entitled to call themselves ”Unix” are dying if not
> already dead.

See, I don't even know the difference. This is a collection of OSes
without even a name. I was trying to avoid saying 'Linux' because of the
preponderance of other Unix-related OSes. But I would rather shoot
myself than resort to using '*nixes'.

On 03/02/2024 01:31, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote:
>
>> What option is that, to have one command 'cc' that can deal with N
>> different languages?
>
> Hint: it uses the filename extension to determine which language, and
> which flavour of the language even, it is dealing with.

This is the filename extension which Linux famously ignores, because you
can use any extension you like?

Hint: my tools KNOW which language they are dealing with:

c:\c>copy hello.c hello.x
c:\c>mcc hello.x
Compiling hello.x to hello.exe

c:\c>copy hello.c hello.s
c:\c>mcc hello.s
Compiling hello.s to hello.exe

Now let's see what the famous gcc does:

root@XXX:/mnt/c/c# cp hello.c hello.x
root@XXX:/mnt/c/c# gcc hello.x
hello.x: file not recognized: file format not recognized

root@XXX:/mnt/c/c# cp hello.c hello.s
root@XXX:/mnt/c/c# gcc hello.s
hello.s: Assembler messages:
hello.s:2: Error: unknown vector operation: `{'
...

>> No. But I can offer a system where you have a choice of N different
>> compilers or assemblers for the same language:
>
> Are their ABIs compatible?

Huh? They will all use the platform ABI.