On Sun, 20 Aug 2023 06:05:04 -0700 (PDT), bart c <bart4858@gmail.com>
wrote in <1075f829-1174-4456-b57d-74331cd61aa8n@googlegroups.com>:

> I suppose this is not really relevant, so long as somebody can climb to
> the top of this heap of complexity and plant a flag saying only 'Make`.
> Then it doesn't matter if its Mount Everest or an anthill.

There you go. You said earlier to stop using the "m" word, but then
there you go, and mention it again.

> Or does it?

It doesn't matter.

I like make(1), but I've used it for decades, and it's not "obscure"
to me. Still, I'm no expert -- it is one of those tools that if I
am using it for a non-trivial project, I'll be RTFM.

If you find the construction of a Makefile inscrutable, perhaps
consider a nutshell handbook, online documentation, etc.
on the subject. It is a POSIX tool, so you'll find yourself
running into it frequently (as you've noticed).

target:(tab)source[ source]
(tab)action
[(tab)action]

Nowadays, I see a lot of autoconf, which generates Makefiles for
the system you want to build on.

../configure
make
sudo make install

Also, by itself, make(1) has default rules for handling
a C programming environment. You can change them:

..c.o:
tcc -c $<

(This is a trivial example for illustrative purposes
only...yes, I left out $(CFLAGS), not really knowing if
tcc uses those...or really, anything about it.)

And make has parallelism:

make -j16

So, I suggest:

man make

...and BTW, I wouldn't have mentioned it, but you've been
a bit stabby when it comes to make. It's a strange hill
to die on, Friend. 🖖️

--
-v

On Sunday, 20 August 2023 at 13:15:49 UTC+1, David Brown wrote:
> On 19/08/2023 18:00, Kaz Kylheku wrote:
> > On 2023-08-19, David Brown <david...@hesbynett.no> wrote:
> >> On 19/08/2023 13:39, bart c wrote:
> >>> That's interesting. One of the limitations of Lua was that it didn't have proper integer type, it used a 64-bit float.
> >>>
> >>
> >> Lua is configurable, and can support different types. When I embedded
> >> in a 32-bit microcontroller program, I use 32-bit integers as the number
> >> type.
> >
> > I don't feel the party has properly started until someone makes that
> > sort of thing a command line option. Or better yet, environment
> > variable.
> >
> I don't think something like that would be remotely helpful for Lua, but
> that is possibly due to my lack of experience with the language. You'd
> get a more complete answer from a Lua newsgroup.
>
Seems unexceptional to me. You might need the full range of 64 bit integers
for some reason. But most likely all the integers in the program are under 2^53
and fractions are useful. So a default to using 64-bit floats and an option to
use 64-bit integers would be the obvious thing to provide, if Lua is indeed
configurable.

On 20/08/2023 16:25, Malcolm McLean wrote:
> On Sunday, 20 August 2023 at 13:15:49 UTC+1, David Brown wrote:
>> On 19/08/2023 18:00, Kaz Kylheku wrote:
>>> On 2023-08-19, David Brown <david...@hesbynett.no> wrote:
>>>> On 19/08/2023 13:39, bart c wrote:
>>>>> That's interesting. One of the limitations of Lua was that it didn't have proper integer type, it used a 64-bit float.
>>>>>
>>>>
>>>> Lua is configurable, and can support different types. When I embedded
>>>> in a 32-bit microcontroller program, I use 32-bit integers as the number
>>>> type.
>>>
>>> I don't feel the party has properly started until someone makes that
>>> sort of thing a command line option. Or better yet, environment
>>> variable.
>>>
>> I don't think something like that would be remotely helpful for Lua, but
>> that is possibly due to my lack of experience with the language. You'd
>> get a more complete answer from a Lua newsgroup.
>>
> Seems unexceptional to me. You might need the full range of 64 bit integers
> for some reason. But most likely all the integers in the program are under 2^53
> and fractions are useful. So a default to using 64-bit floats and an option to
> use 64-bit integers would be the obvious thing to provide, if Lua is indeed
> configurable.

It is indeed configurable (though it was a long time ago when I used it
much). You configure it for the type of numbers you want to use, then
build it - it is compile-time configuration, not run-time configuration.
The point of using smaller types (such as 32-bit int) is to make it
more efficient on smaller targets (such as small embedded systems). It
would be of questionable benefit to have it a choice of 64-bit or 32-bit
integers at runtime (remember, Lua is byte encoded and runs on a virtual
machine) - I'd imagine that would be very much slower than simply fixing
on 64-bit would be.

On Sunday, 20 August 2023 at 15:24:50 UTC+1, vallor wrote:
> On Sun, 20 Aug 2023 06:05:04 -0700 (PDT), bart c <bart...@gmail.com>
> wrote in <1075f829-1174-4456...@googlegroups.com>:
> > I suppose this is not really relevant, so long as somebody can climb to
> > the top of this heap of complexity and plant a flag saying only 'Make`.
> > Then it doesn't matter if its Mount Everest or an anthill.
> There you go. You said earlier to stop using the "m" word, but then
> there you go, and mention it again.

I was going to use asterisks but that would have been silly.
> > Or does it?
>
> It doesn't matter.
>
> I like make(1), but I've used it for decades, and it's not "obscure"
> to me.

And it's something I've managed to avoid using for decades. But then I didn't use Unix and I didn't use C. I don't think I've missed anything!

> If you find the construction of a Makefile inscrutable, perhaps
> consider a nutshell handbook, online documentation, etc.
> on the subject. It is a POSIX tool, so you'll find yourself
> running into it frequently (as you've noticed).

I once started to implement Make, as that's a good way of learning a language. To that end I downloaded the manual, then changed my mind when I started to read it. It's an abomination of a language.

> ./configure

Now THAT is hundred times worse than make. I've seen such files of 30,000 lines of pointless scripting, sometimes dwarfing the source code of the application, which can take minutes to plough through , but even worse is when somebody expects you to run it on Windows. You will know that those scripts are written in a shell language that runs on Linux, and relies on a dozen utilities that only exist on Linux. And, Linux isn't Windows.

> Also, by itself, make(1) has default rules for handling
> a C programming environment. You can change them:
>
> .c.o:
> tcc -c $<
>
> (This is a trivial example for illustrative purposes
> only...yes, I left out $(CFLAGS), not really knowing if
> tcc uses those...or really, anything about it.)

I don't even know what that does.

> And make has parallelism:
>
> make -j16

Yeah, I've seen that. It's solving the wrong problem. You're putting a turbo-charger on a car, but still taking a pointlessly wrong and rambling route to your destination. And more accurately: you're putting it on a car that can only go at walking place to start with.

> So, I suggest:
>
> man make
>
> ...and BTW, I wouldn't have mentioned it, but you've been
> a bit stabby when it comes to make. It's a strange hill
> to die on, Friend. 🖖️

Stabby? If you mean I don't like it, then you're dead right! But I'm pretty much forced to deal with because it is apparently impossible to build even the simplest project unless you introduce a new, much harder language to describe the project structure. And sometimes even that is not enough, you also need 'configure' and sometimes CMake.

Nobody seems to understand how to produce streamlined, simplified build processes for a working open source project. You don't just take a developer's sprawling system of nested folders, dependency graphs, a dozen Linux dependences even for 'cross-platform', compiler-specific options, all sorts of rubbish, wrap it up into a huge ungainly parcel and scrawl 'makefile' on the outside.

It takes some effort.

On Sunday, 20 August 2023 at 15:15:45 UTC+1, David Brown wrote:
> On 20/08/2023 15:05, bart c wrote:
> > On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote:
> >> On 20/08/2023 03:13, bart c wrote:
> >>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote:
> >>>> sc...@slp53.sl.home (Scott Lurndal) writes:
> >>>>> bart c <bart...@gmail.com> writes:
> >>>> [...]
> >>>>>> So how do you directly invoke the actual C compiler?
> >>>>>
> >>>>> As if you don't already know.
> >>>>>
> >>>>> $ gcc -o a.o a.c
> >>>> That creates an executable named "a.o". Bad idea.
> >>>>> or
> >>>>>
> >>>>> $ gcc -o a a.c
> >>>> That invokes the compiler and the linker.
> >>>>
> >>>> To invoke just the compiler:
> >>>>
> >>>> gcc -c a.c
> >>>>
> >>>> which creates an object file named "a.o". If for some odd reason you
> >>>> want the object file to have a different name:
> >>>>
> >>>> gcc -c a.c -o foo.o
> >>>>
> >>>> Giving an object file a name not ending in ".o" is almost certainly a
> >>>> bad idea. (That's for Unix-like systems; other systems might have a
> >>>> different convention like ".obj".)
> >>>
> >>> Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows:
> >>>
> >>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s
> >>>
> >>> It doesn't look very user friendly.
> >> It isn't user friendly - nor is it intended to be. It is intended that
> >> you use "gcc" (or "g++", "gfortran", or other drivers that are
> >> convenient for other gcc languages) as the driver program that will then
> >> invoke "cc1" with whatever options are needed. The options and
> >> interface for "cc1" are not considered user documentation - they are
> >> internal, might not be complete, and may change wildly between versions
> >> of gcc. It is the options for "gcc" that are documented for user usage..
> >
> > How about 'ld'; is that supposed to be directly usable?
> "ld" is not part of gcc. It is part of an independent project,
> binutils, that is often used alongside gcc. (You know this, of course,
> and only feign ignorance.)

Why 'of course'? Is gcc the only C implementation on the planet?

The C compilers I've used most often are complete, self-contained solutions.. Mine doesn't even have or use a linker.

Why is so much is made of the idiosyncratic way that C works on Unix systems? Who cares that 'as' is in compartment A, cc1 is in B, ld is in C, the standard headers is in D1 and may D2, the runtime is E, gcc itself is F, and 'make' is, what, G? Just build the effing program!

When I install gcc on Windows, I really, really don't care how it's organised or who is responsible for what. It should take source code at one end, and output binaries at the other.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> bart c <bart4858@gmail.com> writes:
>[...]
>>>So how do you directly invoke the actual C compiler?
>>
>> As if you don't already know.
>>
>> $ gcc -o a.o a.c
>
>That creates an executable named "a.o". Bad idea.

Yes, I forgot to add the -c. I had in an earlier post included it.

On 8/20/2023 6:14 AM, Phil Carmody wrote:
> Matthew Ernisse <matt@going-flying.com> writes:
>> On Mon, 14 Aug 2023 02:44:16 -0000 (UTC), Kenny McCormack wrote:
>>> In article <8fb22829-9b5e-4108-a513-df3b72391405n@googlegroups.com>,
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> ...
>>>>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
>>>>> development environment, so arguing that it doesn't have "make" is kind of
>>>>> pointless.
>>>
>>> I may actually have mis-spoken here. DOS did originally come with GWBASIC,
>>> so you could, at least write and run programs back then.
>>
>> Later DOS version (I think 6+) came with QBASIC which was pretty close to
>> an early IDE, reasoned individuals may debate whether it is a development
>> environment but I believe I recall single-stepping in it.
>
> DOS 5 came with GORILLA.BAS, that I do remember.

Big time! I used to have a lot of fun hacking around with it to create
different behaviors.

bart c <bart4858@gmail.com> writes:

> On Sunday, 20 August 2023 at 00:10:38 UTC+1, Ben Bacarisse wrote:
>> bart c <bart...@gmail.com> writes:
>> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote:
>> >> bart c <bart...@gmail.com> writes:
>> >
>> >> > That is, you want to be able to type:
>> >> >
>> >> > X
>> >> >
>> >> > and not:
>> >> >
>> >> > X Y
>> >> No, I want to type
>> >>
>> >> make
>> >> make tests
>> >> make install
>> >> make clean
>> >> make mylib.a
>> >
>> > I'm not familiar with how make is used.
>> You have very strong opinions about something you don't know much about.
>
> Well, I'm being brow-beaten by so many people into using something I
> don't want to use.

What?!! How are you being brow-beaten into using make? Don't use it.
Don't talk about it. Ignore it.

> Or I'm obliged to use it in building open-source software (something
> I'm rapidly losing interest in).

What software is there that (a) you want to try, (a) forces you to use
make, and (c) does not work "out of the box"? People here (or in other
groups) could help you get that software to work if you can be specific.
But if the software uses make and does not build out of the box, it's
probably Unix/Liunx only and might too much effort to port.

> I'm seen enough of it to know that I don't like it and it's not for
> me.

Yes, I think most people got that a long time ago.

> Giving you case studies of all the cases where following the build
> rules generally results in failure seems to cut no ice; the problem
> can't possibly be a fragile and error prone process, people have to
> get personal.

If you want the build to work, ask for help.

> The makefile syntax is obscure enough that if something goes wrong, I
> can't fix it. (I've suggested that a build-system for a one-off
> end-user build of a working product should use a streamlined process
> and a simpler makefile; that fell on deaf ears.)

Community software is built by people who want something better. If you
want to be helpful, contribute a better build script or makefile. If
you don't want to do that, shrug your shoulders and move on. That
project did not test the build in (or does not care about) an
environment similar to yours.

> Clearly some of you use 'make' for routine development.

Every day (that I'm programming). I use for other things too. I have
some documents I need to maintain on my phone. Typing "make" builds the
documents from LaTeX and uploads them to my device. There are a few
files other than the actual text that make tracks dependencies on. For
example, a shared file has the aspect ratio of my screen. When I change
phone, the documents are rebuilt.

> I don't;

Right. But without learning how it works, you want to post message
after message about how awful it is for your uses either real (building
in unsupported environments) or imagined. Just move on.

> It is in the latter cases where I was coming across invocations of
> programs like gcc where it has invented its own rules and folklore. I
> find that a nuisance.

Whatever it is you mean, you can probably make gcc work how you want
with a one-line shell function or alias. It's not going to change, no
matter how many posts you write about. Fix and move on...

> This is where the suggestions start: nobody cares how you invoke gcc,
> it's usually invoked from a makefile script. So I'm slowly drawn into
> something that is 100 times worse than that minor nuisance of typing
> file extensions and providing options that should not be needed.

You are not "drawn in". You are a grown man. You can just say "I don't
like that, I prefer to do it may way" and that's that. Instead you
launch yourself into a critique of a tool you don't use, don't care
about and don't understand. From the outside, it looks like crazy
behaviour.

>> > You can also choose to give it a shorter name than 'makefile'!
>>
>> Yes, but the typing is not, and never has been, the issue. If the name
>> is not defaulted everyone has to guess where the rules for this project
>> are stored.
>
> Tool Projectname

I don't know what that means, but as it seems likely that you are
suggesting an "improvement" to something that no one but you objects to.
Why not just walk away?

>> And it's redundant and intrusive to keep specifying the
>> configuration, even if it's easy to type.
>
> Well, you have to type something five times, whether it's 'make',
> 'make makefile', 'make lua', or a dedicated script called 'makelua', I
> don't see much difference.

I note that you don't mind that. Your tools can work that way if you
prefer. I'm happy with what make does. I'm happy with what your
tools do as well.

> Having the project name as part of the invocation I see as useful
> information and confirmation of what you are doing. You don't want to
> click on the wrong terminal window out of 6, type 'make', and you find
> it, a bit later, you're building the wrong project.

I note that you prefer everything to be explicit. I'm happy with what
make does.

>> > gcc is a bad example to follow since it does too much on the command
>> > line and performs multiple functions.
>> But it's what you were talking about. You seem to want it to do less.
>> I don't.
>
> I want it to compile C code, not any other language.

OK. you are out of luck, but I think you have found a compiler that
does what you want, so you are all set are you not?

> But if I invoke it 10,000 times, I have to type .c 10,000 times (times
> the average number of modules) to tell it I'm compiling C and not C++,
> Ada or Fortran. If nothing else, it's not ergonomic.

I note that you don't like typing the .c, yet you haven't written that
one-line function or alias so that gcc does what you want. It would
have been quicker than typing that paragraph.

> I can fix this by providing wrapper to give the behaviour I want, but
> this seems wrong: gcc is already a driver program, and it's already
> huge, yet I have to provide yet another layer to make it usable?

Spin. It's usable as it is. The command alias is to make it suit your
particular requirements. You can't possibly expect gcc to be written
with your choices in mind, so you have only these options: live with it,
fix it or post about it endlessly on Usenet.

> Just deleting it and forgetting about C seems very attractive.

But for some reason not quite attractive enough. Why? That's not
rhetorical. I really would like to know why you spend this amount of
time on something you don't like and don't want to use. It's really
odd.

--
Ben.

bart c <bart4858@gmail.com> writes:
[...]
> Why is so much is made of the idiosyncratic way that C works on Unix
> systems?

Because you keep complaining about it and misrepresenting it.

If you stop posting about it, the discussion will die out.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 20/08/2023 20:48, Ben Bacarisse wrote:
> bart c <bart4858@gmail.com> writes:

> But for some reason not quite attractive enough. Why? That's not
> rhetorical. I really would like to know why you spend this amount of
> time on something you don't like and don't want to use. It's really
> odd.

I'd replied at length to some of your other points, until I came to this.

So why is it hard to move on? Because it means you have all won.

You've championed what I consider to be a poor tool for building open
source software. You're championing complexity.

You're dismissing the many simpler and more reliable ways there are of
describing a C project structure to a C compiler.

You're dismissing my reports that those complex ways are unreliable
(Aach! You must be doing something wrong! There nothing wrong with make!)

And no I'm not going to submit fixes to 1000s of open sources, because
my fixes will not be maintained. The people who maintain them need to be
receptive to the problems, and receptive to better ways of doing it.
They're not. This is just ingrained now.

'Make' is just the one level of the problem. Sometimes the makefiles or
some essential source file is synthesised by a prior process.

There is apparently no 'simple' any more.

Anyway, in my own work, I've long solved the build problem. Anyone can
build any project of mine from source via two files that I provide:
mm.exe and app.ma.

They have to type 'mm app' on the command line. If they moan that that
is not as simple as 'make', then I can provide a third file 'make.bat'
that contains 'mm app'!

Bart <bc@freeuk.com> writes:

> On 20/08/2023 20:48, Ben Bacarisse wrote:
>> bart c <bart4858@gmail.com> writes:
>
>> But for some reason not quite attractive enough. Why? That's not
>> rhetorical. I really would like to know why you spend this amount of
>> time on something you don't like and don't want to use. It's really
>> odd.
>
> I'd replied at length to some of your other points, until I came to
> this.

That's a good idea. Often there is only one key point in contention.

> So why is it hard to move on? Because it means you have all won.

Ah, I see. What does winning look like to you? Stopping me from using
make? Making me use your software? Are you prepared to document it and
support it? Or is winning to you just getting people to say they agree
with you? Do you want me to say that make is crap and gcc shouldn't
assemble and compile C on the same command line?

> You've championed what I consider to be a poor tool for building open
> source software. You're championing complexity.

I am not championing anything. I use it. I like it. It has always
worked to build the software I've needed it to build. You found open
source software that does not build on Windows using make. I am not
surprised; I think every makefile I've ever written is Unix/Liunx
specific in some regard (usually "make install" copies files to system
locations).

> You're dismissing the many simpler and more reliable ways there are of
> describing a C project structure to a C compiler.

Where did I dismiss them? I've not seen one to dismiss. If you know of
one, why did you not contribute such a description for at least one of
the projects that you found would not build on Windows using the Linux
makefile?

> You're dismissing my reports that those complex ways are unreliable (Aach!
> You must be doing something wrong! There nothing wrong with make!)

There are things wrong with make. Where have I ever said there aren't?
You argue like a politician not a developer making technical points.

You report that it's "unreliable" but in fact I think you are just
reporting that the software does not build on Windows. make is not a
way to solve portability issues with builds. It is primarily a
development tool.

> And no I'm not going to submit fixes to 1000s of open sources, because my
> fixes will not be maintained.

I suggest you start with one that you care about. If there are none
(that you care about) what on Earth are you complaining about?

And if your fix really is a truly simple way to build some Linux
software on Windows it will be trivial for you to maintain (for that one
project you really care about). And I guarantee there will be take-up
by others. The reason you find so much Linux software that won't build
on Windows is that no one in the project wants to put the effort in. A
simple solution will be wildly popular.

The trouble is I don't think you are offering an alternative. At least,
if you are, I missed it.

> The people who maintain them need to be
> receptive to the problems, and receptive to better ways of doing
> it. They're not. This is just ingrained now.

If you believe that, then according to your initial remark you have
already lost, so why are still posting about it?

--
Ben.

On 21/08/2023 00:51, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 20/08/2023 20:48, Ben Bacarisse wrote:
>>> bart c <bart4858@gmail.com> writes:
>>
>>> But for some reason not quite attractive enough. Why? That's not
>>> rhetorical. I really would like to know why you spend this amount of
>>> time on something you don't like and don't want to use. It's really
>>> odd.
>>
>> I'd replied at length to some of your other points, until I came to
>> this.
>
> That's a good idea. Often there is only one key point in contention.
>
>> So why is it hard to move on? Because it means you have all won.
>
> Ah, I see. What does winning look like to you? Stopping me from using
> make? Making me use your software? Are you prepared to document it and
> support it? Or is winning to you just getting people to say they agree
> with you? Do you want me to say that make is crap and gcc shouldn't
> assemble and compile C on the same command line?

How about admitting that the solutions based around makefiles can end up
more elaborate than necessary, and more fragile.

>
>> You've championed what I consider to be a poor tool for building open
>> source software. You're championing complexity.
>
> I am not championing anything. I use it. I like it. It has always
> worked to build the software I've needed it to build. You found open
> source software that does not build on Windows using make.

But why SHOULDN'T it build on Windows? What's the difference between a C
compiler on Windows and on Linux? Isn't C supposed to be portable?
Especially for programs that just read and write files.

Perhaps you've never explored why that is, as it doesn't affect you.

Here are a couple more projects I've looked at:

---------------------------
Libjpeg library. This is an old one from 1998. There are 15 makefile.xxx
files for multiple, mostly obsolete compilers. The docs for non-Unix
look horrendous; I will not bother.

I tried the Unix instructions of using ./configure, which writes the
makefile, then make. That worked after a minor tweak.

But what is it about compiling these 72 .c files under non-Unix, that
makes it so hard? I can't just compile them as some .h files need to be
created.

Anyway this can be chalked up under a project that I can't build despite
all those makefiles. Why are these 15 C compilers all so different
anyway, and how do they differ from Unix compilers? It's the same language!

----------------------------------------
Gzlib. A compression utility.

This only had makefile.am/.in, and ./configure. Another project which
you'd think, as it reads and writes files, would hardly be OS-specific.

But there is one very interesting aspect of this one: the configure
script was 38,000 lines, the biggest I've ever seen.

All the .c and .h files of this project were only 8,000 lines altogether.

So another Linux-only one. Does it work? ./configure does: 55 seconds
spent testing whether print supports "%a" format and the like.

However, 'make' actually failed:

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
'/mnt/c/gzip-1.13/build-aux/missing' aclocal-1.16
/mnt/c/gzip-1.13/build-aux/missing: line 81: aclocal-1.16: command not found

I don't know what that means (maybe it doesn't like WSL). I can't just
do 'gcc *.c' because config.h is missing. If only the docs would just
tell me what's supposed to be inside it.

If only the build process was much simpler and more transparent! As it
is, I don't even know what language this utility is written in, some mix of:

C and CPP
Makefile syntax
Bash
M4
--------------------------

> The trouble is I don't think you are offering an alternative. At least,
> if you are, I missed it.

I've suggested easy ways of building C programs such as the ones in my
example. Forgetting 'make' would be a first step (I suspect makefiles
are IDE-generated some of the time).

Here's one from the past: I wanted to build Algol68 Genie (A68G). This
built under Linux, taking about 5 minutes (mostly auto-conf stuff
again). I wanted to build under Windows.

Here I managed to isolate the 72Kloc of .c files. Compiling them with
bcc took around one second, and I got a working a68g.exe file.

Now, why couldn't the docs just say that in the first place! Just submit
this list of C files to the nearest C compiler.

I contend that most projects would build more quickly and with fewer errors

>> The people who maintain them need to be
>> receptive to the problems, and receptive to better ways of doing
>> it. They're not. This is just ingrained now.
>
> If you believe that, then according to your initial remark you have
> already lost, so why are still posting about it?

Maybe my remarks might rub off on some people.

On 21/08/2023 01:26, Bart wrote:
> On 21/08/2023 00:51, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 20/08/2023 20:48, Ben Bacarisse wrote:
>>>> bart c <bart4858@gmail.com> writes:
>>>
>>>> But for some reason not quite attractive enough.  Why?  That's not
>>>> rhetorical.  I really would like to know why you spend this amount of
>>>> time on something you don't like and don't want to use.  It's really
>>>> odd.
>>>
>>> I'd replied at length to some of your other points, until I came to
>>> this.
>>
>> That's a good idea.  Often there is only one key point in contention.
>>
>>> So why is it hard to move on? Because it means you have all won.
>>
>> Ah, I see.  What does winning look like to you?  Stopping me from using
>> make?  Making me use your software?  Are you prepared to document it and
>> support it?  Or is winning to you just getting people to say they agree
>> with you?  Do you want me to say that make is crap and gcc shouldn't
>> assemble and compile C on the same command line?
>
> How about admitting that the solutions based around makefiles can end up
> more elaborate than necessary, and more fragile.
>
>>
>>> You've championed what I consider to be a poor tool for building open
>>> source software. You're championing complexity.
>>
>> I am not championing anything.  I use it.  I like it.  It has always
>> worked to build the software I've needed it to build.  You found open
>> source software that does not build on Windows using make.
>
> But why SHOULDN'T it build on Windows? What's the difference between a C
> compiler on Windows and on Linux? Isn't C supposed to be portable?
> Especially for programs that just read and write files.
>
> Perhaps you've never explored why that is, as it doesn't affect you.
>
> Here are a couple more projects I've looked at:
>

There is one more that is of interest, this is a small one of 3 .c files
and 3 .h files. It doesn't build on Windows because of a missing header
file (<arpa/inet.h>). But on WSL Linux, 'make' reports this:

/usr/bin/ld: mjpeg.o: in function `fprintf':
c:\mjpeg-master/mjpeg.c:364: undefined reference to `__mingw_vfprintf'

If I just do 'gcc *.c' however, it works fine! Here's the makefile:

BIN ?= mjpeg
SRC := $(wildcard *.c)
OBJ := $(SRC:.c=.o)
CFLAGS ?= -Wall -g
PREFIX ?= /usr/local/bin

all: $(BIN)

clean:
rm -rf $(OBJ) $(BIN)

install: $(BIN)
install -p $(BIN) $(PREFIX)

$(BIN): $(OBJ)

Pardon me for having no idea where the problem might be.

On 21/08/2023 02:02, Bart wrote:
> On 21/08/2023 01:26, Bart wrote:
>> On 21/08/2023 00:51, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 20/08/2023 20:48, Ben Bacarisse wrote:
>>>>> bart c <bart4858@gmail.com> writes:
>>>>
>>>>> But for some reason not quite attractive enough.  Why?  That's not
>>>>> rhetorical.  I really would like to know why you spend this amount of
>>>>> time on something you don't like and don't want to use.  It's really
>>>>> odd.
>>>>
>>>> I'd replied at length to some of your other points, until I came to
>>>> this.
>>>
>>> That's a good idea.  Often there is only one key point in contention.
>>>
>>>> So why is it hard to move on? Because it means you have all won.
>>>
>>> Ah, I see.  What does winning look like to you?  Stopping me from using
>>> make?  Making me use your software?  Are you prepared to document it and
>>> support it?  Or is winning to you just getting people to say they agree
>>> with you?  Do you want me to say that make is crap and gcc shouldn't
>>> assemble and compile C on the same command line?
>>
>> How about admitting that the solutions based around makefiles can end
>> up more elaborate than necessary, and more fragile.
>>
>>>
>>>> You've championed what I consider to be a poor tool for building open
>>>> source software. You're championing complexity.
>>>
>>> I am not championing anything.  I use it.  I like it.  It has always
>>> worked to build the software I've needed it to build.  You found open
>>> source software that does not build on Windows using make.
>>
>> But why SHOULDN'T it build on Windows? What's the difference between a
>> C compiler on Windows and on Linux? Isn't C supposed to be portable?
>> Especially for programs that just read and write files.
>>
>> Perhaps you've never explored why that is, as it doesn't affect you.
>>
>> Here are a couple more projects I've looked at:
>>
>
> There is one more that is of interest, this is a small one of 3 .c files
> and 3 .h files. It doesn't build on Windows because of a missing header
> file (<arpa/inet.h>). But on WSL Linux, 'make' reports this:
>
>  /usr/bin/ld: mjpeg.o: in function `fprintf':
>  c:\mjpeg-master/mjpeg.c:364: undefined reference to `__mingw_vfprintf'
>
> If I just do 'gcc *.c' however, it works fine! Here's the makefile:
>
>  BIN ?= mjpeg
>  SRC := $(wildcard *.c)
>  OBJ := $(SRC:.c=.o)
>  CFLAGS ?= -Wall -g
>  PREFIX ?= /usr/local/bin
>
>  all: $(BIN)
>
>  clean:
>      rm -rf $(OBJ) $(BIN)
>
>  install: $(BIN)
>      install -p $(BIN) $(PREFIX)
>
>  $(BIN): $(OBJ)
>
>
> Pardon me for having no idea where the problem might be.
>

Never mind, I realised what it was as soon as I posted, as those Windows
file paths looked funny.

It is still a fact that 'gcc *.c' worked, but 'make' failed because the
former recompiles all sources , but make didn't. There were .o files of
mixed origin present; make can't detect that.

Bart <bc@freeuk.com> writes:

> On 21/08/2023 00:51, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 20/08/2023 20:48, Ben Bacarisse wrote:
>>>> bart c <bart4858@gmail.com> writes:
>>>
>>>> But for some reason not quite attractive enough. Why? That's not
>>>> rhetorical. I really would like to know why you spend this amount of
>>>> time on something you don't like and don't want to use. It's really
>>>> odd.
>>>
>>> I'd replied at length to some of your other points, until I came to
>>> this.
>> That's a good idea. Often there is only one key point in contention.
>>
>>> So why is it hard to move on? Because it means you have all won.
>> Ah, I see. What does winning look like to you? Stopping me from using
>> make? Making me use your software? Are you prepared to document it and
>> support it? Or is winning to you just getting people to say they agree
>> with you? Do you want me to say that make is crap and gcc shouldn't
>> assemble and compile C on the same command line?
>
> How about admitting that the solutions based around makefiles can end up
> more elaborate than necessary, and more fragile.

Solutions to what? As far as I can tell, the failures you see are
because they don't do what you want. You keep bringing up examples, but
you never drill down into them. I commented on a whole bunch of these
failures that you posted, but that was the end of it.

But makefiles are not build scripts. They are guaranteed to be more
elaborate than needed to build the software since the dependencies are
irrelevant to the build. It's hard-wired into the design that they are
more elaborate than the compile command what you want them to be.

I have simple portable programs with makefiles where the simplest build
instructions would just be cc -o prog *.c. The makefile would most
likely do the job (provided none of the targets that might use system
commands like mkdir, rm and so on were referenced) but it's bound to be
more complex than the compile command.

>>> You've championed what I consider to be a poor tool for building open
>>> source software. You're championing complexity.
>> I am not championing anything. I use it. I like it. It has always
>> worked to build the software I've needed it to build. You found open
>> source software that does not build on Windows using make.
>
> But why SHOULDN'T it build on Windows? What's the difference between a C
> compiler on Windows and on Linux? Isn't C supposed to be portable?
> Especially for programs that just read and write files.

Yes, why? We should take an example and look at it in detail, but you
just keep moving on. Portable C is very hard to write (100% portable
that is). If you crack that, the makefile is irrelevant. So is any
configure script. Just compile the C.

Unfortunately, Windows users expect *.txt to be expanded by the program
and Unix users don't. Unix users expect -flags and Windows users expect
/flags. Unix users will expect a configuration called .progrc created
in the user's home directory. I don't know what Windows users expect
for that, but the compile command needs at least something like
-DWINDOWS to allow for these variations.

> Perhaps you've never explored why that is, as it doesn't affect you.

I've moved on. For example, when I see some software is Windows-native
I don't even consider tying to build it for Linux. Maybe I'm missing
some good stuff, but I gave up trying a long time ago. I don't think the
problem is that Windows software uses make, it's that a lot of
programmers don't know how to write portable C.

> Here are a couple more projects I've looked at:

More! Why not take one we've already looked at and investigate in depth
what's going on?

> Libjpeg library. This is an old one from 1998. There are 15 makefile.xxx
> files for multiple, mostly obsolete compilers. The docs for non-Unix look
> horrendous; I will not bother.

Post the link so I can at least see what you are talking about if this
is the example you want me to examine. I think I know the library you
mean, but I don't know the exact source you are looking at.

> Gzlib. A compression utility.

Post the link if this is the one you want to look at in depth.

>> The trouble is I don't think you are offering an alternative. At least,
>> if you are, I missed it.
>
> I've suggested easy ways of building C programs such as the ones in my
> example. Forgetting 'make' would be a first step (I suspect makefiles are
> IDE-generated some of the time).

Your solution is to write portable C. Is that it?

> Here's one from the past: I wanted to build Algol68 Genie (A68G).

Another one! Can we stick to one example?

> This built under Linux, taking about 5 minutes (mostly auto-conf stuff
> again). I wanted to build under Windows.
>
> Here I managed to isolate the 72Kloc of .c files. Compiling them with bcc
> took around one second, and I got a working a68g.exe file.

Bug free, or just working?

> Now, why couldn't the docs just say that in the first place! Just submit
> this list of C files to the nearest C compiler.

If this is the example you want to look at in depth? I can't answer
your question without taking some time looking and in the past you've
dropped each and every example as soon as there's any comment on it. I
don't want to waste my time.

--
Ben.

On 2023-08-21, Bart <bc@freeuk.com> wrote:
> On 21/08/2023 00:51, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 20/08/2023 20:48, Ben Bacarisse wrote:
>>>> bart c <bart4858@gmail.com> writes:
>>>
>>>> But for some reason not quite attractive enough. Why? That's not
>>>> rhetorical. I really would like to know why you spend this amount of
>>>> time on something you don't like and don't want to use. It's really
>>>> odd.
>>>
>>> I'd replied at length to some of your other points, until I came to
>>> this.
>>
>> That's a good idea. Often there is only one key point in contention.
>>
>>> So why is it hard to move on? Because it means you have all won.
>>
>> Ah, I see. What does winning look like to you? Stopping me from using
>> make? Making me use your software? Are you prepared to document it and
>> support it? Or is winning to you just getting people to say they agree
>> with you? Do you want me to say that make is crap and gcc shouldn't
>> assemble and compile C on the same command line?
>
> How about admitting that the solutions based around makefiles can end up
> more elaborate than necessary, and more fragile.
>
>>
>>> You've championed what I consider to be a poor tool for building open
>>> source software. You're championing complexity.
>>
>> I am not championing anything. I use it. I like it. It has always
>> worked to build the software I've needed it to build. You found open
>> source software that does not build on Windows using make.
>
> But why SHOULDN'T it build on Windows? What's the difference between a C
> compiler on Windows and on Linux? Isn't C supposed to be portable?

C supports portable programming. Building C programs is not required to
be portable according to the language standard. Right at the outset,
in section "1 Scope", that stuff is declared out of scope and so
not part of the language:

it is written (I'm quoting the C99 version of the text):

This International Standard does not specify

— the mechanism by which C programs are transformed for use by a
data-processing system;
— the mechanism by which C programs are invoked for use by a
data-processing system;
— the mechanism by which input data are transformed for use by a C program;
— the mechanism by which output data are transformed after being
produced by a C program;
— the size or complexity of a program and its data that will exceed the
capacity of any specific data-processing system or the capacity of a
particular processor;
— all minimal requirements of a data-processing system that is capable
of supporting a conforming implementation.

C came from Unix. On Unix, people were using makefiles and a program
called "cc" with -c and -o options, and an "a.out" default.

Those things were not specified as part of C. People took C into other
systems, and had a different take on the "para-programming" aspect;
what the C compiler looks like, how it is called, and what to do about
incremental builds.

When C standardization came along, that was not considered part of the
language. There were two working groups: one standardizing the language,
and one working on a Unix standard. The people working on the Unix
standard *did* consider that build stuff to be in their domain.

C and Unix were born together. Both are standardized, but in
standardization, they forked. We have ISO C 9899 for C, and IEEE 1003
"POSIX" for Unix.

Some programs take advantage of both standards. They use the C langauge
with the POSIX library and are built by POSIX tools like make.

> But what is it about compiling these 72 .c files under non-Unix, that
> makes it so hard? I can't just compile them as some .h files need to be
> created.

What's hard about non-Unix is that Unix is standard environment.
It has a standard: IEEE 1003 "POSIX".

Non-unix is nonstandard, and nonstandard is harder due to proliferating
the ways of doing things, and having inadequate/missing tooling.

POSIX is a language: it has the shell and utilities. Utilities like
sed, awk, and Make.

Systems which conform to POSIX can be targeted by programs in
that language, like makefiles containing shells script fragments that
use the utilities.

Then for all the systems that don't conform to POSIX, we have to use
their arbitrary languages for all the "para-programming".

> Anyway this can be chalked up under a project that I can't build despite
> all those makefiles. Why are these 15 C compilers all so different
> anyway, and how do they differ from Unix compilers? It's the same language!

C is the same language, but non-Unix is not the same language as Unix.

Isn't it obvious?

> Gzlib. A compression utility.
>
> This only had makefile.am/.in, and ./configure. Another project which
> you'd think, as it reads and writes files, would hardly be OS-specific.

Gzip comes from the GNU project.

The boss of the GNU project was/is a keen Lisp programmer. His ideal
system would have been some kind of Lisp machine. This preference
is well documented in his own writings.

However, more than that, he wanted the world to be liberated from
proprietary software. He saw that Unix systems were more popular than
Lisp machines, and so he decided that his GNU project would replace the
proprietary software in Unix. That would be the target. (And there
would be Lisp, as an application, rather than as the foundational basis
for the entire system.)

Thus, programs like Gzip, GNU Bash, GNU Make and GNU C were explicitly
geared toward the Unix world. They exactly copied Unix conventions,
where applicable, albeit with their own extensions.

They built using the Unix ways, because that suited the GNU project; all
the utilities used for building a GNU program on a proprietary Unix like
SunOS were being replaced by the GNU project itself: a system loaded
with GNU utilities instead of proprietary Unix utilities could also
build the GNU programs.

Users were able to choose how much GNU stuff to use; it was designed to
blend in. You could choose to use GNU Bash instead of the shell that
came with your Unix, but otherwise use its utilities. Or you could
choose just to have GNU grep, and nothing else. Or just the GNU
compiler, but nothing else from GNU.

GNU stands for "GNU is not Unix" but of course it's a clone of Unix.

GNU set the tone for subsequent FOSS. Linus Torvalds started a project
which gave GNU a practical kernel to run over to form a complete
system and the rest is recent history.

That sytem spawned a hotbed of FOSS activity, and most of that
activity has been Unix-flavored.

Non-Unix systems are just annoying outliers. For various reasons, people
are required to work with them, and want to bring some of that FOSS, so
they get up to their knees and elbows in shit and make it work.

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

On Mon, 21 Aug 2023 02:52:44 -0000 (UTC), Kaz Kylheku
<864-117-4973@kylheku.com> wrote in <20230820191756.541@kylheku.com>:

> On 2023-08-21, Bart <bc@freeuk.com> wrote:
>> On 21/08/2023 00:51, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 20/08/2023 20:48, Ben Bacarisse wrote:
>>>>> bart c <bart4858@gmail.com> writes:
>>>>
>>>>> But for some reason not quite attractive enough. Why? That's not
>>>>> rhetorical. I really would like to know why you spend this amount
>>>>> of time on something you don't like and don't want to use. It's
>>>>> really odd.
>>>>
>>>> I'd replied at length to some of your other points, until I came to
>>>> this.
>>>
>>> That's a good idea. Often there is only one key point in contention.
>>>
>>>> So why is it hard to move on? Because it means you have all won.
>>>
>>> Ah, I see. What does winning look like to you? Stopping me from
>>> using make? Making me use your software? Are you prepared to
>>> document it and support it? Or is winning to you just getting people
>>> to say they agree with you? Do you want me to say that make is crap
>>> and gcc shouldn't assemble and compile C on the same command line?
>>
>> How about admitting that the solutions based around makefiles can end
>> up more elaborate than necessary, and more fragile.
>>
>>
>>>> You've championed what I consider to be a poor tool for building open
>>>> source software. You're championing complexity.
>>>
>>> I am not championing anything. I use it. I like it. It has always
>>> worked to build the software I've needed it to build. You found open
>>> source software that does not build on Windows using make.
>>
>> But why SHOULDN'T it build on Windows? What's the difference between a
>> C compiler on Windows and on Linux? Isn't C supposed to be portable?
>
> C supports portable programming. Building C programs is not required to
> be portable according to the language standard. Right at the outset,
> in section "1 Scope", that stuff is declared out of scope and so not
> part of the language:
>
> it is written (I'm quoting the C99 version of the text):
>
> This International Standard does not specify
>
> — the mechanism by which C programs are transformed for use by a
> data-processing system;
> — the mechanism by which C programs are invoked for use by a
> data-processing system;
> — the mechanism by which input data are transformed for use by a C
> program;
> — the mechanism by which output data are transformed after being
> produced by a C program;
> — the size or complexity of a program and its data that will exceed
> the
> capacity of any specific data-processing system or the capacity of a
> particular processor;
> — all minimal requirements of a data-processing system that is capable
> of supporting a conforming implementation.
>
> C came from Unix. On Unix, people were using makefiles and a program
> called "cc" with -c and -o options, and an "a.out" default.
>
> Those things were not specified as part of C. People took C into other
> systems, and had a different take on the "para-programming" aspect; what
> the C compiler looks like, how it is called, and what to do about
> incremental builds.
>
> When C standardization came along, that was not considered part of the
> language. There were two working groups: one standardizing the language,
> and one working on a Unix standard. The people working on the Unix
> standard *did* consider that build stuff to be in their domain.
>
> C and Unix were born together. Both are standardized, but in
> standardization, they forked. We have ISO C 9899 for C, and IEEE 1003
> "POSIX" for Unix.
>
> Some programs take advantage of both standards. They use the C langauge
> with the POSIX library and are built by POSIX tools like make.
>
>> But what is it about compiling these 72 .c files under non-Unix, that
>> makes it so hard? I can't just compile them as some .h files need to be
>> created.
>
> What's hard about non-Unix is that Unix is standard environment.
> It has a standard: IEEE 1003 "POSIX".
>
> Non-unix is nonstandard, and nonstandard is harder due to proliferating
> the ways of doing things, and having inadequate/missing tooling.
>
> POSIX is a language: it has the shell and utilities. Utilities like sed,
> awk, and Make.
>
> Systems which conform to POSIX can be targeted by programs in that
> language, like makefiles containing shells script fragments that use the
> utilities.
>
> Then for all the systems that don't conform to POSIX, we have to use
> their arbitrary languages for all the "para-programming".
>
>> Anyway this can be chalked up under a project that I can't build
>> despite all those makefiles. Why are these 15 C compilers all so
>> different anyway, and how do they differ from Unix compilers? It's the
>> same language!
>
> C is the same language, but non-Unix is not the same language as Unix.
>
> Isn't it obvious?
>
>> Gzlib. A compression utility.
>>
>> This only had makefile.am/.in, and ./configure. Another project which
>> you'd think, as it reads and writes files, would hardly be OS-specific.
>
> Gzip comes from the GNU project.
>
> The boss of the GNU project was/is a keen Lisp programmer. His ideal
> system would have been some kind of Lisp machine. This preference is
> well documented in his own writings.
>
> However, more than that, he wanted the world to be liberated from
> proprietary software. He saw that Unix systems were more popular than
> Lisp machines, and so he decided that his GNU project would replace the
> proprietary software in Unix. That would be the target. (And there
> would be Lisp, as an application, rather than as the foundational basis
> for the entire system.)
>
> Thus, programs like Gzip, GNU Bash, GNU Make and GNU C were explicitly
> geared toward the Unix world. They exactly copied Unix conventions,
> where applicable, albeit with their own extensions.
>
> They built using the Unix ways, because that suited the GNU project; all
> the utilities used for building a GNU program on a proprietary Unix like
> SunOS were being replaced by the GNU project itself: a system loaded
> with GNU utilities instead of proprietary Unix utilities could also
> build the GNU programs.
>
> Users were able to choose how much GNU stuff to use; it was designed to
> blend in. You could choose to use GNU Bash instead of the shell that
> came with your Unix, but otherwise use its utilities. Or you could
> choose just to have GNU grep, and nothing else. Or just the GNU
> compiler, but nothing else from GNU.
>
> GNU stands for "GNU is not Unix" but of course it's a clone of Unix.
>
> GNU set the tone for subsequent FOSS. Linus Torvalds started a project
> which gave GNU a practical kernel to run over to form a complete system
> and the rest is recent history.
>
> That sytem spawned a hotbed of FOSS activity, and most of that activity
> has been Unix-flavored.
>
> Non-Unix systems are just annoying outliers. For various reasons, people
> are required to work with them, and want to bring some of that FOSS, so
> they get up to their knees and elbows in shit and make it work.

Thank you for this excellent post, and thank you for the time it took
you to write it.

--
-v

On 2023-08-21, vallor <vallor@cultnix.org> wrote:
> On Mon, 21 Aug 2023 02:52:44 -0000 (UTC), Kaz Kylheku
>
> Thank you for this excellent post, and thank you for the time it took
> you to write it.

You're welcome.

I glossed over some important things: one of which being how hard it had
been to write programs that only work on multiple Unixes and nothing
else.

In the 1980s, Unix was a zoo due to everyone licensing the code and
rolling their own. They couldn't agree on how to copy memory around: BSD
had bcopy (which some goofballs still use today in new program) AT&T
introduced memcpy. Differences in TTY handling, job control, shared
memory, file locking, yadda yadda, you name it. Different hader files.

Then the environment: broken shells and whatnot, so you resort to
crap like if test foo$x = $x ; ... then

The GNU project had its hands full just with the chosen mission:
to make replacement equivalents of Unix programs, and get them
to build everywhere.

GNU programs went with the approach of using scripts to detect
features of the environment and then to focus on making up for
differences or lack of individual features.

They did some things that are not so great in hindsight, like a
monstrous configuraton system based on using M4 as a compiler that
generates a shell script, which then detects features and generates
makefile fragments and header files. That continues to be used even
though there is a lot less of a reason for it.

Today, the situation is a lot better, with much improved consistency
among systems due to standardization (and also market forces that
wiped out "weird" systems leaving fewer players).

Still, even today, if you write some nontrivial program and get it
working on a few Linux distros, Cygwin, and MacOS, that's no guarantee
it will build on, say, Solaris, and getting it to build there is
no guarantee it will work on AIX, and so on. There are still
little problems you run into.

Even just minor things. Like that one one system, if you include a
certain POSIX header file, it also includes another one that you happen
to need (but didn't include). On antoher system, that other one is not
included for you by the first header, so the program breaks.

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

On 21/08/2023 03:13, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

> Yes, why? We should take an example and look at it in detail, but you
> just keep moving on. Portable C is very hard to write (100% portable
> that is). If you crack that, the makefile is irrelevant. So is any
> configure script. Just compile the C.

I can't just compile the C because the info I need is hidden in the
makefile! Sometimes the makefile doesn't exist and the now even more
indirect instructions are inside a bash script, of which 99% is
irrelevant noise.

It is very frustrating.

> Unfortunately, Windows users expect *.txt to be expanded by the program
> and Unix users don't. Unix users expect -flags and Windows users expect
> /flags.

See my last remarks below. People will know how to invoke their own
compilers (unless they /only/ know how to type 'make'!). This is a
non-issue.

> Unix users will expect a configuration called .progrc created
> in the user's home directory. I don't know what Windows users expect
> for that,

I don't expect anything, as I've never heard of it.

There will obviously be some differences between Windows and Linux; eg.
one uses LoadLibrary, the other dlopen. This is not the problem. A
program that works on either will have sorted that. Maybe one module is
different between the two.

>> Libjpeg library. This is an old one from 1998. There are 15 makefile.xxx
>> files for multiple, mostly obsolete compilers. The docs for non-Unix look
>> horrendous; I will not bother.
>
> Post the link so I can at least see what you are talking about if this
> is the example you want me to examine. I think I know the library you
> mean, but I don't know the exact source you are looking at.

Start here: https://libjpeg.sourceforge.net/

(The configure file needed /bin/sh changed to /bin/bash)

>> Gzlib. A compression utility.
>
> Post the link if this is the one you want to look at in depth.

I think it was 'gzip' not gzlib. I used second from the last link here:
https://ftp.nluug.nl/pub/gnu/gzip/.

I think there might be more than 8Kloc of C code since there are
subfolders, although they don't look specific to this utility. But I
have literally no idea what modules comprise the product.

Here the generated makefile is 2600 lines of gorgeous nonsense. You'd
better hope it works or there's no chance.

>> I've suggested easy ways of building C programs such as the ones in my
>> example. Forgetting 'make' would be a first step (I suspect makefiles are
>> IDE-generated some of the time).
>
> Your solution is to write portable C. Is that it?

A lot of stuff is already portable since I can build it given the basic
build info. If people want to use open() and not fopen(), that's up to
them, but then their product is likely not cross-platform.

>> Here's one from the past: I wanted to build Algol68 Genie (A68G).
>
> Another one! Can we stick to one example?

My contention is that C projects with makefiles are generally
troublesome on Windows, which is why I always look at them askance.

The 4-5 examples based around my OP weren't enough to convince anybody.
Not even me. Enough gaslighting has been going on that I'm not sure
myself. I need more examples of projects with makefiles that build
effortlessly under Windows by simply following instructions.

But they're still rare!

>> Here I managed to isolate the 72Kloc of .c files. Compiling them with bcc
>> took around one second, and I got a working a68g.exe file.
>
> Bug free, or just working?

It wasn't bug-free with bcc, but I could run some A68 programs. Maybe
gcc could have been applied, I can't remember.

>> Now, why couldn't the docs just say that in the first place! Just submit
>> this list of C files to the nearest C compiler.
>
> If this is the example you want to look at in depth? I can't answer

It is really very simple. The basic info needed to build a program from
C modules is just a list of those modules and where they are located.

If there's anything extra, then that can be explained. This can be put
into a Readme or Install or Build text file.

By all means provide a makefile. But armed with the basic information,
people can also devise their own solutions, or fall back to that if
there is a problem. Or if there is a failure to build, they can more
easily pinpoint where.

makefile/configure solutions tend to be highly opaque, not allowing for
failure and not allowing for debugging.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-08-21, vallor <vallor@cultnix.org> wrote:
>> On Mon, 21 Aug 2023 02:52:44 -0000 (UTC), Kaz Kylheku
>>
>> Thank you for this excellent post, and thank you for the time it took
>> you to write it.
>
> You're welcome.
>
> I glossed over some important things: one of which being how hard it had
> been to write programs that only work on multiple Unixes and nothing
> else.
>
> In the 1980s, Unix was a zoo due to everyone licensing the code and
> rolling their own.

To make matters worse, C was a zoo then too. Some compilers had void
and some did not. Most had unsigned and long but not all had structure
assignment and parameter passing. Some had function prototype syntax
and some did not. And then there were extensions galore. For a long
time you could not write any significant Windows software without near
and far pointers.

> They couldn't agree on how to copy memory around: BSD
> had bcopy

Yes. In K&R1 "the C library" was essentially the I/O function,
character testing, a couple of string functions and calloc (no malloc).
The only standard include file was stdio.h because, with implicit int
and without prototypes, what's point in declaring "strlen();"? So when
that changed a few years latter there was the fun of finding out whether
to include "strings.h" or "string.h"; "malloc.h", "memory.h" or
"stdlib.h".

This was the legacy that spawned autoconf and all that malarkey. As you
say, much of it is redundant now, but if it still works (and I find
dozens of configure scripts work correctly to this day) there is little
incentive to revise the code and get rid of them.

--
Ben.

On 21/08/2023 11:09, Bart wrote:
> On 21/08/2023 03:13, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>> Yes, why?  We should take an example and look at it in detail, but you
>> just keep moving on.  Portable C is very hard to write (100% portable
>> that is).  If you crack that, the makefile is irrelevant.  So is any
>> configure script.  Just compile the C.
>
> I can't just compile the C because the info I need is hidden in the
> makefile! Sometimes the makefile doesn't exist and the now even more
> indirect instructions are inside a bash script, of which 99% is
> irrelevant noise.
>
> It is very frustrating.
>
>> Unfortunately, Windows users expect *.txt to be expanded by the program
>> and Unix users don't.  Unix users expect -flags and Windows users expect
>> /flags.
>
> See my last remarks below. People will know how to invoke their own
> compilers (unless they /only/ know how to type 'make'!). This is a
> non-issue.
>
>>  Unix users will expect a configuration called .progrc created
>> in the user's home directory.  I don't know what Windows users expect
>> for that,
>
> I don't expect anything, as I've never heard of it.
>
> There will obviously be some differences between Windows and Linux; eg.
> one uses LoadLibrary, the other dlopen. This is not the problem. A
> program that works on either will have sorted that. Maybe one module is
> different between the two.
>
>>> Libjpeg library. This is an old one from 1998. There are 15 makefile.xxx
>>> files for multiple, mostly obsolete compilers. The docs for non-Unix
>>> look
>>> horrendous; I will not bother.
>>
>> Post the link so I can at least see what you are talking about if this
>> is the example you want me to examine.  I think I know the library you
>> mean, but I don't know the exact source you are looking at.
>
> Start here: https://libjpeg.sourceforge.net/
>
> (The configure file needed /bin/sh changed to /bin/bash)

That is from 1998.

Better is http://ijg.org/, then download jpegsrc.v9e.tar.gz (or
jpegsr9e.zip)

Or, jpeg-turbo:
git clone https://github.com/libjpeg-turbo/libjpeg-turbo.git

On 20/08/2023 18:25, bart c wrote:
> On Sunday, 20 August 2023 at 15:15:45 UTC+1, David Brown wrote:
>> On 20/08/2023 15:05, bart c wrote:
>>> On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote:
>>>> On 20/08/2023 03:13, bart c wrote:
>>>>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson
>>>>> wrote:
>>>>>> sc...@slp53.sl.home (Scott Lurndal) writes:
>>>>>>> bart c <bart...@gmail.com> writes:
>>>>>> [...]
>>>>>>>> So how do you directly invoke the actual C compiler?
>>>>>>>
>>>>>>> As if you don't already know.
>>>>>>>
>>>>>>> $ gcc -o a.o a.c
>>>>>> That creates an executable named "a.o". Bad idea.
>>>>>>> or
>>>>>>>
>>>>>>> $ gcc -o a a.c
>>>>>> That invokes the compiler and the linker.
>>>>>>
>>>>>> To invoke just the compiler:
>>>>>>
>>>>>> gcc -c a.c
>>>>>>
>>>>>> which creates an object file named "a.o". If for some odd
>>>>>> reason you want the object file to have a different name:
>>>>>>
>>>>>> gcc -c a.c -o foo.o
>>>>>>
>>>>>> Giving an object file a name not ending in ".o" is almost
>>>>>> certainly a bad idea. (That's for Unix-like systems; other
>>>>>> systems might have a different convention like ".obj".)
>>>>>
>>>>> Also, none of these /directly/ invoke the compiler. Using
>>>>> your suggestion, gcc uses an invocation like this, on
>>>>> Windows:
>>>>>
>>>>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe
>>>>> -quiet -v -iprefix
>>>>> C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT
>>>>> hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64
>>>>> -auxbase hello -version -o
>>>>> C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s
>>>>>
>>>>> It doesn't look very user friendly.
>>>> It isn't user friendly - nor is it intended to be. It is
>>>> intended that you use "gcc" (or "g++", "gfortran", or other
>>>> drivers that are convenient for other gcc languages) as the
>>>> driver program that will then invoke "cc1" with whatever
>>>> options are needed. The options and interface for "cc1" are not
>>>> considered user documentation - they are internal, might not be
>>>> complete, and may change wildly between versions of gcc. It is
>>>> the options for "gcc" that are documented for user usage.
>>>
>>> How about 'ld'; is that supposed to be directly usable?
>> "ld" is not part of gcc. It is part of an independent project,
>> binutils, that is often used alongside gcc. (You know this, of
>> course, and only feign ignorance.)
>
> Why 'of course'? Is gcc the only C implementation on the planet?

The "of course" is because you know that gcc is a compiler (or multiple
compilers), with the actual "gcc" executable being a driver program.
You know the compiler does not include the C standard library, OS
headers, an assembler or a linker. You know that "as" and "ld" are
commonly used with gcc, and are part of the binutils project, not part
of the GCC project. You know all this because it has been explained to
you, patiently, countless times. Any attempts to claim otherwise are
just trolling on your part - more feeble attempts to make it look like
there is a problem with gcc rather than a problem with you.

>
> The C compilers I've used most often are complete, self-contained
> solutions. Mine doesn't even have or use a linker.

Then it is not a C compiler - it is a tool that includes a C compiler
amongst other things.

Self-contained toolchains can often be a useful solution, and it is
common to see compilers packaged alongside a library, assembler, linker,
librarian, and perhaps other tools such as a debugger and profiler. If
the packaging is for Windows, basic common utilities (such as make, a
decent shell, and common POSIX cli programs) are also common.

But as you know, many C compilers - gcc, clang, icc, and others - are
merely parts of C implementations. For most users, it really doesn't
matter as long as they have all the working parts - relatively few C
developers care about the details of their assembler or linker.

>
> Why is so much is made of the idiosyncratic way that C works on Unix
> systems? Who cares that 'as' is in compartment A, cc1 is in B, ld is
> in C, the standard headers is in D1 and may D2, the runtime is E, gcc
> itself is F, and 'make' is, what, G? Just build the effing program!

The people developing the tools care.

I agree that most users - C programmers in this case - often don't care.
They usually get all the parts from the same source - "apt-get
install", or download mingw64, or get a cross-compiler toolchain from a
microcontroller manufacturer's website.

However, if you want to mix and match parts, as you seem to do, it helps
to know what the parts are and where they come from. (And if you didn't
mean to mix and match, then it helps to know what you did wrong.)

And you specifically asked about "ld", so I answered your question.
Shooting the messenger and getting in a fluster just because your little
tool combines a C compiler and linker in one program is not particularly
helpful.

>
> When I install gcc on Windows, I really, really don't care how it's
> organised or who is responsible for what. It should take source code
> at one end, and output binaries at the other.
>

Oh, but you /do/ care. You care a great deal - you care that it
/fails/, no matter how hard you have to work in order to make that happen.

On Monday, 21 August 2023 at 13:43:39 UTC+1, David Brown wrote:
> On 20/08/2023 18:25, bart c wrote:
> > On Sunday, 20 August 2023 at 15:15:45 UTC+1, David Brown wrote:
> >> On 20/08/2023 15:05, bart c wrote:
> >>> On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote:
> >>>> On 20/08/2023 03:13, bart c wrote:
> >>>>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson
> >>>>> wrote:
> >>>>>> sc...@slp53.sl.home (Scott Lurndal) writes:
> >>>>>>> bart c <bart...@gmail.com> writes:
> >>>>>> [...]
> >>>>>>>> So how do you directly invoke the actual C compiler?
> >>>>>>>
> >>>>>>> As if you don't already know.
> >>>>>>>
> >>>>>>> $ gcc -o a.o a.c
> >>>>>> That creates an executable named "a.o". Bad idea.
> >>>>>>> or
> >>>>>>>
> >>>>>>> $ gcc -o a a.c
> >>>>>> That invokes the compiler and the linker.
> >>>>>>
> >>>>>> To invoke just the compiler:
> >>>>>>
> >>>>>> gcc -c a.c
> >>>>>>
> >>>>>> which creates an object file named "a.o". If for some odd
> >>>>>> reason you want the object file to have a different name:
> >>>>>>
> >>>>>> gcc -c a.c -o foo.o
> >>>>>>
> >>>>>> Giving an object file a name not ending in ".o" is almost
> >>>>>> certainly a bad idea. (That's for Unix-like systems; other
> >>>>>> systems might have a different convention like ".obj".)
> >>>>>
> >>>>> Also, none of these /directly/ invoke the compiler. Using
> >>>>> your suggestion, gcc uses an invocation like this, on
> >>>>> Windows:
> >>>>>
> >>>>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe
> >>>>> -quiet -v -iprefix
> >>>>> C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT
> >>>>> hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64
> >>>>> -auxbase hello -version -o
> >>>>> C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s
> >>>>>
> >>>>> It doesn't look very user friendly.
> >>>> It isn't user friendly - nor is it intended to be. It is
> >>>> intended that you use "gcc" (or "g++", "gfortran", or other
> >>>> drivers that are convenient for other gcc languages) as the
> >>>> driver program that will then invoke "cc1" with whatever
> >>>> options are needed. The options and interface for "cc1" are not
> >>>> considered user documentation - they are internal, might not be
> >>>> complete, and may change wildly between versions of gcc. It is
> >>>> the options for "gcc" that are documented for user usage.
> >>>
> >>> How about 'ld'; is that supposed to be directly usable?
> >> "ld" is not part of gcc. It is part of an independent project,
> >> binutils, that is often used alongside gcc. (You know this, of
> >> course, and only feign ignorance.)
> >
> > Why 'of course'? Is gcc the only C implementation on the planet?
> The "of course" is because you know that gcc is a compiler (or multiple
> compilers), with the actual "gcc" executable being a driver program.
> You know the compiler does not include the C standard library, OS
> headers, an assembler or a linker. You know that "as" and "ld" are
> commonly used with gcc, and are part of the binutils project, not part
> of the GCC project. You know all this because it has been explained to
> you, patiently, countless times. Any attempts to claim otherwise are
> just trolling on your part - more feeble attempts to make it look like
> there is a problem with gcc rather than a problem with you.
> >
> > The C compilers I've used most often are complete, self-contained
> > solutions. Mine doesn't even have or use a linker.
> Then it is not a C compiler - it is a tool that includes a C compiler
> amongst other things.
>
A compiler translates from one computer language to another.
S a program which takes in C source and spits out Fortran would be a
Co to Fortran compiler. One that spits out object code, like gcc, is a C
to object code compiler. But one that spits out executable machine
code, like Bart's appears to do, would also be a C compiler.

Often of course C is a target language of compilers. It's very common
to devise a high level language and then write a whizzylang to C compiler
for it. You then leverage C's popularity to make whizzylang run almost
anywhere.

On 21/08/2023 13:12, Richard Harnden wrote:
> On 21/08/2023 11:09, Bart wrote:

>> Start here: https://libjpeg.sourceforge.net/
>>
>> (The configure file needed /bin/sh changed to /bin/bash)
>
>
> Or, jpeg-turbo:
> git clone https://github.com/libjpeg-turbo/libjpeg-turbo.git

That last one uses CMake.

Among the highly varied build instructions, the ones for MingW are:

cd {build_directory}
cmake -G"MSYS Makefiles" [additional CMake flags] {source_directory}
make

I experimented with various incantations of that middle line (I
understand that [] means optional, and {} is a placeholder for an actual
path), but got nowhere.

> That is from 1998.
>
> Better is http://ijg.org/, then download jpegsrc.v9e.tar.gz (or
> jpegsr9e.zip)

At first this looks very similar to the 1998 version. But in the INSTALL
file, there is something magical:

Configuring the software by hand
--------------------------------

First, generate a jconfig.h file. If you are moderately familiar with C,
the comments in jconfig.txt should be enough information to do this; just
copy jconfig.txt to jconfig.h and edit it appropriately. Otherwise,
you may...

I copied jconfig.txt to jconfig.h. Now I need a list of files. It
suggests using makefile.ansi for the makefile, which I will try first.

I did that, and 'make' now finally works.

The difference here is a project explains things in English and shows
how to get around the need for things like 'configure'.

jconfig.h, if comments are stripped, is 38 lines. I didn't need to
change anything.

The build process creates 5 utility programs from 73 .c files. What's
still missing is a list of the modules for each program. Without that, I
had to rely on the makefile working. This time, it did.

The build process to build from scratch could be summarised in a few
lines. If I capture the output of make, then the summary involves these
files:

ar rc libjpeg.a jcapimin.o jcapistd.o jcarith.o jctrans.o jcparam.o
jdatadst.o jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o
jccoefct.o jccolor.o jcsample.o jchuff.o jcdctmgr.o jfdctfst.o
jfdctflt.o jfdctint.o jdapimin.o jdapistd.o jdarith.o jdtrans.o
jdatasrc.o jdmaster.o jdinput.o jdmarker.o jdhuff.o jdmainct.o
jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o jidctflt.o jidctint.o
jdsample.o jdcolor.o jquant1.o jquant2.o jdmerge.o jaricom.o jcomapi.o
jutils.o jerror.o jmemmgr.o jmemnobs.o
cc -o djpeg djpeg.o wrppm.o wrgif.o wrtarga.o wrrle.o wrbmp.o
rdcolmap.o cdjpeg.o libjpeg.a
cc -o jpegtran jpegtran.o rdswitch.o cdjpeg.o transupp.o libjpeg.a
cc -o cjpeg cjpeg.o rdppm.o rdgif.o rdtarga.o rdrle.o rdbmp.o
rdswitch.o cdjpeg.o libjpeg.a
cc -o rdjpgcom rdjpgcom.o
cc -o wrjpgcom wrjpgcom.o

For 'cc', if I change .o to .c, I could probably build directly from
sources.

I didn't expect that libjpeg.a file and I'm not familiar with that. But
I expect that where libjpeg.a is used, I can substitute the list of .c
files that comprise it.

I will try that experiment first with the existing .o files like this:

gcc -o djpeg djpeg.o wrppm.o wrgif.o wrtarga.o wrrle.o wrbmp.o
rdcolmap.o cdjpeg.o jcapimin.o jcapistd.o jcarith.o jctrans.o jcparam.o
jdatadst.o jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o
jccoefct.o jccolor.o jcsample.o jchuff.o jcdctmgr.o jfdctfst.o
jfdctflt.o jfdctint.o jdapimin.o jdapistd.o jdarith.o jdtrans.o
jdatasrc.o jdmaster.o jdinput.o jdmarker.o jdhuff.o jdmainct.o
jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o jidctflt.o jidctint.o
jdsample.o jdcolor.o jquant1.o jquant2.o jdmerge.o jaricom.o jcomapi.o
jutils.o jerror.o jmemmgr.o jmemnobs.o
gcc -o jpegtran jpegtran.o rdswitch.o cdjpeg.o transupp.o jcapimin.o
jcapistd.o jcarith.o jctrans.o jcparam.o jdatadst.o jcinit.o jcmaster.o
jcmarker.o jcmainct.o jcprepct.o jccoefct.o jccolor.o jcsample.o
jchuff.o jcdctmgr.o jfdctfst.o jfdctflt.o jfdctint.o jdapimin.o
jdapistd.o jdarith.o jdtrans.o jdatasrc.o jdmaster.o jdinput.o
jdmarker.o jdhuff.o jdmainct.o jdcoefct.o jdpostct.o jddctmgr.o
jidctfst.o jidctflt.o jidctint.o jdsample.o jdcolor.o jquant1.o
jquant2.o jdmerge.o jaricom.o jcomapi.o jutils.o jerror.o jmemmgr.o
jmemnobs.o
gcc -o cjpeg cjpeg.o rdppm.o rdgif.o rdtarga.o rdrle.o rdbmp.o
rdswitch.o cdjpeg.o jcapimin.o jcapistd.o jcarith.o jctrans.o jcparam.o
jdatadst.o jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o
jccoefct.o jccolor.o jcsample.o jchuff.o jcdctmgr.o jfdctfst.o
jfdctflt.o jfdctint.o jdapimin.o jdapistd.o jdarith.o jdtrans.o
jdatasrc.o jdmaster.o jdinput.o jdmarker.o jdhuff.o jdmainct.o
jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o jidctflt.o jidctint.o
jdsample.o jdcolor.o jquant1.o jquant2.o jdmerge.o jaricom.o jcomapi.o
jutils.o jerror.o jmemmgr.o jmemnobs.o
gcc -o rdjpgcom rdjpgcom.o
gcc -o wrjpgcom wrjpgcom.o

That worked. Now I replace those .o by .c, delete all .o and .exe files,
and try again. It takes a bit longer, but still works!

So the minimal need to build this project on Windows and mingws is a
6-line script in /any/ language (like above but with .c, and using -s),
and a 38-line jconfig.h file.

The actual makefile is 200 lines (times 15) plus 16000 lines of configure.

Of course, I needed a working makefile to extract this information. It
would be nice to have those six lines as a default or fall-back method.

On 21/08/2023 13:43, David Brown wrote:
> On 20/08/2023 18:25, bart c wrote:

>> Why 'of course'?  Is gcc the only C implementation on the planet?
>
> The "of course" is because you know that gcc is a compiler (or multiple
> compilers), with the actual "gcc" executable being a driver program.

Isn't that part supposed to be transparent? Somebody could rewrite gcc
as an all-in-one program (or rename tcc.exe to gcc.exe).

> You
> know the compiler does not include the C standard library, OS headers,
> an assembler or a linker.

I once used Clang for 18 months before I realised it was using gcc's
headers and linker. Then it switch to piggybacking onto MS tools, even
though it's quite a hefty app already. Since then it has rarely worked.

  You know that "as" and "ld" are commonly used
> with gcc, and are part of the binutils project, not part of the GCC
> project.  You know all this because it has been explained to you,
> patiently, countless times.  Any attempts to claim otherwise are just
> trolling on your part - more feeble attempts to make it look like there
> is a problem with gcc rather than a problem with you.
>
>>
>> The C compilers I've used most often are complete, self-contained
>> solutions. Mine doesn't even have or use a linker.
>
> Then it is not a C compiler - it is a tool that includes a C compiler
> amongst other things.

So what /is/ a C compiler? What exactly does it comprise? What, exactly,
does it do?

Does it really not include stdio.h? Where would you even get stdio.h, or
windows.h, if supplied separately?