On 2/4/24 18:10, Chris M. Thomasson wrote:
> On 2/4/2024 4:07 PM, Malcolm McLean wrote:
>> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
>>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>>>
>>>> But it does seem as though Unix was a breeding ground for multitudinous
>>>> developer tools. Plus there was little demarcation between user
>>>> commands, C development tools, C libraries and OS.
>>>>
>>>> Somebody who's used to that environment is surely going to have trouble
>>>> on an OS like MSDOS or Windows where they have to start from nothing.
>>>> Even if most of the tools are now free.
>>>
>>> Yet it seems like even someone like you, who is supposed to be “used to”
>>> Windows rather than *nix, still has the same trouble. So maybe it’s not
>>> about being “used to” *nix at all, there really is something inherent in
>>> the fundamental design of that environment that makes development work
>>> easier.
>> On Windows you can't assume that the end user will be interested in
>> development or have any develoment tools available.
>
> Fwiw, I have seen Linux users that have no intent to program anything at
> all.
>

But the tools are *still preinstalled*, so installers can definitely
rely on compiling stuff.

>
>> Or that he'll be able to do anything other than the most basic
>> installation. It's a consumer platform.
>

--
user <candycane> is generated from /dev/urandom

On 2/4/24 16:02, Chris M. Thomasson wrote:
> On 2/4/2024 9:48 AM, David Brown wrote:
> [...]
>> In Windows, it is sometimes part of a file name (when it is not the
>> last period in the name), sometimes a magical character that appears
>> or disappears (when the file ends in a period), and sometimes it
>> delimits a file extension.
>
> picture_of_a_cow____________________this_is_not_a_virus_really.jpeg.gif.exe
>
> lol.

Windows making such a big deal over file extensions and outright hiding
them is silly IMO
--
user <candycane> is generated from /dev/urandom

On Sun, 4 Feb 2024 01:19:53 +0000, bart <bc@freeuk.com> wrote:

> Everybody says use makefiles; well they don't work. They tend to be
> heavily skewed towards the use of gcc. My compiler isn't gcc.

By default a lot of builtin "implicit rules" determine which
program to use to make a .o from a .c etc. etc., and yes, that
is GCC-centric.

However, it is possible to remove all of those rules by calling
make as
make -rR
meaning:
-r, --no-builtin-rules
-R, --no-builtin-variables
, or by writing an empty
.SUFFIXES:
section in the Makefile.

Then, provide an include file "myrules.mk" with your own rules.

<https://www.gnu.org/software/make/manual/make.html#Old_002dFashioned-Suffix-Rules>

Something like :
%.o : %.c
mcc $< -o $@

etc., and include that in your Makefile with
include myrules.mk

<https://www.gnu.org/software/make/manual/make.html#Including-Other-Makefiles>

I apologize in advance if I missed a post in this huge thread
that already hinted you for that.

--
Regards,
Kees Nuyt

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
> On Sun, 4 Feb 2024 01:19:53 +0000, bart <bc@freeuk.com> wrote:
>> Everybody says use makefiles; well they don't work. They tend to be
>> heavily skewed towards the use of gcc. My compiler isn't gcc.
>
> By default a lot of builtin "implicit rules" determine which
> program to use to make a .o from a .c etc. etc., and yes, that
> is GCC-centric.

Not really. "make" is older than gcc, and GNU make was first released
about a year after the initial release of gcc.

Even modern GNU is not gcc-specific. It assumes by default that the C
compiler is called "cc" (which resolves to "gcc" on many systems, but it
doesn't have to).

Rather gcc mimics the user interface of earlier UNIX C compilers.

--
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 05/02/2024 16:48, candycanearter07 wrote:
> On 2/4/24 16:02, Chris M. Thomasson wrote:
>> On 2/4/2024 9:48 AM, David Brown wrote:
>> [...]
>>> In Windows, it is sometimes part of a file name (when it is not the
>>> last period in the name), sometimes a magical character that appears
>>> or disappears (when the file ends in a period), and sometimes it
>>> delimits a file extension.
>>
>> picture_of_a_cow____________________this_is_not_a_virus_really.jpeg.gif.exe
>>
>> lol.
>
> Windows making such a big deal over file extensions and outright hiding
> them is silly IMO

Hiding the extension is a complete nightmare. Unless the automatic
recognition system works perfectly, you can end up with a file you can't
use.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2/5/24 11:29, Malcolm McLean wrote:
> On 05/02/2024 16:48, candycanearter07 wrote:
>> On 2/4/24 16:02, Chris M. Thomasson wrote:
>>> On 2/4/2024 9:48 AM, David Brown wrote:
>>> [...]
>>>> In Windows, it is sometimes part of a file name (when it is not the
>>>> last period in the name), sometimes a magical character that appears
>>>> or disappears (when the file ends in a period), and sometimes it
>>>> delimits a file extension.
>>>
>>> picture_of_a_cow____________________this_is_not_a_virus_really.jpeg.gif.exe
>>>
>>> lol.
>>
>> Windows making such a big deal over file extensions and outright
>> hiding them is silly IMO
>
> Hiding the extension is a complete nightmare. Unless the automatic
> recognition system works perfectly, you can end up with a file you can't
> use.

Or they could just use the magic number as a fallback..
--
user <candycane> is generated from /dev/urandom

On 2024-02-04, bart <bc@freeuk.com> wrote:
> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>>
>>> But it does seem as though Unix was a breeding ground for multitudinous
>>> developer tools. Plus there was little demarcation between user
>>> commands, C development tools, C libraries and OS.
>>>
>>> Somebody who's used to that environment is surely going to have trouble
>>> on an OS like MSDOS or Windows where they have to start from nothing.
>>> Even if most of the tools are now free.
>>
>> Yet it seems like even someone like you, who is supposed to be ???used to???
>> Windows rather than *nix, still has the same trouble.
>
>
> *I* don't have trouble. Only with other people's projects originating
> from Linux.
>
> Apparently, on that OS, nobody knows how to build a program given only
> the C source files, and a C compiler.

Programmers and Developers do.

> Or if they do, they are unwilling to part with that information. It is
> encrypted into a makefile, or worse.

Encrypted? I always thought makefiles were plain text? You can read them
with less^H^H^H^H "more" - which if memory serves, is also a DOS command?

As an aside I skip most of this rubbish and just dip in occasionally.
But I think I have some measure of where bart is coming from. Some
people come at things not as they are, but as they wish they were given
their background.

I'll go back to lurking and just dipping into this if I've time to waste.

On 05/02/2024 17:37, Jim Jackson wrote:
> On 2024-02-04, bart <bc@freeuk.com> wrote:
>> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
>>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>>>
>>>> But it does seem as though Unix was a breeding ground for multitudinous
>>>> developer tools. Plus there was little demarcation between user
>>>> commands, C development tools, C libraries and OS.
>>>>
>>>> Somebody who's used to that environment is surely going to have trouble
>>>> on an OS like MSDOS or Windows where they have to start from nothing.
>>>> Even if most of the tools are now free.
>>>
>>> Yet it seems like even someone like you, who is supposed to be ???used to???
>>> Windows rather than *nix, still has the same trouble.
>>
>>
>> *I* don't have trouble. Only with other people's projects originating
>> from Linux.
>>
>> Apparently, on that OS, nobody knows how to build a program given only
>> the C source files, and a C compiler.
>
> Programmers and Developers do.
>
>> Or if they do, they are unwilling to part with that information. It is
>> encrypted into a makefile, or worse.
>
> Encrypted? I always thought makefiles were plain text? You can read them
> with less^H^H^H^H "more" - which if memory serves, is also a DOS command?
>
Here's one on my machine I selected almost at random

!ifndef BCROOT
BCROOT=$(MAKEDIR)\..
!endif

BCC32 = $(BCROOT)\bin\Bcc32.exe

IDE_LinkFLAGS32 = -L$(BCROOT)\LIB
COMPOPTS= -O2 -tWC -tWM- -Vx -Ve -D_NO_VCL; -I../../../../;
-L..\..\build\bcb5

timer.exe : regex_timer.cpp
$(BCC32) @&&|
$(COMPOPTS) -e$@ regex_timer.cpp
|

Whilst some of this is pretty clear, it's not all obvious what the
second half of the line
$(BCC32) @&&|
is meant to mean.

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

On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
> But the tools are *still preinstalled*, so installers can definitely
> rely on compiling stuff.

No, they aren't. It's common for devel tools not to be part of the base
system of a distro.

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

On 05/02/2024 18:03, Malcolm McLean wrote:
> On 05/02/2024 17:37, Jim Jackson wrote:
>> On 2024-02-04, bart <bc@freeuk.com> wrote:
>>> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
>>>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>>>>
>>>>> But it does seem as though Unix was a breeding ground for
>>>>> multitudinous
>>>>> developer tools. Plus there was little demarcation between user
>>>>> commands, C development tools, C libraries and OS.
>>>>>
>>>>> Somebody who's used to that environment is surely going to have
>>>>> trouble
>>>>> on an OS like MSDOS or Windows where they have to start from nothing.
>>>>> Even if most of the tools are now free.
>>>>
>>>> Yet it seems like even someone like you, who is supposed to be
>>>> ???used to???
>>>> Windows rather than *nix, still has the same trouble.
>>>
>>>
>>> *I* don't have trouble. Only with other people's projects originating
>>> from Linux.
>>>
>>> Apparently, on that OS, nobody knows how to build a program given only
>>> the C source files, and a C compiler.
>>
>> Programmers and Developers do.
>>
>>> Or if they do, they are unwilling to part with that information. It is
>>> encrypted into a makefile, or worse.
>>
>> Encrypted? I always thought makefiles were plain text? You can read them
>> with less^H^H^H^H "more" - which if memory serves, is also a DOS command?
>>
> Here's one on my machine I selected almost at random
>
> !ifndef BCROOT
> BCROOT=$(MAKEDIR)\..
> !endif
>
> BCC32   = $(BCROOT)\bin\Bcc32.exe
>
> IDE_LinkFLAGS32 =  -L$(BCROOT)\LIB
> COMPOPTS= -O2 -tWC -tWM- -Vx -Ve -D_NO_VCL; -I../../../../;
> -L..\..\build\bcb5
>
>
> timer.exe : regex_timer.cpp
>   $(BCC32) @&&|
>  $(COMPOPTS) -e$@ regex_timer.cpp
> |
>
>
> Whilst some of this is pretty clear, it's not all obvious what the
> second half of the line
> $(BCC32) @&&|
> is meant to mean.
>
>

I thought of some project and decided to look at NASM sources, choosing
2.15 from a few years ago as it might be simpler.

There was no makefile, only makefile.in of 1000 lines. If I type 'make',
it says no targets found.

There was also 'configure' of 11,000 lines, so I switched to WSL. Now
typing ./configure shows:

-bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory

So it doesn't work on Linux either. If I look at INSTALL, it actually
says use "sh configure". That now says:

: not found14:
configure: 30: Syntax error: newline unexpected (expecting ")")

The entire project is only 106 .c files.

If I try compiling a random .c file, it complains of a missing header.

This is all quite typical.

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>On Sun, 4 Feb 2024 01:19:53 +0000, bart <bc@freeuk.com> wrote:
>
>> Everybody says use makefiles; well they don't work. They tend to be
>> heavily skewed towards the use of gcc. My compiler isn't gcc.
>
>By default a lot of builtin "implicit rules" determine which
>program to use to make a .o from a .c etc. etc., and yes, that
>is GCC-centric.

I wouldn't call them GCC-centric, for the most it is POSIX-centric,
i.e.
CC = cc

Although there is
CXX = g++

The built-in recipes are pretty generic.

%.o: %.c
# recipe to execute (built-in):
$(COMPILE.c) $(OUTPUT_OPTION) $<

%.cc:

%: %.cc
# recipe to execute (built-in):
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@

%.o: %.cc
# recipe to execute (built-in):
$(COMPILE.cc) $(OUTPUT_OPTION) $<

%.C:

%: %.C
# recipe to execute (built-in):
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@

%.o: %.C
# recipe to execute (built-in):
$(COMPILE.C) $(OUTPUT_OPTION) $<

%.cpp:

%: %.cpp
# recipe to execute (built-in):
$(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@

%.o: %.cpp
# recipe to execute (built-in):
$(COMPILE.cpp) $(OUTPUT_OPTION) $<

You can always override the variable on the make command line

$ make CC=bcc

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 05/02/2024 17:37, Jim Jackson wrote:
>> On 2024-02-04, bart <bc@freeuk.com> wrote:
>>> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
>>>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>>>>
>>>>> But it does seem as though Unix was a breeding ground for multitudinous
>>>>> developer tools. Plus there was little demarcation between user
>>>>> commands, C development tools, C libraries and OS.
>>>>>
>>>>> Somebody who's used to that environment is surely going to have trouble
>>>>> on an OS like MSDOS or Windows where they have to start from nothing.
>>>>> Even if most of the tools are now free.
>>>>
>>>> Yet it seems like even someone like you, who is supposed to be ???used to???
>>>> Windows rather than *nix, still has the same trouble.
>>>
>>>
>>> *I* don't have trouble. Only with other people's projects originating
>>> from Linux.
>>>
>>> Apparently, on that OS, nobody knows how to build a program given only
>>> the C source files, and a C compiler.
>>
>> Programmers and Developers do.
>>
>>> Or if they do, they are unwilling to part with that information. It is
>>> encrypted into a makefile, or worse.
>>
>> Encrypted? I always thought makefiles were plain text? You can read them
>> with less^H^H^H^H "more" - which if memory serves, is also a DOS command?
>>
>Here's one on my machine I selected almost at random
>
>!ifndef BCROOT
>BCROOT=$(MAKEDIR)\..
>!endif
>
>BCC32 = $(BCROOT)\bin\Bcc32.exe
>
>IDE_LinkFLAGS32 = -L$(BCROOT)\LIB
>COMPOPTS= -O2 -tWC -tWM- -Vx -Ve -D_NO_VCL; -I../../../../;
>-L..\..\build\bcb5
>
>
>timer.exe : regex_timer.cpp
> $(BCC32) @&&|
> $(COMPOPTS) -e$@ regex_timer.cpp
>|

The recipes are executed using the host shell.

That must be one of barts makefiles.

As it is shown, it is not a valid make recipe for any unix or
linux shell.

timer.exe: regex_timer.cpp
$(BCC32) $(COMPOPTS) -e $@ regex_timer.cpp

would be more likely, but the parameter to '-e' is completely
interpeted by whatever program is specified by the BCC32 variable.

On 2/5/2024 6:48 AM, Tim Rentsch wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 2/4/2024 8:41 PM, Keith Thompson wrote:
>>
>>> [...]
>>>
>>> Better yet, if you could cut down on the followups that don't add
>>> anything relevant, I for one would appreciate it.
>
> For what it's worth, I second Keith's request, and strenuously
> support it.

I was trying to lighten the mood, so to speak. Well, it backfired on me. ;^o

On 2/5/2024 7:45 AM, bart wrote:
[...]
> Yeah, because no other OS has ever required a hard reboot. I've had to
> do a hard power-off and power-on cycle endless times on smart TVs,
> phones and tablets. None of them ran Windows.
[...]
You never experienced a blue screen of death on Windows?

bart <bc@freeuk.com> writes:
[...]
> There was also 'configure' of 11,000 lines, so I switched to WSL. Now
> typing ./configure shows:
>
> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory

It looks like you've downloaded the source as a .zip file, which was
packaged incorrectly. I've reported this to their mailing list. Try
downloading the .tar.gz file instead.

--
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 05/02/2024 21:25, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> There was also 'configure' of 11,000 lines, so I switched to WSL. Now
>> typing ./configure shows:
>>
>> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory
>
> It looks like you've downloaded the source as a .zip file, which was
> packaged incorrectly. I've reported this to their mailing list. Try
> downloading the .tar.gz file instead.
>

Well, this was the 2020 version (I thought it might be slightly less
challenging than the latest, and not so old that that had its own problems).

Maybe a newer one is fixed.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/5/2024 6:48 AM, Tim Rentsch wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 2/4/2024 8:41 PM, Keith Thompson wrote:
>>>> [...]
>>>>
>>>> Better yet, if you could cut down on the followups that don't add
>>>> anything relevant, I for one would appreciate it.
>> For what it's worth, I second Keith's request, and strenuously
>> support it.
>
> I was trying to lighten the mood, so to speak. Well, it backfired on me. ;^o

Does that mean you're going to stop? You're just about to land in my
killfile, but I'm willing to reconsider. You do sometimes post relevant
content, but it's just not worth digging through the noise.

--
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 */

bart <bc@freeuk.com> writes:
> On 05/02/2024 21:25, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> There was also 'configure' of 11,000 lines, so I switched to WSL. Now
>>> typing ./configure shows:
>>>
>>> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory
>> It looks like you've downloaded the source as a .zip file, which was
>> packaged incorrectly. I've reported this to their mailing list. Try
>> downloading the .tar.gz file instead.
>>
>
> Well, this was the 2020 version (I thought it might be slightly less
> challenging than the latest, and not so old that that had its own
> problems).
>
> Maybe a newer one is fixed.

No, I downloaded 2.16.01 from 2022-12-21. Try the .tar.gz file instead
(or .tar.bz2, or .tar.xz).

--
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 */

In article <8734u6lhop.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 2/5/2024 6:48 AM, Tim Rentsch wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 2/4/2024 8:41 PM, Keith Thompson wrote:
>>>>> [...]
>>>>>
>>>>> Better yet, if you could cut down on the followups that don't add
>>>>> anything relevant, I for one would appreciate it.
>>> For what it's worth, I second Keith's request, and strenuously
>>> support it.
>>
>> I was trying to lighten the mood, so to speak. Well, it backfired on me. ;^o
>
>Does that mean you're going to stop? You're just about to land in my
>killfile, but I'm willing to reconsider. You do sometimes post relevant
>content, but it's just not worth digging through the noise.

The best possible thing that can happen to a CLC poster is to be killfiled
by Keith - as I was (and still am) long ago. Then you are spared Keith's
incessant bitching and whining about your posts.

I am hoping Chris is lucky enough to be given this honor.

--
Meatball Ron wants to replace the phrase "climate change" with the phrase
"energy dominance" in policy discussions.

Yeah, like that makes a lot of sense...

On 2024-02-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> There was also 'configure' of 11,000 lines, so I switched to WSL. Now
>> typing ./configure shows:
>>
>> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory
>
> It looks like you've downloaded the source as a .zip file, which was
> packaged incorrectly.

Or, no?

I'm guessing that a .zip file is intended for Windows users and so it has
text files in CR-LF format.

It might be intended to be built in the MinGW environment.

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-02-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> There was also 'configure' of 11,000 lines, so I switched to WSL. Now
>>> typing ./configure shows:
>>>
>>> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory
>>
>> It looks like you've downloaded the source as a .zip file, which was
>> packaged incorrectly.
>
> Or, no?
>
> I'm guessing that a .zip file is intended for Windows users and so it has
> text files in CR-LF format.
>
> It might be intended to be built in the MinGW environment.

Possibly. I got a reply on the mailing list:
https://lists.nasm.us/archives/nasm-devel/2024-February/000095.html

It isn't an error; the .zip file has DOS-style file endings because it
is intended primarily to be used on DOS/Windows and similar systems.

On Unix, you can extract it with "unzip -a" or (better) use the .tar.xz
file.

If you use "unzip -a" it will translate CRLF to LF line endings for
files that are considered to be "text".

Normally /bin/sh doesn't tolerate CRLF line endings (more precisely, it
treats the CR as part of the line and LF as the line ending). I suppose
there's a /bin/sh provided with MinGW; I don't know how it behaves.

--
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 Mon, 5 Feb 2024 15:45:07 +0000, bart wrote:

> Pretty much every front-end not aimed at technical users is
> case-insensitive.

Some Linux filesystems offer this option, should you want to enable it
<https://lwn.net/Articles/784041/>.

On 2024-02-05, bart <bc@freeuk.com> wrote:
> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory

This indicates that the thing you're trying to build was converted
to Windows format. See that ^M? It's a carriage return; what's that
doing in a POSIX shell script? Someone likely did that on purpose.

Firstly, projects with ./configure shell scripts are often not ported to
Windows at all. If that is the case, you could be the first one trying
that. In that situation, the best bet is Cygwin. (Or WSL2, but that's
basically not Windows.)

The .zip file containing files converted to Windows format suggests
that the package is ported to Windows, using some build environment that
uses CR-LF files like MinGW.

Your best bet is to consult the project and ask them, how is it ported
to Windows? Then do it their way. Otherwise you're on your own.

Another pattern that occurs is that FOSS projects which port their code
to Windows themselves provide binaries for Windows, so they don't expect
users to build those. Thus their procedure for building on Windows might not
be well documented.

> This is all quite typical.

You not knowing where to get a glue and generally being lost
at sea with no rudder or sail?

Don't you have some nephew or niece in the fifth grade who could
help with this?

When I go to the NASM site (https://www.nasm.us) there is a clear
Download link.

In the download link, there are versioned and dated release
directories.

In the most recent one, there are Win32 and Win64 subdirectories.

There is a file

nasm-2.16.02rc9-installer-x64.exe

Doh?

They've gone out of the way to support Windows users with an executable
installer.

If you want to know how they built that, they may have documentation
elsewhere. There might be instructions in the accompanying .zip or else
you just have to as in the mailing list.

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

On Mon, 5 Feb 2024 13:02:52 +0100, David Brown wrote:

> It /is/ a consumer platform, yes. And because it has no standard ways
> to build software, and no one (approximately) using it wants to build
> software on it, the norm is to distribute code in binary form for
> Windows. That works out fine for almost all Windows users. That
> includes libraries - even C programmers on Windows don't want to build
> "libjpeg" or whatever, they want a DLL.

But without integrated package management, how do you keep it all up to
date? If two separate apps use the same library, do they each end up with
their own version, or do they share one version? Does each app have to run
its own periodic background updater task to tell you there’s a new version
available?

On 05/02/2024 22:51, Lawrence D'Oliveiro wrote:
> On Mon, 5 Feb 2024 13:02:52 +0100, David Brown wrote:
>
>> It /is/ a consumer platform, yes. And because it has no standard ways
>> to build software, and no one (approximately) using it wants to build
>> software on it, the norm is to distribute code in binary form for
>> Windows. That works out fine for almost all Windows users. That
>> includes libraries - even C programmers on Windows don't want to build
>> "libjpeg" or whatever, they want a DLL.
>
> But without integrated package management, how do you keep it all up to
> date? If two separate apps use the same library, do they each end up with
> their own version, or do they share one version? Does each app have to run
> its own periodic background updater task to tell you there’s a new version
> available?

The term is DLL hell.
If a DLL changes, does that means that apps which called the old DLL and
are were buggy should call the new DLL and will now be fixed? Or should
they still call the old DLL in case the new DLL breaks something? And
who is responsible for managing this and testing things, and making sure
old versions are still hanging around if needed but not accidentally
linked to?
It's still a problem with static libraries of course, but now at least
is clear that it is develooer of the app is the person responsible for
deciding which version shall be linked and testing that it works. At
least if you distribute binary.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm