Started a new thread as the last one went somewhat off-topic regarding
'CPP tags'.

Everyone is getting tired of me mouthing off about Make and friends, and
I'm fed up of not being believed when I talk about the problems it
introduces.

I thought I'd try one more attempt at finding a small C project that
used make to see if it really was as bad as I was saying.

There is a small test file I have called piet.c, an esoteric language
interpreter. I couldn't find the original project but there is one
called npiet.c (https://www.bertnase.de/npiet/).

It contains these files:

c:\xxx\npiet-1.3f>dir
09/08/2020 12:41 5,574 ChangeLog
26/06/2004 16:53 461 config.h.in
09/08/2020 13:18 140,516 configure
05/08/2011 19:19 584 configure.in
06/06/2004 17:48 17,984 COPYING
09/08/2020 12:41 <DIR> examples
09/08/2020 12:17 <DIR> foo
06/06/2004 12:25 4,771 install-sh
09/08/2020 13:18 44 Makefile
04/12/2014 20:59 2,743 Makefile.in
05/08/2011 21:26 2,116 npiet-foogol.1
09/08/2020 13:18 98,071 npiet-foogol.c
19/11/2014 19:17 45,555 npiet-foogol.y
04/08/2011 21:14 4,446 npiet.1
09/08/2020 12:35 68,150 npiet.c
29/01/2005 19:29 17,801 npietedit
26/09/2004 21:53 1,064 npietedit.1
27/01/2014 17:24 1,436 README.npiet

There is a makefile (which only contains the message to run ./configure)
and a configure script.

If try and do make under Windows, it actually does some tests,
concluding that I don't have gcc, cc or cl installed, and fails on 'No C
Compiler'.

If I run this 4800-line script under WSL, it produces a 140-line
makefile. The makefile tries to build 3 programs, the main 'npiet', and
two more, but those have dependencies that will fail even under WSL.

Actually, 'npiet' is successfully created, but that fact is lost amongst
all the errors.

Now that I have a makefile, could it work under Windows for building
'npiet.exe'? Apparently not, because the makefile is Linux-specific.

So, under actual Windows, both 'make' and './configure' were useless.

But you will say, This is obviously for Linux, what did you expect?

===============================

Here I will reveal a secret: as soon as I saw that list of files, and
saw that make required configure, I tried this anyway:

c:\xxx\npiet-1.3f> mcc npiet
Compiling npiet.c to npiet.exe

It just worked! And it seems to run:

c:\xxx\npiet-1.3f> npiet examples\nfib.ppm
0
1
1
2
3
5
8
13
21
34
55
89
144
233
377
610
987

(The nfib.ppm file is a block of coloured pixels. You can see examples
at the link. I've no idea how it works; I just use these as test programs.)

Apparently it works on Windows just fine, no thanks to the Readme,
makefile and configure files.

===============================

So, I ask again, why this obsession that C developers have with make and
configure files? It's taken a simple, one-file program and made it
impossible to build on my favoured OS, if you were to follow the make route.

Actually, if I look inside npiet.c, it does explain how to build the
program with a bare compiler. This is also where I put build info when I
distribute C programs. To hell with make.

On 2024-01-14, bart <bc@freeuk.com> wrote:
> Started a new thread as the last one went somewhat off-topic regarding
> 'CPP tags'.
>
> Everyone is getting tired of me mouthing off about Make and friends, and
> I'm fed up of not being believed when I talk about the problems it
> introduces.
>
> I thought I'd try one more attempt at finding a small C project that
> used make to see if it really was as bad as I was saying.
>
> There is a small test file I have called piet.c, an esoteric language
> interpreter. I couldn't find the original project but there is one
> called npiet.c (https://www.bertnase.de/npiet/).
>
> It contains these files:
>
> c:\xxx\npiet-1.3f>dir
> 09/08/2020 12:41 5,574 ChangeLog
> 26/06/2004 16:53 461 config.h.in
> 09/08/2020 13:18 140,516 configure
> 05/08/2011 19:19 584 configure.in
> 06/06/2004 17:48 17,984 COPYING
> 09/08/2020 12:41 <DIR> examples
> 09/08/2020 12:17 <DIR> foo
> 06/06/2004 12:25 4,771 install-sh
> 09/08/2020 13:18 44 Makefile
> 04/12/2014 20:59 2,743 Makefile.in
> 05/08/2011 21:26 2,116 npiet-foogol.1
> 09/08/2020 13:18 98,071 npiet-foogol.c
> 19/11/2014 19:17 45,555 npiet-foogol.y
> 04/08/2011 21:14 4,446 npiet.1
> 09/08/2020 12:35 68,150 npiet.c
> 29/01/2005 19:29 17,801 npietedit
> 26/09/2004 21:53 1,064 npietedit.1
> 27/01/2014 17:24 1,436 README.npiet
>
> There is a makefile (which only contains the message to run ./configure)
> and a configure script.

That's almost a strawman. This isn't a pure Makefile project but one
that uses GNU Autotools, which is an abomination.

> Now that I have a makefile, could it work under Windows for building
> 'npiet.exe'? Apparently not, because the makefile is Linux-specific.

Yes; a build configuration generated by the Autoconf-generated
configure script is specific to a system; it is not a portable
artifact.

> So, under actual Windows, both 'make' and './configure' were useless.
>
> But you will say, This is obviously for Linux, what did you expect?

If a program is for Linux, it's completely pointless for it to be using
Autoconf.

Autoconf is intended for making programs portable among Unix variants:
things with a shell that can run the configure script, and that provide
the utilities they need.

(Using it for /that/ is separately a bad idea.)

Using Autoconf for such a small program is usually a sign that the
author doesn't understand builds, doesn't want to learn how to use make.
They see that a lot of open-source projects use Autoconf, and just
cribs that without any understanding.

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

On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:

> But you will say, This is obviously for Linux, what did you expect?

Because all the smart folk have given up battering their heads against the
brick wall that is open-source/cross-platform development on Windows.

On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>
>> But you will say, This is obviously for Linux, what did you expect?
>
> Because all the smart folk have given up battering their heads against the
> brick wall that is open-source/cross-platform development on Windows.

Did you look at the example project?

This was basically a one-file C program, that was actually portable
across both Windows and Linux.

The insistence on using make + auto-config made it more complicated to
build, and specific to Linux. Adding two extra programs in there which
have external dependencies, introduced a failure point even on Linux.

It's made a simple program that you compile trivially into a mini-disaster.

So, why are you turning this around and saying it is all Window's fault?

Sometimes you have to learn to keep things simple. Or do Linux people
introduce that complexity and those Linux dependencies on purpose, just
to ensure it won't build on Windows?

bart <bc@freeuk.com> writes:
>On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>
>>> But you will say, This is obviously for Linux, what did you expect?
>>
>> Because all the smart folk have given up battering their heads against the
>> brick wall that is open-source/cross-platform development on Windows.
>
>Did you look at the example project?

No.

>
>This was basically a one-file C program, that was actually portable
>across both Windows and Linux.

So why do you need make for that?

>
>The insistence on using make + auto-config made it more complicated to
>build, and specific to Linux. Adding two extra programs in there which
>have external dependencies, introduced a failure point even on Linux.

Nobody would do that for a one-line C program.

Yep, completely agree here. I use nothing but a single handwritten
makefile for the big projects i program and it's worked fine for me. The
problem has is not with make, but with autotools and the wonky standards
established by GNU and the FSF.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Of course, like many Unix tools, make has its own problems that were fixed
in Plan 9.

On Sun, 14 Jan 2024 19:40:46 +0000, bart <bc@freeuk.com> wrote in
<uo1dbu$img2$1@dont-email.me>:

> Started a new thread as the last one went somewhat off-topic regarding
> 'CPP tags'.
>
> Everyone is getting tired of me mouthing off about Make and friends, and
> I'm fed up of not being believed when I talk about the problems it
> introduces.
>
> I thought I'd try one more attempt at finding a small C project that
> used make to see if it really was as bad as I was saying.
>
> There is a small test file I have called piet.c, an esoteric language
> interpreter. I couldn't find the original project but there is one
> called npiet.c (https://www.bertnase.de/npiet/).
>
> It contains these files:
>
> c:\xxx\npiet-1.3f>dir 09/08/2020 12:41 5,574 ChangeLog
> 26/06/2004 16:53 461 config.h.in 09/08/2020 13:18
> 140,516 configure 05/08/2011 19:19 584
> configure.in 06/06/2004 17:48 17,984 COPYING 09/08/2020
> 12:41 <DIR> examples 09/08/2020 12:17 <DIR>
> foo 06/06/2004 12:25 4,771 install-sh 09/08/2020
> 13:18 44 Makefile 04/12/2014 20:59
> 2,743 Makefile.in 05/08/2011 21:26 2,116
> npiet-foogol.1 09/08/2020 13:18 98,071 npiet-foogol.c
> 19/11/2014 19:17 45,555 npiet-foogol.y 04/08/2011
> 21:14 4,446 npiet.1 09/08/2020 12:35 68,150
> npiet.c 29/01/2005 19:29 17,801 npietedit 26/09/2004
> 21:53 1,064 npietedit.1 27/01/2014 17:24
> 1,436 README.npiet
>
> There is a makefile (which only contains the message to run ./configure)
> and a configure script.
>
> If try and do make under Windows, it actually does some tests,
> concluding that I don't have gcc, cc or cl installed, and fails on 'No C
> Compiler'.
>
> If I run this 4800-line script under WSL, it produces a 140-line
> makefile. The makefile tries to build 3 programs, the main 'npiet', and
> two more, but those have dependencies that will fail even under WSL.
>
> Actually, 'npiet' is successfully created, but that fact is lost amongst
> all the errors.
>
> Now that I have a makefile, could it work under Windows for building
> 'npiet.exe'? Apparently not, because the makefile is Linux-specific.
>
> So, under actual Windows, both 'make' and './configure' were useless.
>
> But you will say, This is obviously for Linux, what did you expect?
>
> ===============================
>
> Here I will reveal a secret: as soon as I saw that list of files, and
> saw that make required configure, I tried this anyway:
>
> c:\xxx\npiet-1.3f> mcc npiet Compiling npiet.c to npiet.exe
>
> It just worked! And it seems to run:
>
> c:\xxx\npiet-1.3f> npiet examples\nfib.ppm 0
> 1
> 1
> 2
> 3
> 5
> 8
> 13 21 34 55 89 144 233 377 610 987
>
> (The nfib.ppm file is a block of coloured pixels. You can see examples
> at the link. I've no idea how it works; I just use these as test
> programs.)
>
> Apparently it works on Windows just fine, no thanks to the Readme,
> makefile and configure files.
>
> ===============================
>
> So, I ask again, why this obsession that C developers have with make and
> configure files? It's taken a simple, one-file program and made it
> impossible to build on my favoured OS, if you were to follow the make
> route.
>
> Actually, if I look inside npiet.c, it does explain how to build the
> program with a bare compiler. This is also where I put build info when I
> distribute C programs. To hell with make.

Take a look in your Makefile for other make rules. You
missed another couple of files in the directory, which appear
to be related: npiet-foogol.c and npiet-foogol.y.

The .y is for lex(1) and yacc(1), for which GNU
has flex and bison. What does your all-inclusive
C compiler do with .y files?

Also, if you don't know what it does, try running "man npiet.1" or
"man npiet-foogol.1" in your WSL instance -- the *.1 files are
the man pages.

Finally, it's possible the developer just wanted to try out
autoconf. Can't really know what they were thinking...

--
-v

On 1/15/2024 7:49 AM, Blue-Maned_Hawk wrote:
> Yep, completely agree here. I use nothing but a single handwritten
> makefile for the big projects i program and it's worked fine for me. The
> problem has is not with make, but with autotools and the wonky standards
> established by GNU and the FSF.
>

Agreed.

For most of my projects, 'make' works fine.
Provided one actually uses 'make' as it was intended to be used.
IOW: Not just as part of the "autotools" crap pile.

....

This is excluding the subset of programs that are so simple that
one-liner shell-scrips and similar become the more preferable option.

On 1/14/2024 4:27 PM, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>>
>>>> But you will say, This is obviously for Linux, what did you expect?
>>>
>>> Because all the smart folk have given up battering their heads against the
>>> brick wall that is open-source/cross-platform development on Windows.
>>
>> Did you look at the example project?
>
> No.
>
>>
>> This was basically a one-file C program, that was actually portable
>> across both Windows and Linux.
>
> So why do you need make for that?
>
>>
>> The insistence on using make + auto-config made it more complicated to
>> build, and specific to Linux. Adding two extra programs in there which
>> have external dependencies, introduced a failure point even on Linux.
>
> Nobody would do that for a one-line C program.
>

Errm, I think part of the problem is that some people *are* using
autotools for things that could have been built with a trivial one-liner
on the command-line.

It seems like the "cult of GNU" has seemingly convinced people that
autotools is preferable to both raw Makefiles, and building via
one-liner shell scripts and similar (nevermind if, with these options, a
person may need to modify or make their own version of the one-liner
shell script if their target differs from the existing shell scripts).

Well, also because apparently POSIX isn't good enough and a one-liner:
c89 -o myprogram myprogram.c -lm

Or, for a slightly more advanced program:
c89 -o myprogram myprogram.c -O3 -lm -lSDL -DUNIX -DUSE_SDL
Or similar... (nevermind if SDL is itself a pretty big dependency).

Isn't "sufficiently portable", yet a shell-script that depends on Bash
and m4 and Perl and similar is fine...

BGB <cr88192@gmail.com> writes:
>On 1/14/2024 4:27 PM, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>>>
>>>>> But you will say, This is obviously for Linux, what did you expect?
>>>>
>>>> Because all the smart folk have given up battering their heads against the
>>>> brick wall that is open-source/cross-platform development on Windows.
>>>
>>> Did you look at the example project?
>>
>> No.
>>
>>>
>>> This was basically a one-file C program, that was actually portable
>>> across both Windows and Linux.
>>
>> So why do you need make for that?
>>
>>>
>>> The insistence on using make + auto-config made it more complicated to
>>> build, and specific to Linux. Adding two extra programs in there which
>>> have external dependencies, introduced a failure point even on Linux.
>>
>> Nobody would do that for a one-line C program.
>>
>
>Errm, I think part of the problem is that some people *are* using
>autotools for things that could have been built with a trivial one-liner
>on the command-line.
>
>It seems like the "cult of GNU" has seemingly convinced people that
>autotools is preferable to both raw Makefiles

autotools were created to accomodate the wide variety of unix
and unix-like systems and even some non-unix systems - and they've
been sucessful at that by most measures.

Yes, it's arcane, and yes, in modern times, it is somewhat
less necessary (note that not all linux distributions have the
same versions of all packages, so even there, autotools are
useful).

But autotools have been used successfully to create the most
widely portable software available.

Using labels and generalizations like "cult of GNU" is the sign
that you are relying on emotion rather than logic.

In any case, this discussion has diverged sufficiently from the
C language that it is more appropriate to continue elsewhere.

On Mon, 15 Jan 2024 15:32:33 -0600, BGB wrote:

> Provided one actually uses 'make' as it was intended to be used.
> IOW: Not just as part of the "autotools" crap pile.

This is why Ninja exists: it assumes there will be a prior control file
generation stage, so it concentrates on executing a small set of
directives very efficiently.

On 1/15/2024 4:10 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 1/14/2024 4:27 PM, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>>>>
>>>>>> But you will say, This is obviously for Linux, what did you expect?
>>>>>
>>>>> Because all the smart folk have given up battering their heads against the
>>>>> brick wall that is open-source/cross-platform development on Windows.
>>>>
>>>> Did you look at the example project?
>>>
>>> No.
>>>
>>>>
>>>> This was basically a one-file C program, that was actually portable
>>>> across both Windows and Linux.
>>>
>>> So why do you need make for that?
>>>
>>>>
>>>> The insistence on using make + auto-config made it more complicated to
>>>> build, and specific to Linux. Adding two extra programs in there which
>>>> have external dependencies, introduced a failure point even on Linux.
>>>
>>> Nobody would do that for a one-line C program.
>>>
>>
>> Errm, I think part of the problem is that some people *are* using
>> autotools for things that could have been built with a trivial one-liner
>> on the command-line.
>>
>> It seems like the "cult of GNU" has seemingly convinced people that
>> autotools is preferable to both raw Makefiles
>
> autotools were created to accomodate the wide variety of unix
> and unix-like systems and even some non-unix systems - and they've
> been sucessful at that by most measures.
>
> Yes, it's arcane, and yes, in modern times, it is somewhat
> less necessary (note that not all linux distributions have the
> same versions of all packages, so even there, autotools are
> useful).
>
> But autotools have been used successfully to create the most
> widely portable software available.
>
> Using labels and generalizations like "cult of GNU" is the sign
> that you are relying on emotion rather than logic.
>

Curious conclusion, I mostly have a form of affective alexithymia, so
tend not to identify much with emotion in general (tending to see
emotional content more as patterns than as something to be experienced,
and may often miss on nuances in these areas).

However, I do suspect that the GNU does influence an undue level of
influence on public mindshare, in any case, and that some of the things
that are common in this space are counter-productive and anti-patterns.
This was more the point I was trying to make here.

> In any case, this discussion has diverged sufficiently from the
> C language that it is more appropriate to continue elsewhere.

Possibly.

I was gone from the topic for a while.
I guess in retrospect it may have been better to have not responded?...
Oh well, either way.

On 15/01/2024 21:24, vallor wrote:
> On Sun, 14 Jan 2024 19:40:46 +0000, bart <bc@freeuk.com> wrote in
> <uo1dbu$img2$1@dont-email.me>:
>
>> Started a new thread as the last one went somewhat off-topic regarding
>> 'CPP tags'.
>>
>> Everyone is getting tired of me mouthing off about Make and friends, and
>> I'm fed up of not being believed when I talk about the problems it
>> introduces.
>>
>> I thought I'd try one more attempt at finding a small C project that
>> used make to see if it really was as bad as I was saying.
>>
>> There is a small test file I have called piet.c, an esoteric language
>> interpreter. I couldn't find the original project but there is one
>> called npiet.c (https://www.bertnase.de/npiet/).
>>
>> It contains these files:
>>
>> c:\xxx\npiet-1.3f>dir 09/08/2020 12:41 5,574 ChangeLog
>> 26/06/2004 16:53 461 config.h.in 09/08/2020 13:18
>> 140,516 configure 05/08/2011 19:19 584
>> configure.in 06/06/2004 17:48 17,984 COPYING 09/08/2020
>> 12:41 <DIR> examples 09/08/2020 12:17 <DIR>
>> foo 06/06/2004 12:25 4,771 install-sh 09/08/2020
>> 13:18 44 Makefile 04/12/2014 20:59
>> 2,743 Makefile.in 05/08/2011 21:26 2,116
>> npiet-foogol.1 09/08/2020 13:18 98,071 npiet-foogol.c
>> 19/11/2014 19:17 45,555 npiet-foogol.y 04/08/2011
>> 21:14 4,446 npiet.1 09/08/2020 12:35 68,150
>> npiet.c 29/01/2005 19:29 17,801 npietedit 26/09/2004
>> 21:53 1,064 npietedit.1 27/01/2014 17:24
>> 1,436 README.npiet
>>
>> There is a makefile (which only contains the message to run ./configure)
>> and a configure script.
>>
>> If try and do make under Windows, it actually does some tests,
>> concluding that I don't have gcc, cc or cl installed, and fails on 'No C
>> Compiler'.
>>
>> If I run this 4800-line script under WSL, it produces a 140-line
>> makefile. The makefile tries to build 3 programs, the main 'npiet', and
>> two more, but those have dependencies that will fail even under WSL.
>>
>> Actually, 'npiet' is successfully created, but that fact is lost amongst
>> all the errors.
>>
>> Now that I have a makefile, could it work under Windows for building
>> 'npiet.exe'? Apparently not, because the makefile is Linux-specific.
>>
>> So, under actual Windows, both 'make' and './configure' were useless.
>>
>> But you will say, This is obviously for Linux, what did you expect?
>>
>> ===============================
>>
>> Here I will reveal a secret: as soon as I saw that list of files, and
>> saw that make required configure, I tried this anyway:
>>
>> c:\xxx\npiet-1.3f> mcc npiet Compiling npiet.c to npiet.exe
>>
>> It just worked! And it seems to run:
>>
>> c:\xxx\npiet-1.3f> npiet examples\nfib.ppm 0
>> 1
>> 1
>> 2
>> 3
>> 5
>> 8
>> 13 21 34 55 89 144 233 377 610 987
>>
>> (The nfib.ppm file is a block of coloured pixels. You can see examples
>> at the link. I've no idea how it works; I just use these as test
>> programs.)
>>
>> Apparently it works on Windows just fine, no thanks to the Readme,
>> makefile and configure files.
>>
>> ===============================
>>
>> So, I ask again, why this obsession that C developers have with make and
>> configure files? It's taken a simple, one-file program and made it
>> impossible to build on my favoured OS, if you were to follow the make
>> route.
>>
>> Actually, if I look inside npiet.c, it does explain how to build the
>> program with a bare compiler. This is also where I put build info when I
>> distribute C programs. To hell with make.
>
> Take a look in your Makefile for other make rules.

Note: I work on Windows. This stuff only works on systems like Linux.

The makefile doesn't even exist until I go through the configure step.

> You
> missed another couple of files in the directory, which appear
> to be related: npiet-foogol.c and npiet-foogol.y.
>
> The .y is for lex(1) and yacc(1), for which GNU
> has flex and bison. What does your all-inclusive
> C compiler do with .y files?

The project comprises 3 programs:

npiet.c This is a standalone program with no dependencies. It
is the one I want to run.

npietedit.c This needs TCL/TK, which I don't have on my WSL, and
I'm not interested in getting

npiet-foogol.c This one depends on a library called 'GD' which I
don't have.

This last one I believe is generated from the .y file. If I hide it, it
needs to generate it using 'bison'. I don't have that either.

The 'man' stuff is another Linux thing. (groff looks to turn .1 files
into PostScript. Manually using the invocation in the makefile, it
reports that 'html' is an invalid device).

So the configure/make stuff tries to do too much, with two many points
of failure. It means it will fail on two of those three programs because
of dependencies which it does not attempt to fix.

The error reporting however is chaotic: there is no summary of what
worked and what didn't.

So, it is attempting to build multiple applications with assorted
dependencies and processing help files or whatever.

My C compiler ... compiles .c files into a .exe or .dll file. It is
focused on that task.

It will not attempt to install anything. Or generate documentation. That
would be done at another level.

This is a clear demarcation between basic compilation and everything
else, that is missing from the make solution.

At the very least, the makefile could have used sub-makefiles to build
each of the three programs with its own dedicated script.

That could have allowed me to directly invoke the script for the main
npiet.c program, even on Windows.

Of course, any such files would actually need to exist, but they are
synthesised by the configure script, which only works on Unix-like systems.

> Also, if you don't know what it does, try running "man npiet.1" or
> "man npiet-foogol.1" in your WSL instance -- the *.1 files are
> the man pages.

> Finally, it's possible the developer just wanted to try out
> autoconf. Can't really know what they were thinking...
>

I've seen two many examples for this to be just a one-off.

I come across makefiles and the associated stuff in two main situations:

(1) There's a C library I want to build, but it's guarded by this and
mostly it doesn't workk. Even if works under WSL, I need EXE and DLL
files that work on real Windows.

(2) When I need test programs to try out my C compiler on. (Or maybe I
want to use my compiler for (1), but it's the same obstacle.)

Even if 'make' worked on Windows, my compiler is unconventional: it
doesn't use intermediate object files for example, nor a normal linker.
So I couldn't use 'make' with my compiler.

In most cases where I can finally get at the necessary information, it
turns that all that was needed was a LIST OF C SOURCE FILES. That's all.

In some cases however it is complicated by there being some essential
header, even if it only consists of 3 lines, being synthesised by the
build process. It is very frustrating.

On 1/15/2024 5:05 PM, Lawrence D'Oliveiro wrote:
> On Mon, 15 Jan 2024 15:32:33 -0600, BGB wrote:
>
>> Provided one actually uses 'make' as it was intended to be used.
>> IOW: Not just as part of the "autotools" crap pile.
>
> This is why Ninja exists: it assumes there will be a prior control file
> generation stage, so it concentrates on executing a small set of
> directives very efficiently.

Things like CMake and Ninja seemed to work effectively in the past from
what little I had used them...

Though, admittedly, hadn't really used them much in my own projects.

....

On 1/15/2024 3:48 PM, BGB wrote:
> On 1/15/2024 4:10 PM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 1/14/2024 4:27 PM, Scott Lurndal wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>>>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>>>>>
>>>>>>> But you will say, This is obviously for Linux, what did you expect?
>>>>>>
>>>>>> Because all the smart folk have given up battering their heads
>>>>>> against the
>>>>>> brick wall that is open-source/cross-platform development on Windows.
>>>>>
>>>>> Did you look at the example project?
>>>>
>>>> No.
>>>>
>>>>>
>>>>> This was basically a one-file C program, that was actually portable
>>>>> across both Windows and Linux.
>>>>
>>>> So why do you need make for that?
>>>>
>>>>>
>>>>> The insistence on using make + auto-config made it more complicated to
>>>>> build, and specific to Linux. Adding two extra programs in there which
>>>>> have external dependencies, introduced a failure point even on Linux.
>>>>
>>>> Nobody would do that for a one-line C program.
>>>>
>>>
>>> Errm, I think part of the problem is that some people *are* using
>>> autotools for things that could have been built with a trivial one-liner
>>> on the command-line.
>>>
>>> It seems like the "cult of GNU" has seemingly convinced people that
>>> autotools is preferable to both raw Makefiles
>>
>> autotools were created to accomodate the wide variety of unix
>> and unix-like systems and even some non-unix systems - and they've
>> been sucessful at that by  most measures.
>>
>> Yes, it's arcane, and yes, in modern times, it is somewhat
>> less necessary (note that not all linux distributions have the
>> same versions of all packages, so even there, autotools are
>> useful).
>>
>> But autotools have been used successfully to create the most
>> widely portable software available.
>>
>> Using labels and generalizations like "cult of GNU" is the sign
>> that you are relying on emotion rather than logic.
>>
>
> Curious conclusion, I mostly have a form of affective alexithymia, so
> tend not to identify much with emotion in general (tending to see
> emotional content more as patterns than as something to be experienced,
> and may often miss on nuances in these areas).

Some people think that the concept of love is programmed into something
called the "procreation algorithm pejorative"... ;^)

>
> However, I do suspect that the GNU does influence an undue level of
> influence on public mindshare, in any case, and that some of the things
> that are common in this space are counter-productive and anti-patterns.
> This was more the point I was trying to make here.
>
>
>> In any case, this discussion has diverged sufficiently from the
>> C language that it is more appropriate to continue elsewhere.
>
> Possibly.
>
> I was gone from the topic for a while.
> I guess in retrospect it may have been better to have not responded?...
> Oh well, either way.
>
>

On 1/15/2024 6:37 PM, Chris M. Thomasson wrote:
> On 1/15/2024 3:48 PM, BGB wrote:
>> On 1/15/2024 4:10 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 1/14/2024 4:27 PM, Scott Lurndal wrote:
>>>>> bart <bc@freeuk.com> writes:
>>>>>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>>>>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
[...]
>> Curious conclusion, I mostly have a form of affective alexithymia, so
>> tend not to identify much with emotion in general (tending to see
>> emotional content more as patterns than as something to be
>> experienced, and may often miss on nuances in these areas).
>
> Some people think that the concept of love is programmed into something
> called the "procreation algorithm pejorative"... ;^)
[...]
Keep in mind that she, Vermithrax Pejorative, the Dragon... Simply loves
her children... She does not really know why, she just does (follows
instructions, so to speak?). Strange concepts, indeed. Are we
programmed? Yikes! Will a honey bee sting something if it knows it will
die? For the greater good of the hive mind?

https://youtu.be/T2dGQwx6wJw

Humm...

On 1/15/2024 8:37 PM, Chris M. Thomasson wrote:
> On 1/15/2024 3:48 PM, BGB wrote:
>> On 1/15/2024 4:10 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 1/14/2024 4:27 PM, Scott Lurndal wrote:
>>>>> bart <bc@freeuk.com> writes:
>>>>>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>>>>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>>>>>>
>>>>>>>> But you will say, This is obviously for Linux, what did you expect?
>>>>>>>
>>>>>>> Because all the smart folk have given up battering their heads
>>>>>>> against the
>>>>>>> brick wall that is open-source/cross-platform development on
>>>>>>> Windows.
>>>>>>
>>>>>> Did you look at the example project?
>>>>>
>>>>> No.
>>>>>
>>>>>>
>>>>>> This was basically a one-file C program, that was actually portable
>>>>>> across both Windows and Linux.
>>>>>
>>>>> So why do you need make for that?
>>>>>
>>>>>>
>>>>>> The insistence on using make + auto-config made it more
>>>>>> complicated to
>>>>>> build, and specific to Linux. Adding two extra programs in there
>>>>>> which
>>>>>> have external dependencies, introduced a failure point even on Linux.
>>>>>
>>>>> Nobody would do that for a one-line C program.
>>>>>
>>>>
>>>> Errm, I think part of the problem is that some people *are* using
>>>> autotools for things that could have been built with a trivial
>>>> one-liner
>>>> on the command-line.
>>>>
>>>> It seems like the "cult of GNU" has seemingly convinced people that
>>>> autotools is preferable to both raw Makefiles
>>>
>>> autotools were created to accomodate the wide variety of unix
>>> and unix-like systems and even some non-unix systems - and they've
>>> been sucessful at that by  most measures.
>>>
>>> Yes, it's arcane, and yes, in modern times, it is somewhat
>>> less necessary (note that not all linux distributions have the
>>> same versions of all packages, so even there, autotools are
>>> useful).
>>>
>>> But autotools have been used successfully to create the most
>>> widely portable software available.
>>>
>>> Using labels and generalizations like "cult of GNU" is the sign
>>> that you are relying on emotion rather than logic.
>>>
>>
>> Curious conclusion, I mostly have a form of affective alexithymia, so
>> tend not to identify much with emotion in general (tending to see
>> emotional content more as patterns than as something to be
>> experienced, and may often miss on nuances in these areas).
>
> Some people think that the concept of love is programmed into something
> called the "procreation algorithm pejorative"... ;^)
>

Hmm...

In my case:
Asperger's / high-functioning autism, level 2;
Affective alexithymia;
Limited perception and experience of emotions.
Seemingly both asexual and aromantic (*);
...

*: Had wanted to be able to have kids, but this requires finding someone
compatible, but my non-standard psychology does complicate matters. My
experience of "attraction" is seemingly also fairly limited, and have
noted that what sort of emotional investment I have towards potential
romantic interests does not itself tend to fit "romantic" patterns.

In my case, it isn't so much about wanting/needing anything in
particular, but rather the issue that someone with a more normal
psychology would not be happy with me, which would not work in my best
interest.

Not entirely unemotional, but emotions seem to follow atypical patterns
(that don't really match up with standard social patterns).

In terms with interactions with females, had modified patterns slightly
to be "more useful". Say, it isn't useful to mimic neurotypical romantic
patterns, if any relationship based on those patterns is doomed to fail.
Better to set up "hand grenades" such that if any neurotypicals get too
close, they will soon realize that it will be unworkable.
And, indirectly, this works best for mutual best interest, as they are
better off looking for someone who matches their psychology, which
shouldn't be too hard given they are the majority.

Though, there is another group that is preferably avoided as well:
Namely those who will mimic neurotypical patterns, but then try to bend
the patterns in self-serving ways. Say, acting friendly, but lying about
stuff, and will then steal anything that isn't nailed down when no one
is looking. Usually, if one makes them aware that one can see through
their act, they will go away.

They seem to differ from neurotypicals in a few ways though:
They are basically able to turn their use of NT social patterns on and
off at will (NTs are seemingly unable to "turn off" or dynamically
modify their social patterns if they go outside of a normal scope);
In the presence of emotional queues, they will often lack a sort of
"sentiment lag", where if presented with a piece of "emotionally
relevant information", neurotypicals seem to have a roughly 5 second lag
time which seems to be absent in the "mimics".

From what I can tell, most neurotypicals don't like them either, if
they figure it out, but are seemingly mostly unaware of them. These
types are still best avoided though (if by their actions they show that
they are mostly acting for their own benefit at the possible expense of
others).

But, as I see it, modifying the social patterns to some extent can be
more honest. But there are practical limits here. Also, better to act in
ways that preserves peoples' freedom of choice, and respects their best
interest. But, without necessarily needing to be bound by their social
patterns.

But, not really met anyone that seems particular compatible with my
patterns.

Did at least encounter someone who seems kind of similar in that she
also seemed to have ASD with alexithymia, but there were some other
oddities which I am less sure of. Her responses seemed to be consistent
with those expected for ASD, but she seemingly kept trying to interact
with me as-if I were an NT, despite me trying to make it obvious that
this was not necessary (she was able to step outside of NT patterns; but
seemingly kept trying to revert to using them in interactions). In any
case, she wasn't interested, but never really explained her thinking.

Granted, it is possible that my initial assessment was incorrect, or
that interaction styles were "not sufficiently compatible" (well, or
could be related to emotions as well; as she was not the same as myself
in these areas).

Things reached one of the "endpoint scenarios", so I guess I will just
have to trust her response on this one.

Note that I can note that most people tend to primarily act in terms of
maximizing their own self interest, with some variability in terms of
how much they will respect the well-being of others, or how much they
will act in terms of "generalized altruism".

If someone will try to increase their own self-interest at the expense
of the well-being of others, this is not something I consider to be
acceptable. Though, as I see it, people are not under any obligation to
act in ways that benefit the well-being of others unless it aligns with
their own self-interest (in effect, altruistic behavior is optional,
rather than mandatory).

Say, if one person does act in ways that benefits themselves at the
expense of others, then it becomes in the best interest of those around
them to neutralize that person in some way so that they can no longer
inflict further damage. Similarly, any action they take against others
is justifiably taken against them. If one assumes that each person knows
what the others have done, then it is in the best interest of anyone
involved to not act in ways that harm the well-being of others (lest
they give others a valid reason to take action against them).

But, it can still be worthwhile to pursue actions that more benefit
everyone, rather than focus exclusively on ones' own best interest. Say,
if the value added (over everyone) exceeds the opportunity cost to the
individual (for actions which would only benefit themselves).

Well, and say, each person is transient, and when they cease to exist,
anything they had gathered for themselves becomes moot. All that is left
is whether or not it also brought benefit to those around them (and that
the benefit exceeded the cost, etc).

On 15/01/2024 22:54, BGB wrote:
> On 1/14/2024 4:27 PM, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>>>
>>>>> But you will say, This is obviously for Linux, what did you expect?
>>>>
>>>> Because all the smart folk have given up battering their heads
>>>> against the
>>>> brick wall that is open-source/cross-platform development on Windows.
>>>
>>> Did you look at the example project?
>>
>> No.
>>
>>>
>>> This was basically a one-file C program, that was actually portable
>>> across both Windows and Linux.
>>
>> So why do you need make for that?
>>
>>>
>>> The insistence on using make + auto-config made it more complicated to
>>> build, and specific to Linux. Adding two extra programs in there which
>>> have external dependencies, introduced a failure point even on Linux.
>>
>> Nobody would do that for a one-line C program.
>>
>
> Errm, I think part of the problem is that some people *are* using
> autotools for things that could have been built with a trivial one-liner
> on the command-line.
>

autotools is hard to learn. But once you understand it, AFAIUI (I am
not an autotools user myself) it should be quite simple to set it up for
a new project. So if you have used it for years on many big and small
projects, then even if you are making a tiny little project, it would be
a simple matter for you to use it again for the new project. It costs
you nothing as the developer, and makes it easy for users to compile on
all sorts of systems (other than, depending on your setup, windows).

It would be overkill to learn autotools and use it from scratch for a
tiny project. But if it's already in your toolbox and you know it well,
it could be a completely different matter.

I don't know about anyone else in this thread, but I certainly have no
idea about the developer of the project Bart picked - all I know is that
Bart cherry-picked that project to complain about. It is unreasonable
to criticise his/her decision to use autotools without knowing why it
was done.

bart <bc@freeuk.com> writes:
>On 15/01/2024 21:24, vallor wrote:

>The 'man' stuff is another Linux thing.

It predates linux by a quarter century.

$ man manpage.man

formats and displays the nroff document.

The makefile rule to build a PDF version of a man page:

%.pdf: %.man
@$(QUIET) || echo " BUILDPDF $@"
$(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@

On Tue, 16 Jan 2024 16:13:36 +0000, Scott Lurndal wrote:

> bart <bc@freeuk.com> writes:
>>On 15/01/2024 21:24, vallor wrote:
>
>>The 'man' stuff is another Linux thing.
>
> It predates linux by a quarter century.

In 1978, S. R. Bourne, of Bell Labs, wrote a paper called
"An Introduction to the UNIX shell". Section 2.10 of this
document gives a brief overview of how to access the online
version of the UNIX manual, concluding with a short shell
script that implemented the man(1) command.

> $ man manpage.man

Or, if you want to specify the section (given that some
sections have man pages with names that you might find
in other sections):

man section manpage

as in
man 1 mktemp
which describes the program "mktemp", vs
man 3 mktemp
which describes the library function "mktemp()"

The standard sections of the manual include
1 User Commands
2 System Calls
3 C Library Functions
4 Devices and Special Files
5 File Formats and Conventions
6 Games et. Al.
7 Miscellanea
8 System Administration tools and Deamons

>
> formats and displays the nroff document.
[snip]

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
> Or, if you want to specify the section (given that some
> sections have man pages with names that you might find
> in other sections):
>
> man section manpage
>
> as in
> man 1 mktemp
> which describes the program "mktemp", vs
> man 3 mktemp
> which describes the library function "mktemp()"

You can also type
man mktemp.1
or
man mktemp.3

--
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 Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> [...]
>> Or, if you want to specify the section (given that some
>> sections have man pages with names that you might find
>> in other sections):
>>
>> man section manpage
>>
>> as in
>> man 1 mktemp
>> which describes the program "mktemp", vs
>> man 3 mktemp
>> which describes the library function "mktemp()"
>
> You can also type
> man mktemp.1
> or
> man mktemp.3

That only works if there's a file called "mktemp.1"
(or "mktemp.3") in your local directory, at least
for the version of man(1) that I have available.

14:15 $ pwd
/home/lpitcher/tmp

14:15 $ ls -la
total 84
drwxr-xr-x 2 lpitcher users 69632 Jan 11 14:33 .
drwxr-xr-x 114 lpitcher users 12288 Jan 16 11:07 ..

14:15 $ man mktemp.3
No manual entry for mktemp.3

14:15 $ man mktemp.1
No manual entry for mktemp.1

14:15 $ man 1 mktemp | wc -l
135

14:15 $ man 3 mktemp | wc -l
74

:-)

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> [...]
>>> Or, if you want to specify the section (given that some
>>> sections have man pages with names that you might find
>>> in other sections):
>>>
>>> man section manpage
>>>
>>> as in
>>> man 1 mktemp
>>> which describes the program "mktemp", vs
>>> man 3 mktemp
>>> which describes the library function "mktemp()"
>>
>> You can also type
>> man mktemp.1
>> or
>> man mktemp.3
>
> That only works if there's a file called "mktemp.1"
> (or "mktemp.3") in your local directory, at least
> for the version of man(1) that I have available.

Interesting.

I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
"man mktemp.1" will look up the corresponding man page in $MANPATH.
If I want to use a local file, I can use an absolute or relative path
with a '/' in it, such as "man ./mktemp.1".

[...]

--
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 Tue, 16 Jan 2024 11:23:52 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> [...]
>>>> Or, if you want to specify the section (given that some
>>>> sections have man pages with names that you might find
>>>> in other sections):
>>>>
>>>> man section manpage
>>>>
>>>> as in
>>>> man 1 mktemp
>>>> which describes the program "mktemp", vs
>>>> man 3 mktemp
>>>> which describes the library function "mktemp()"
>>>
>>> You can also type
>>> man mktemp.1
>>> or
>>> man mktemp.3
>>
>> That only works if there's a file called "mktemp.1"
>> (or "mktemp.3") in your local directory, at least
>> for the version of man(1) that I have available.
>
> Interesting.

Indeed. Perhaps my environment is out of whack.

> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
> "man mktemp.1" will look up the corresponding man page in $MANPATH.
> If I want to use a local file, I can use an absolute or relative path
> with a '/' in it, such as "man ./mktemp.1".

Here's what my man(1) manual says:
DESCRIPTION
man formats and displays the on-line manual pages. If you specify sec-
tion, man only looks in that section of the manual. name is normally
the name of the manual page, which is typically the name of a command,
function, or file.

However, if name contains a slash (/) then man interprets it as
a file specification, so that you can do man ./foo.5 or even man
/cd/foo/bar.1.gz.

It's that last sentence that catches my eye.

My man(1) is
14:33 $ man -h
man, version 1.6g
distributed as part of Slackware 14.2, from the source maintained by
Federico Lucifredi (flucifredi@acm.org).

It appears to explicitly /not/ be part of the man-db package, stating in
it's README that
There is a very different man program, also derived from
John Eaton's original version (by Graeme W. Wilford)
distributed under the name man_db, with version numbers
like man_db-2.3.10. Do not confuse the two, they are
mutually incompatible, although they perform nearly the same job.

--
Lew Pitcher
"In Skills We Trust"

On 1/16/2024 6:58 AM, David Brown wrote:
> On 15/01/2024 22:54, BGB wrote:
>> On 1/14/2024 4:27 PM, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 14/01/2024 21:01, Lawrence D'Oliveiro wrote:
>>>>> On Sun, 14 Jan 2024 19:40:46 +0000, bart wrote:
>>>>>
>>>>>> But you will say, This is obviously for Linux, what did you expect?
>>>>>
>>>>> Because all the smart folk have given up battering their heads
>>>>> against the
>>>>> brick wall that is open-source/cross-platform development on Windows.
>>>>
>>>> Did you look at the example project?
>>>
>>> No.
>>>
>>>>
>>>> This was basically a one-file C program, that was actually portable
>>>> across both Windows and Linux.
>>>
>>> So why do you need make for that?
>>>
>>>>
>>>> The insistence on using make + auto-config made it more complicated to
>>>> build, and specific to Linux. Adding two extra programs in there which
>>>> have external dependencies, introduced a failure point even on Linux.
>>>
>>> Nobody would do that for a one-line C program.
>>>
>>
>> Errm, I think part of the problem is that some people *are* using
>> autotools for things that could have been built with a trivial
>> one-liner on the command-line.
>>
>
> autotools is hard to learn.  But once you understand it, AFAIUI (I am
> not an autotools user myself) it should be quite simple to set it up for
> a new project.  So if you have used it for years on many big and small
> projects, then even if you are making a tiny little project, it would be
> a simple matter for you to use it again for the new project.  It costs
> you nothing as the developer, and makes it easy for users to compile on
> all sorts of systems (other than, depending on your setup, windows).
>
> It would be overkill to learn autotools and use it from scratch for a
> tiny project.  But if it's already in your toolbox and you know it well,
> it could be a completely different matter.
>
> I don't know about anyone else in this thread, but I certainly have no
> idea about the developer of the project Bart picked - all I know is that
> Bart cherry-picked that project to complain about.  It is unreasonable
> to criticise his/her decision to use autotools without knowing why it
> was done.
>
>

Luckily at least, in cases where this does happen, and one is not on a
target that uses Bash or similar (*), the workaround is typically
straightforward...

Namely, to ignore the configure script and invoke the compiler directly...

In other cases, for trivial projects, it seems often sufficient to not
bother with a build file, and then assume whoever might want to use the
program, can figure out themselves how to invoke the compiler with a
suitable command-line.

Though, generally, this would not be for programs intended for "typical
end users".

*: Or, like:
Works on Bash;
Maybe works on Bourne shell (not encountered in the wild)
Was a bit hit/miss on Almquist shell
Some newer variants of the shell seem to work.
Often had problems with Ash based systems in the past.

Places it doesn't work:
Windows "cmd" shell;
Windows PowerShell;
...

Wont currently work on the TestKern shell, but this is currently moot:
Not exactly like I can currently compile programs natively in TestKern
in the first place (would need a compiler that doesn't blow out the RAM
budget). The shell itself falls well short of basic expectations for a
Unix style shell though (wont support anything beyond fairly simple
command-lines; closest thing to "advanced shell scripting" supported at
the moment is to fire up a BASIC interpreter or similar (using something
along vaguely similar lines to the 1980s BASIC variants, which allows
for a fairly simple/cheap interpreter design compared with more advanced
languages; but does have the tweak of allowing/preferring named labels
rather than line numbers).

Compilers:
Works fine with GCC;
Can work with Clang;
Didn't seem to work with TinyC or similar in the past;
Can't seem to get it to accept BGBCC as a valid cross-compiler (*).

*: Some fiddling later, got configure to at least "sort of" start
playing along with it, configure then promptly dies once it realizes
that BGBCC doesn't support C++ (which, granted, is a valid issue for the
program in question...).

Doesn't help with debugging as the script seems to redirect stderr
output, so is unclear what command-line arguments and similar configure
is trying to invoke it with.

With some other programs, seemed to completely ignore my attempts to use
the "--host" argument (on one of the programs tested, needing to go and
manually change line endings in a text editor for the various relevant
files, as the files had gotten mangled to use CR+LF endings, which don't
exactly lead to working shell scripts...).

There seems to be some variability in terms of "what hill it will decide
to die on". Seems like configure may be tuned in terms of what features
are considered as critical for the program being compiled.
Some may die on realizing it is not GCC;
Others, on it not supporting C++;
...

But, more progress at the moment than in the past it seems...
Like, it has seemingly at least decided to accept the BGBCC can compile
C... (well, after changing the default output file back to "a.exe" in
the POSIX emulation mode).

Looks like at some point, I had changed it from replacing:
a.exe
With
progname.exe where 'progname' would be the name of the first source
file on the command-line.
But, it seems this throws configure off the trail, so it kinda still
needs to be "a.exe" in this case (or "a.o" with the "-c" option).

....