On 15/08/2023 16:58, MJ OS_EXAMINE wrote:
> On Tuesday, August 15, 2023 at 11:12:10 AM UTC-4, Bart wrote:
>> I usually avoid .tar.gz files since they are a pig to extract on
>> Windows. It involves using 7-Zip, but is still a trial-and-error
process.
>
> I don't think that's been necessary for a few Windows versions now.
> These days, Windows comes with its own built-in tar that allows you
to just:
> tar -xvf lua-5.4.6.tar.gz
> See:
>
https://learn.microsoft.com/en-us/virtualization/community/team-blog/2017/20171219-tar-and-curl-come-to-windows

Oh is it back? I remember 'tar' from long ago, but it only did .tar
files iirc.

But your link is dated 2023, it seems to be recent.

..tar.gz and like files I think were supposed to be handled directly by
Windows, but that never worked. I had to use a package called 7-Zip, and
it was dire.

You clicked Extract, and it did half the job; you had a .tar file. You
clicked extract on that, and nothing happened. Eventually it would deign
to extract files, but it was pot-luck where they would end up, or how
deeply nested, even if you gave a path.

It was confusing also because you could just click and go inside the
archive, but I think you'd need to be at the right location for Extract
to work.

So thanks.

On Sunday, August 13, 2023 at 10:53:59 AM UTC-3, Bart wrote:
> Bart:
> >> Suppose you dispensed with all that dependency stuff; how long would
> >> it take to build such a project? Say compared with just compiling one
> >> module.

I am still using and very satisfied with the solution we already had topics here that
is create a simple executable that does the build.

All I need for windows

cl build.c && build

All I need for Linux
gcc build.c -o build && ./build

When you have several files to be compiled, having one more file that is the build
itself does not make any difference. Usage of preprocessor is very handy.

I also have automatic unit tests . all I need to do is

cl -DTEST build.c && build

Bart <bc@freeuk.com> writes:
[...]
> My recent post goes into this in more detail. But, I've believe the
> ZIP files from the Github Lua repository are incorrect.

You're right.

The GitHub repo for Lua is
https://github.com/lua/lua
It includes (not as part of the repo itself) a number of releases,
including:
https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz

The lua.org site provides a tarball:
https://www.lua.org/ftp/lua-5.4.6.tar.gz
I don't see any zip files on lua.org.

The zipfile and tarball from the GitHub release match each other, but do
not match the tarball from lua.org.

> So, whose fault is that?

I have no idea, but I hardly think comp.lang.c is the place to complain
about it.

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

Bart <bc@freeuk.com> writes:
[...]
> The releases page for Github Lua, for version 5.4.6, has these two assets:
>
> * Source code: v5.4.6.zip
>
> * Source code: v5.4.6.tar.gz
>
> TELL me where in the build instructions it says that the contents of
> these two files are incompatible.

It doesn't, because their contents are identical. I just checked.

They differ from the lua-5.4.6.tar.gz file on the lua.org website.

https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
https://www.lua.org/ftp/lua-5.4.6.tar.gz

The release files on github.com are copies of the git repo. The
lua-5.4.6.tar.gz was *generated* from the files in the git repo.
It's created by the Lua maintainers; I don't know how.

The tarball on the lua.org web site is the one you should use to build
Lua from source. (If you want to work on developing Lua itself, you
should clone the repo. I'm not convinced that the GitHub release files
are particularly useful.)

> THEN then tell me why they are incompatible, and what the point is of
> the .zip version since it has a missing outer makefile.
>
> NOW tell me why on earth someone would know, or even guess, that the
> source bundles contained in those files are anything other than the
> same data, packaged in different types of containers.

That's exactly what they are, but they differ from the tar.gz file from
lua.org.

People who want to build Lua from source (without necessarily wanting to
work on the Lua implementation) should build from the .tar.gz file from
lua.org.

[...]

> You know, one thing is going 100% certain in this thread: you are
> never for one minute going to admit that I'm right in there being
> something wrong with those Github ZIPs.
>
> You didn't see the problem because you either obtained the source
> bundle elsewhere, or would have used only the .tar.gz version.
>
> So, fuck you as well as Scott. This clearly is a personal vendetta.

Dude, calm down. Scott likely wasn't aware of the GitHub release files.
The presence of those files is genuinely confusing, but that's not
Scott's fault.

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

scott@slp53.sl.home (Scott Lurndal) writes:
> David Brown <david.brown@hesbynett.no> writes:
>>On 15/08/2023 17:11, Bart wrote:
>>> On 15/08/2023 14:21, David Brown wrote:
>>> I usually avoid .tar.gz files since they are a pig to extract on
>>> Windows. It involves using 7-Zip, but is still a trial-and-error process.
>>>
>>
>>Is there /nothing/ in this world that you don't find hard? How can you
>>possibly have trouble with a simple compressed archive? It's not as if
>>it contains filenames that Windows can't handle.
>
> IIRC, Windows filesystems are case insensitive. Would not that preclude
> successfully unpacking a tarball which contains two filenames which differ
> only in case?

Depends on whether "successfully" is viewed from the perspective of
the person trying to root your system, as in this git(hub) bug from
nearly a decade ago:
https://www.beyondtrust.com/blog/entry/dissecting-githubs-case-insensitive-discrepancies
TL;DF: create some ``.Git/hooks/*'' files or a ``.Git/config'' file

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 15/08/2023 20:48, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> My recent post goes into this in more detail. But, I've believe the
>> ZIP files from the Github Lua repository are incorrect.
>
> You're right.
>
> The GitHub repo for Lua is
> https://github.com/lua/lua
> It includes (not as part of the repo itself) a number of releases,
> including:
> https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
> https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
>
> The lua.org site provides a tarball:
> https://www.lua.org/ftp/lua-5.4.6.tar.gz
> I don't see any zip files on lua.org.
>
> The zipfile and tarball from the GitHub release match each other, but do
> not match the tarball from lua.org.

OK, that one was my mistake then. But it means they're both wrong. And
if that Mr. DB had downloaded the source code from the Github, then the
make instructions he saw on lua.org would not have worked because of a
missing makefile.

>> So, whose fault is that?
>
> I have no idea, but I hardly think comp.lang.c is the place to complain
> about it.

What I'm complaining about is being falsely (and I believe maliciously)
accused of incompetence:

BC:
>> So, whose fault is that?
>
DB:
> Yours - you did not read the build instructions, but ploughed on with
> your own guesswork and got into trouble.

That doesn't bother you I guess. Although this won't stop DB, who will
claim that of course I should have known that different kinds of source
'tarballs' exist for the version of product, and only some of them will
work with the given build instructions.

Although I did mention Github regarding Lua two days ago; you'd think
someone would have told me that was the wrong site to download source
code from, if it's so bleeding obvious.

As for who is at fault; I'd suggest:

(1) The github site for not mentioning anything about it at all, like:
'download the proper tarball from lua.org' if you want to build it. (Why
isn't that top layer present anyway?)

(2) Even with the correct sources, you'd have to go on a scavenger hunt
through lua.org's Readme page to find the right instructions to run
'make' for plain Windows.

BTW the thread is about build systems. My contention was that 'make' on
Windows (actual Windows not Linux running under Windows) is generally
troublesome.

I haven't seen evidence to the contrary.

On 15/08/2023 21:36, Bart wrote:

> As for who is at fault; I'd suggest:
>
> (1) The github site for not mentioning anything about it at all, like:
> 'download the proper tarball from lua.org' if you want to build it. (Why
> isn't that top layer present anyway?)
>
> (2) Even with the correct sources, you'd have to go on a scavenger hunt
> through lua.org's Readme page to find the right instructions to run
> 'make' for plain Windows.

BTW, why does Github (on this project and I've seen it on others)
provide both .zip and .tar.gz sources?

According to DB, processing .tar.gz files is so utterly trivial that
there appears to be little point to using .zip.

People who prefer .zip will of course choose that if both are options.

On 15/08/2023 10:08, David Brown wrote:
> "make" automates the process of figuring out which compilations are
> needed.  Of course it doesn't do anything that I could not do manually.
> And if I change "spi.c" then I know I need to re-compile that, and not
> "uart.c", and other files.  But that would mean that after editing
> "spi.c" I'd have to manually choose to re-compile "spi.c", including the
> perhaps 500 or more characters in the command line (lots of warning
> flags, carefully chosen options, pre-defined macros, directory paths for
> source code, object code, listing files, include paths, etc. - this is
> not a "hello.c" toy on a PC).  And if I changed the "clocks.h" header,
> I'd have to look through dozens of source files to see which ones
> included that header and needed re-compiling, and which ones do not.
>
> Or I can type "make".  (Or, more commonly, press "ctrl-B" and the IDE
> will do "make" and update the source windows with markers for any issues
> found.)
>
> Which do you think is a better choice for development?

When I was still being paid to do this stuff (and not just following the
group out of nostalgia) we used a tool called Ice Cream

<https://github.com/icecc/icecream>

which distributed the work around the pool of machines in the office.
OK, there was a _lot_ of C++ in it, but a clean compile still took an
hour or so. If you are finding that your compiles take a long time it's
worth looking into.

That page mentions distcc as one of the ancestors.

Andy

On 15/08/2023 19:01, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 15/08/2023 17:11, Bart wrote:
>>> On 15/08/2023 14:21, David Brown wrote:
>
>>>
>>> I usually avoid .tar.gz files since they are a pig to extract on
>>> Windows. It involves using 7-Zip, but is still a trial-and-error process.
>>>
>>
>> Is there /nothing/ in this world that you don't find hard? How can you
>> possibly have trouble with a simple compressed archive? It's not as if
>> it contains filenames that Windows can't handle.
>
> IIRC, Windows filesystems are case insensitive. Would not that preclude
> successfully unpacking a tarball which contains two filenames which differ
> only in case?
>

Yes - but the tarball in question does not have such files.

(NTFS supports having files whose names differ only in case, because it
was made to support POSIX semantics, from early plans for WinNT to be
more POSIX-like. It is possible to create filenames on an NTFS drive
that normal Windows programs can't handle, causing much fun as a prank.)

Bart <bc@freeuk.com> writes:
> On 15/08/2023 20:48, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> My recent post goes into this in more detail. But, I've believe the
>>> ZIP files from the Github Lua repository are incorrect.
>> You're right.
>> The GitHub repo for Lua is
>> https://github.com/lua/lua
>> It includes (not as part of the repo itself) a number of releases,
>> including:
>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
>> The lua.org site provides a tarball:
>> https://www.lua.org/ftp/lua-5.4.6.tar.gz
>> I don't see any zip files on lua.org.
>> The zipfile and tarball from the GitHub release match each other,
>> but do
>> not match the tarball from lua.org.
>
> OK, that one was my mistake then. But it means they're both wrong. And
> if that Mr. DB had downloaded the source code from the Github, then
> the make instructions he saw on lua.org would not have worked because
> of a missing makefile.
>
>>> So, whose fault is that?
>> I have no idea, but I hardly think comp.lang.c is the place to
>> complain
>> about it.
>
> What I'm complaining about is being falsely (and I believe
> maliciously) accused of incompetence:

You're far too quick to assume malice.

> BC:
>>> So, whose fault is that?
>>
> DB:
>> Yours - you did not read the build instructions, but ploughed on with
>> your own guesswork and got into trouble.

I won't attempt to speak for DB, but I doubt that it occurred to him
that the release files on GitHub differ so substantially from the
..tar.gz files on lua.org.

> That doesn't bother you I guess. Although this won't stop DB, who will
> claim that of course I should have known that different kinds of
> source 'tarballs' exist for the version of product, and only some of
> them will work with the given build instructions.
>
> Although I did mention Github regarding Lua two days ago; you'd think
> someone would have told me that was the wrong site to download source
> code from, if it's so bleeding obvious.

It's not obvious, and nobody has said that it is. I would have assumed
that the release .tar.gz file from GitHub was similar to the .tar.gz
file from lua.org until I checked.

> As for who is at fault; I'd suggest:
>
> (1) The github site for not mentioning anything about it at all, like:
> 'download the proper tarball from lua.org' if you want to build
> it. (Why isn't that top layer present anyway?)

GitHub release files are just packaged copies of the files in the repo.
The release tarball from lua.org is built from that. For example, the
GitHub repo includes documentation in what appears to be a
project-specific format; the lua.org release includes generated man
pages and html files.

The README.md file says: "Download official Lua releases from Lua.org.".

Yes, the presence of the "release" files on GitHub is misleading. Now
that we've established that, can we stop complaining about it here?

[...]

--
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 15/08/2023 19:49, Bart wrote:

> You know, one thing is going 100% certain in this thread: you are never
> for one minute going to admit that I'm right in there being something
> wrong with those Github ZIPs.
>
> You didn't see the problem because you either obtained the source bundle
> elsewhere, or would have used only the .tar.gz version.
>

Look, I have no idea if these are the same or different. I don't know,
and don't care. The only reason I was at the lua website at all was
because /you/ picked it as something that "proves" that make never works
on Windows. I went to the lua website, followed the instructions on how
to build lua on Windows, and it worked - using "make". /You/ did not
not follow the instructions, and you got in trouble. No doubt you'd
have got in trouble even if you did follow the instructions, because you
are always so determined to have everything fail.

I am not going to look at the zip files, or compare them, and I am
certainly not going to spend any more effort trying to help you figure
out what you did wrong.

> You hate me so much that whenever I find a problem anywhere, it
> automatically has to be my fault, even when it isn't!

I don't hate you at all - if I did, then I would not have been wasting
so much time trying to help you.

>
> And you're so intent on proving me wrong, that you even delude yourself
> that doing this:
>
>    curl -R -O http://www.lua.org/ftp/lua-5.4.6.tar.gz
>    tar zxf lua-5.4.6.tar.gz
>    cd lua-5.4.6
>    make all test
>
> is 'installing it on Windows'.

It /is/ installing it on Windows.

> And when challenged, you say that doing
> it under MSYS2 is also 'installing it on Windows'.

I have msys2 installed. On Windows. I used tools from that (including
make) to build Lua. On Windows. It resulted in Windows exe files for
Lua. They are on my Windows machine. I can now run lua on Windows.
(This is Windows 7, with no WSL in sight, no virtual machines, or
anything like that.) I can copy these exe files to another windows
machine, and they work there too. How is that /not/ "installing it on
windows" ? What is your criteria here - if it works for someone else,
then they must naturally have been cheating in some way, because it
could not possibly be that /you/ have the problem?

>
> You know, I don't believe you actually know how to do this under plain
> Windows! Otherwise you would have done so; you must know that's what I
> use.)
>

By /my/ ruling, any system with "bcc" or "tcc" is not plain Windows.
Therefore you failed.

Does that sound familiar? Any more goalposts you want to shuffle around
and move to completely different pitches in another feeble attempt to
look less pathetic?

>
> So, what have /you/ achieved?
>

I did exactly what you claimed was impossible - used "make" to build Lua
on windows.

On 15/08/2023 22:09, David Brown wrote:
> On 15/08/2023 19:49, Bart wrote:
>
>> You know, one thing is going 100% certain in this thread: you are
>> never for one minute going to admit that I'm right in there being
>> something wrong with those Github ZIPs.
>>
>> You didn't see the problem because you either obtained the source
>> bundle elsewhere, or would have used only the .tar.gz version.
>>
>
> Look, I have no idea if these are the same or different. I don't know,
> and don't care. The only reason I was at the lua website at all was
> because /you/ picked it as something that "proves" that make never works
> on Windows. I went to the lua website, followed the instructions on how
> to build lua on Windows, and it worked - using "make". /You/ did not
> not follow the instructions,

I downloaded an open source project like I've done a hundred others:
from Github. It's usually expected to have everything needed to build
the project, except for the actual tools.

> and you got in trouble. No doubt you'd
> have got in trouble even if you did follow the instructions, because you
> are always so determined to have everything fail.

You don't see the failures because most open source software is
developed for Unix-like OSes, so build systems are well-tested because
so many will be using that and will have reported failures.

In addition, even for software that runs on Windows, you hide behind a
wall of Linux utilities; using MSYS2 or WSL.

So really, it's not surprising that everything works for you with hardly
needing to lift a finger.

>> You know, I don't believe you actually know how to do this under plain
>> Windows! Otherwise you would have done so; you must know that's what I
>> use.)
>>
>
> By /my/ ruling, any system with "bcc" or "tcc" is not plain Windows.
> Therefore you failed.

Huh? Those are compilers. You need a C compiler to turn .c files into
..exe files. You don't need that other crap.

>> So, what have /you/ achieved?
>>
>
> I did exactly what you claimed was impossible

I said when I tried it, it failed.

> - used "make" to build Lua on windows.

So did I in the end. But I'd long since done it anyway:

* Without even needing the 'proper' source file bundle: the Github
version was fine

* Without using 'make' or the right makefile

* Without using MSYS2 or CYGWIN

* Without using WSL

All in all I did better without using 'make'. I could even switch
instantly between GCC and TCC.

AND I built in with my BCC, which cannot be used from a makefile, not
the one here anyway, because it expects a C compiler to work in a
certain way.

Bart <bc@freeuk.com> writes:
> On 15/08/2023 22:09, David Brown wrote:
>> On 15/08/2023 19:49, Bart wrote:
>>> You know, one thing is going 100% certain in this thread: you are
>>> never for one minute going to admit that I'm right in there being
>>> something wrong with those Github ZIPs.
>>>
>>> You didn't see the problem because you either obtained the source
>>> bundle elsewhere, or would have used only the .tar.gz version.
>>>
>>
>> Look, I have no idea if these are the same or different. I don't know,
>> and don't care. The only reason I was at the lua website at all was
>> because /you/ picked it as something that "proves" that make never works
>> on Windows. I went to the lua website, followed the instructions on how
>> to build lua on Windows, and it worked - using "make". /You/ did not
>> not follow the instructions,
>
> I downloaded an open source project like I've done a hundred others:
> from Github. It's usually expected to have everything needed to build
> the project, except for the actual tools.

And now you've learned that the "release" .tar.gz and .zip files
provided by GitHub are just snapshots of the git repo. Official source
releases are often generated from the git repo, with things like
documentation and configure scripts generated by the maintainers of the
project. Whether you can easily build something from a GitHub release
file depends on the project.

I suspect you resorted to the GitHub "release" files because lua.org
doesn't provide a zip file.

It's an understandable error -- and it gave you an excuse to complain
and insult people.

--
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 15/08/2023 23:55, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 15/08/2023 22:09, David Brown wrote:
>>> On 15/08/2023 19:49, Bart wrote:
>>>> You know, one thing is going 100% certain in this thread: you are
>>>> never for one minute going to admit that I'm right in there being
>>>> something wrong with those Github ZIPs.
>>>>
>>>> You didn't see the problem because you either obtained the source
>>>> bundle elsewhere, or would have used only the .tar.gz version.
>>>>
>>>
>>> Look, I have no idea if these are the same or different. I don't know,
>>> and don't care. The only reason I was at the lua website at all was
>>> because /you/ picked it as something that "proves" that make never works
>>> on Windows. I went to the lua website, followed the instructions on how
>>> to build lua on Windows, and it worked - using "make". /You/ did not
>>> not follow the instructions,
>>
>> I downloaded an open source project like I've done a hundred others:
>> from Github. It's usually expected to have everything needed to build
>> the project, except for the actual tools.
>
> And now you've learned that the "release" .tar.gz and .zip files
> provided by GitHub are just snapshots of the git repo. Official source
> releases are often generated from the git repo, with things like
> documentation and configure scripts generated by the maintainers of the
> project. Whether you can easily build something from a GitHub release
> file depends on the project.
>
> I suspect you resorted to the GitHub "release" files because lua.org
> doesn't provide a zip file.
>
> It's an understandable error -- and it gave you an excuse to complain
> and insult people.

But it's not understood by David Brown, and it gave him an excuse to
insult /me/.

In his book, it's impossible for anything to go wrong, so if I can't get
something to work, it HAS to be my fault. It can NEVER be the extra
opportunities for error that complex makefiles provide, or even simple ones.

No docs are too obscure or misleading (like lumping the 'mingw'
parameter needed for Windows under Unix-like systems)

And if can't make something work under ordinary Windows, my mistake is
not using Linux-like layers to keep the build process happy.

If even he has trouble pinning something on me (maybe somebody else
encountered the problem!) then of course it's because Windows is rubbish.

So, basically, I cannot win.

On 15/08/2023 14:22, Malcolm McLean wrote:
> On Tuesday, 15 August 2023 at 13:15:38 UTC+1, Bart wrote:
>> On 15/08/2023 11:53, Malcolm McLean wrote:
>>> On Tuesday, 15 August 2023 at 11:45:39 UTC+1, Bart wrote:
>>
>>>> I downloaded CMake to build Malcolm's project. I followed the
>>>> instructions and it didn't work.
>>>>
>>>> So, what do you want ME to do about that? Say that it is great anyway? I
>>>> say what I see.
>>>>
>>>> This project can be built trivially using:
>>>>
>>>> gcc *.c freetype\*.c samplerate\*.c
>>>>
>>>> So What Is The Point of using a heavyweight product like CMake? Try
>>>> selling THAT to me!
>>>>
>>> Well I'm the person responsible for that failure.
>>> Thank you very much for finding out that the instructions didn't work. I'm very close
>>> to packaging everything up into a release, and I don't want to release it with
>>> instructions that don't work.
>> My comment was a compliment not a criticism!
>>
>> Yes, there was implied criticism of CMake, but it was only highlighting
>> that having a complex dependency brings extra ways to fail.
>>
> Of course. So what went wrong?

I posted the results. But can't find that post (it was in that very long
thread), and I no longer have CMake.

But the gist of the main error was that it couldn't open 'nmake'. (There
were other things about something being deprecated.)

I don't know whether it expects that utility to be present, or why it
needs it, since the cmakelists.txt file didn't mention it.

If it is that, try hiding/renaming 'nmake' on your system (check by
typing 'nmake') to try and force the error.

On 2023-08-16, Bart <bc@freeuk.com> wrote:
> On 15/08/2023 23:55, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 15/08/2023 22:09, David Brown wrote:
>>>> On 15/08/2023 19:49, Bart wrote:
>>>>> You know, one thing is going 100% certain in this thread: you are
>>>>> never for one minute going to admit that I'm right in there being
>>>>> something wrong with those Github ZIPs.
>>>>>
>>>>> You didn't see the problem because you either obtained the source
>>>>> bundle elsewhere, or would have used only the .tar.gz version.
>>>>>
>>>>
>>>> Look, I have no idea if these are the same or different. I don't know,
>>>> and don't care. The only reason I was at the lua website at all was
>>>> because /you/ picked it as something that "proves" that make never works
>>>> on Windows. I went to the lua website, followed the instructions on how
>>>> to build lua on Windows, and it worked - using "make". /You/ did not
>>>> not follow the instructions,
>>>
>>> I downloaded an open source project like I've done a hundred others:
>>> from Github. It's usually expected to have everything needed to build
>>> the project, except for the actual tools.
>>
>> And now you've learned that the "release" .tar.gz and .zip files
>> provided by GitHub are just snapshots of the git repo. Official source
>> releases are often generated from the git repo, with things like
>> documentation and configure scripts generated by the maintainers of the
>> project. Whether you can easily build something from a GitHub release
>> file depends on the project.
>>
>> I suspect you resorted to the GitHub "release" files because lua.org
>> doesn't provide a zip file.
>>
>> It's an understandable error -- and it gave you an excuse to complain
>> and insult people.
>
> But it's not understood by David Brown, and it gave him an excuse to
> insult /me/.
>
> In his book, it's impossible for anything to go wrong, so if I can't get
> something to work, it HAS to be my fault. It can NEVER be the extra
> opportunities for error that complex makefiles provide, or even simple ones.
>
> No docs are too obscure or misleading (like lumping the 'mingw'
> parameter needed for Windows under Unix-like systems)
>
> And if can't make something work under ordinary Windows, my mistake is
> not using Linux-like layers to keep the build process happy.

The main C cross-platform problem between POSIX and Windows isn't
building, but the platforms being vastly different.

One way to port POSIX programs to Windows is to have a run-time
environment that has the needed POSIX support.

The projects which provide that tend to have the build environment also,
and of course that also helps.

If the library functions were there, but no build environment with make and
shell, that would be inconvenient. But less inconvenient than the
reverse: having the build environment, but crap POSIX libraries (situation with
all versions of MinGW).

I use Cygwin for building the Windows version of the TXR language.

For the run-time, I created a project which forks the Cygwin run-time.
I made some key alterations in the CYGWIN1.DLL to claw back some
of the ways in which the middleware emulates POSIX a little bit too
far.

The project is here:

https://www.kylheku.com/cygnal/

Cygnal makes it as easy as "humanly possible" to port your
Unix and Linux programs to Windows, and ship them to the users
such that the programs exhibit native-like conventions.

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

On 16/08/2023 00:36, Bart wrote:
>
> On 15/08/2023 22:09, David Brown wrote:
> > On 15/08/2023 19:49, Bart wrote:
> >
> >> You know, one thing is going 100% certain in this thread: you are
> >> never for one minute going to admit that I'm right in there being
> >> something wrong with those Github ZIPs.
> >>
> >> You didn't see the problem because you either obtained the source
> >> bundle elsewhere, or would have used only the .tar.gz version.
> >>
> >
> > Look, I have no idea if these are the same or different.  I don't know,
> > and don't care.  The only reason I was at the lua website at all was
> > because /you/ picked it as something that "proves" that make never works
> > on Windows.  I went to the lua website, followed the instructions on how
> > to build lua on Windows, and it worked - using "make".  /You/ did not
> > not follow the instructions,
>
> I downloaded an open source project like I've done a hundred others:
> from Github. It's usually expected to have everything needed to build
> the project, except for the actual tools.
>
> > and you got in trouble.  No doubt you'd
> > have got in trouble even if you did follow the instructions, because you
> > are always so determined to have everything fail.
>
> You don't see the failures because most open source software is
> developed for Unix-like OSes, so build systems are well-tested because
> so many will be using that and will have reported failures.
>

I use both Windows and Linux. I aim to use the system that is the best
choice for the task in hand, though of course many things can be done
equally on both. Like most people, I use the software I find most
convenient and most appropriate for the things I want to do and the way
I want to work. I have "msys2" on my Windows system - it is not
"cheating", or "not proper Windows", or "hiding" - it is a package made
for Windows that provides tools that some people find useful. Nothing
more, nothing less. Similarly, I have "wine" installed on my Linux
systems so that I can run Windows programs there - that is not cheating,
or "not proper Linux".

And when people want to install software to use on Windows or Linux, how
many want to compile the software from source in order to use the
software (as distinct from modify it or copy parts of it)? I'd guess
that for Linux, the figure is less than 0.1% of users - and for Windows,
0.01% or fewer. Virtually everyone wanting Lua on Windows will download
a binary installer. Virtually everyone wanting Lua on Linux will use
their package manager - "yum install lua", "apt-get install lua", or
whatever gui they like for their particular distribution. Even people
using source-based Linux distributions like Gentoo will not see that the
source code is downloaded and compiled on their system.

Building projects from source code is not always easy, and often does
not have detailed information about requirements, because it is not
something many people do, and those who do it, are usually experienced
developers. Github source code is for developers, not users, and it is
expected that people are seriously interested in the project and willing
to spend time reading documentation and learning about it. People go to
the lua github page because they are interested in lua development -
maybe adding extensions, or reporting issues, or looking at integrating
it as a scripting language in their own code. The contributors to the
github site are interested in enhancing and improving the lua compiler,
interpreter, runtime and libraries - they are not going to waste their
time writing idiot's guide to compiling on Windows. And they are not
interested in people who want to build the software just so that they
can say it compiled - they are interested in people who want to /use/
the software.

You appear to be under a misconception that the world revolves around
/you/, that everyone else should go out of their way to make life as
simple as possible for you and your peculiar and unique needs, and that
those who do not, are personally attacking you. I suspect you still
don't understand how unusual your position is - no matter how often you
find yourself at odds with everyone else in discussion threads.

> In addition, even for software that runs on Windows, you hide behind a
> wall of Linux utilities; using MSYS2 or WSL.
>
> So really, it's not surprising that everything works for you with hardly
> needing to lift a finger.

I try to make things work. /You/ try to make things fail. We both succeed.

>
> >> You know, I don't believe you actually know how to do this under plain
> >> Windows! Otherwise you would have done so; you must know that's what I
> >> use.)
> >>
> >
> > By /my/ ruling, any system with "bcc" or "tcc" is not plain Windows.
> > Therefore you failed.
>
> Huh? Those are compilers. You need a C compiler to turn .c files into
> .exe files. You don't need that other crap.
>

It's exactly the same - tools for the job.

>
> >> So, what have /you/ achieved?
> >>
> >
> > I did exactly what you claimed was impossible
>
> I said when I tried it, it failed.

No, /you/ failed to use "make". So really, you succeeded, since failure
was your goal. Well done.

On Wednesday, 16 August 2023 at 10:23:40 UTC+1, David Brown wrote:
>
> And when people want to install software to use on Windows or Linux, how
> many want to compile the software from source in order to use the
> software (as distinct from modify it or copy parts of it)? I'd guess
> that for Linux, the figure is less than 0.1% of users - and for Windows,
> 0.01% or fewer. Virtually everyone wanting Lua on Windows will download
> a binary installer. Virtually everyone wanting Lua on Linux will use
> their package manager - "yum install lua", "apt-get install lua", or
> whatever gui they like for their particular distribution. Even people
> using source-based Linux distributions like Gentoo will not see that the
> source code is downloaded and compiled on their system.
>
> Building projects from source code is not always easy, and often does
> not have detailed information about requirements, because it is not
> something many people do, and those who do it, are usually experienced
> developers. Github source code is for developers, not users, and it is
> expected that people are seriously interested in the project and willing
> to spend time reading documentation and learning about it. People go to
> the lua github page because they are interested in lua development -
> maybe adding extensions, or reporting issues, or looking at integrating
> it as a scripting language in their own code. The contributors to the
> github site are interested in enhancing and improving the lua compiler,
> interpreter, runtime and libraries - they are not going to waste their
> time writing idiot's guide to compiling on Windows. And they are not
> interested in people who want to build the software just so that they
> can say it compiled - they are interested in people who want to /use/
> the software.
>
My understanding of Lua is that, whilst it can be used as a standalone
language, it's really meant for adding scripting to applications. If you're
writing the game level editor then of course the programmer works
closely with the users, and it's acceptable to have the level editor
call a binary executable. But if you want scripting in the game itself then
you have to include the Lua source code.

S yes, users rather than developers of Lua itself have to be able to
incorporate it into a project and compile it easily.

On 16/08/2023 02:05, Bart wrote:
> On 15/08/2023 23:55, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 15/08/2023 22:09, David Brown wrote:
>>>> On 15/08/2023 19:49, Bart wrote:
>>>>> You know, one thing is going 100% certain in this thread: you are
>>>>> never for one minute going to admit that I'm right in there being
>>>>> something wrong with those Github ZIPs.
>>>>>
>>>>> You didn't see the problem because you either obtained the source
>>>>> bundle elsewhere, or would have used only the .tar.gz version.
>>>>>
>>>>
>>>> Look, I have no idea if these are the same or different.  I don't know,
>>>> and don't care.  The only reason I was at the lua website at all was
>>>> because /you/ picked it as something that "proves" that make never
>>>> works
>>>> on Windows.  I went to the lua website, followed the instructions on
>>>> how
>>>> to build lua on Windows, and it worked - using "make".  /You/ did not
>>>> not follow the instructions,
>>>
>>> I downloaded an open source project like I've done a hundred others:
>>> from Github. It's usually expected to have everything needed to build
>>> the project, except for the actual tools.
>>
>> And now you've learned that the "release" .tar.gz and .zip files
>> provided by GitHub are just snapshots of the git repo.  Official source
>> releases are often generated from the git repo, with things like
>> documentation and configure scripts generated by the maintainers of the
>> project.  Whether you can easily build something from a GitHub release
>> file depends on the project.
>>
>> I suspect you resorted to the GitHub "release" files because lua.org
>> doesn't provide a zip file.
>>
>> It's an understandable error -- and it gave you an excuse to complain
>> and insult people.
>

Actually, I am not sure it is an understandable error for Bart. In one
sense, Bart does not understand his error. In another sense, he is
familiar with github - he most certainly should know that it is for
development, and that code found there is often in flux, while released
versions from the project website will be more tested and more
appropriate for general use. And it is not understandable that he is
scared of tarballs.

> But it's not understood by David Brown, and it gave him an excuse to
> insult /me/.
>
> In his book, it's impossible for anything to go wrong, so if I can't get
> something to work, it HAS to be my fault. It can NEVER be the extra
> opportunities for error that complex makefiles provide, or even simple
> ones.

Oh, many things can go wrong. And it is quite possible for things to go
wrong that are /not/ your fault. But when you claim you're giving
things a fair test, yet fail to follow the simplest and most basic
instructions (despite being helped with pointers), that's not a fair
test. That is a determined intention to fail. (You are far too smart
and experienced to use inability or ignorance as an excuse.)

>
> No docs are too obscure or misleading (like lumping the 'mingw'
> parameter needed for Windows under Unix-like systems)
>
> And if can't make something work under ordinary Windows, my mistake is
> not using Linux-like layers to keep the build process happy.
>
> If even he has trouble pinning something on me (maybe somebody else
> encountered the problem!) then of course it's because Windows is rubbish.
>
> So, basically, I cannot win.
>

You can't win until you decide to try to listen, learn, experiment, and
progress as a developer. As long as your goal is to convince yourself
that the entire software world, other than yourself, is wrong, and all
tools other than your home-made systems are useless, unworkable and
unnecessary, then no - you cannot win.

No one is asking you to like C, gcc, make, Linux, or any other of your
pet hates. But it would be nice if you stopped spreading shite about them.

Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do
XXX in C, therefore it is an unusable disaster and my own language is
pure genius". Wouldn't that make a nice change, and make threads a bit
more friendly and useful?

On 15/08/2023 23:07, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 15/08/2023 20:48, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> My recent post goes into this in more detail. But, I've believe the
>>>> ZIP files from the Github Lua repository are incorrect.
>>> You're right.
>>> The GitHub repo for Lua is
>>> https://github.com/lua/lua
>>> It includes (not as part of the repo itself) a number of releases,
>>> including:
>>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
>>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
>>> The lua.org site provides a tarball:
>>> https://www.lua.org/ftp/lua-5.4.6.tar.gz
>>> I don't see any zip files on lua.org.
>>> The zipfile and tarball from the GitHub release match each other,
>>> but do
>>> not match the tarball from lua.org.
>>
>> OK, that one was my mistake then. But it means they're both wrong. And
>> if that Mr. DB had downloaded the source code from the Github, then
>> the make instructions he saw on lua.org would not have worked because
>> of a missing makefile.
>>
>>>> So, whose fault is that?
>>> I have no idea, but I hardly think comp.lang.c is the place to
>>> complain
>>> about it.
>>
>> What I'm complaining about is being falsely (and I believe
>> maliciously) accused of incompetence:
>
> You're far too quick to assume malice.
>
>> BC:
>>>> So, whose fault is that?
>>>
>> DB:
>>> Yours - you did not read the build instructions, but ploughed on with
>>> your own guesswork and got into trouble.
>
> I won't attempt to speak for DB, but I doubt that it occurred to him
> that the release files on GitHub differ so substantially from the
> .tar.gz files on lua.org.

It did not surprise me at all that they are different - github is
primarily for development, not standard tested releases. If you want to
download a proper release for a project, you go to the project website,
and follow the pointers there. (For some projects, the github pages and
readme.md /is/ the main website - but that is clearly not the case here.)

However, it did surprise me that the GitHub repository is /so/ different
from the released tarballs from the main site. The directory structures
are different, and the makefiles are significantly different - in the
release tarballs, they are aimed at configuring and installing (thus
having things like platform selection options), while in the GitHub they
are aimed at development (so lots of warning flags). The actual source
files seem the same.

>
>> That doesn't bother you I guess. Although this won't stop DB, who will
>> claim that of course I should have known that different kinds of
>> source 'tarballs' exist for the version of product, and only some of
>> them will work with the given build instructions.
>>
>> Although I did mention Github regarding Lua two days ago; you'd think
>> someone would have told me that was the wrong site to download source
>> code from, if it's so bleeding obvious.
>
> It's not obvious, and nobody has said that it is. I would have assumed
> that the release .tar.gz file from GitHub was similar to the .tar.gz
> file from lua.org until I checked.

Note, however, that people /did/ tell Bart to look at the build
instructions on the Lua site (including suggesting looking at the
"Detailed instructions").

And in the GitHub page, there is an "About" that says "The Lua
development repository, as seen by the Lua team. Mirrored irregularly."
There's a link to the project site.

>
>> As for who is at fault; I'd suggest:
>>
>> (1) The github site for not mentioning anything about it at all, like:
>> 'download the proper tarball from lua.org' if you want to build
>> it. (Why isn't that top layer present anyway?)
>
> GitHub release files are just packaged copies of the files in the repo.
> The release tarball from lua.org is built from that. For example, the
> GitHub repo includes documentation in what appears to be a
> project-specific format; the lua.org release includes generated man
> pages and html files.
>
> The README.md file says: "Download official Lua releases from Lua.org.".
>
> Yes, the presence of the "release" files on GitHub is misleading. Now
> that we've established that, can we stop complaining about it here?
>
> [...]
>

On 16/08/2023 11:34, Malcolm McLean wrote:
> On Wednesday, 16 August 2023 at 10:23:40 UTC+1, David Brown wrote:
>>
>> And when people want to install software to use on Windows or Linux, how
>> many want to compile the software from source in order to use the
>> software (as distinct from modify it or copy parts of it)? I'd guess
>> that for Linux, the figure is less than 0.1% of users - and for Windows,
>> 0.01% or fewer. Virtually everyone wanting Lua on Windows will download
>> a binary installer. Virtually everyone wanting Lua on Linux will use
>> their package manager - "yum install lua", "apt-get install lua", or
>> whatever gui they like for their particular distribution. Even people
>> using source-based Linux distributions like Gentoo will not see that the
>> source code is downloaded and compiled on their system.
>>
>> Building projects from source code is not always easy, and often does
>> not have detailed information about requirements, because it is not
>> something many people do, and those who do it, are usually experienced
>> developers. Github source code is for developers, not users, and it is
>> expected that people are seriously interested in the project and willing
>> to spend time reading documentation and learning about it. People go to
>> the lua github page because they are interested in lua development -
>> maybe adding extensions, or reporting issues, or looking at integrating
>> it as a scripting language in their own code. The contributors to the
>> github site are interested in enhancing and improving the lua compiler,
>> interpreter, runtime and libraries - they are not going to waste their
>> time writing idiot's guide to compiling on Windows. And they are not
>> interested in people who want to build the software just so that they
>> can say it compiled - they are interested in people who want to /use/
>> the software.
>>
> My understanding of Lua is that, whilst it can be used as a standalone
> language, it's really meant for adding scripting to applications.

Certainly embedding it within other applications is a major purpose of
the language, yes. It is becoming more mature as a stand-alone
language, with more libraries, but it is very popular for adding to
other programs. As you say, Lua is a common choice for scripting in
games. I used it myself as a scripting language in an embedded program,
many moons ago.

> If you're
> writing the game level editor then of course the programmer works
> closely with the users, and it's acceptable to have the level editor
> call a binary executable. But if you want scripting in the game itself then
> you have to include the Lua source code.
>
> S yes, users rather than developers of Lua itself have to be able to
> incorporate it into a project and compile it easily.
>

Sure. But if you want to do that, you read the relevant sections of the
manual and see which files you need, which options you want, what
configuration you want, and how you should combine it with your own
code. You need to know how to integrate Lua with your code - how your
application will start the Lua runtime or call Lua code, how the Lua
code will call /your/ functions (in C or whatever), how to wrap your
functions, variables, classes, etc., into Lua tables and functions.
There is a lot involved here - it's not a "download and compile" task.
But then, you wouldn't be doing this unless you actually wanted to use
Lua in your program and are willing to invest the effort to do so.

On Wednesday, 16 August 2023 at 11:52:46 UTC+1, David Brown wrote:
> On 16/08/2023 11:34, Malcolm McLean wrote:
> > On Wednesday, 16 August 2023 at 10:23:40 UTC+1, David Brown wrote:
> >>
> >> And when people want to install software to use on Windows or Linux, how
> >> many want to compile the software from source in order to use the
> >> software (as distinct from modify it or copy parts of it)? I'd guess
> >> that for Linux, the figure is less than 0.1% of users - and for Windows,
> >> 0.01% or fewer. Virtually everyone wanting Lua on Windows will download
> >> a binary installer. Virtually everyone wanting Lua on Linux will use
> >> their package manager - "yum install lua", "apt-get install lua", or
> >> whatever gui they like for their particular distribution. Even people
> >> using source-based Linux distributions like Gentoo will not see that the
> >> source code is downloaded and compiled on their system.
> >>
> >> Building projects from source code is not always easy, and often does
> >> not have detailed information about requirements, because it is not
> >> something many people do, and those who do it, are usually experienced
> >> developers. Github source code is for developers, not users, and it is
> >> expected that people are seriously interested in the project and willing
> >> to spend time reading documentation and learning about it. People go to
> >> the lua github page because they are interested in lua development -
> >> maybe adding extensions, or reporting issues, or looking at integrating
> >> it as a scripting language in their own code. The contributors to the
> >> github site are interested in enhancing and improving the lua compiler,
> >> interpreter, runtime and libraries - they are not going to waste their
> >> time writing idiot's guide to compiling on Windows. And they are not
> >> interested in people who want to build the software just so that they
> >> can say it compiled - they are interested in people who want to /use/
> >> the software.
> >>
> > My understanding of Lua is that, whilst it can be used as a standalone
> > language, it's really meant for adding scripting to applications.
> Certainly embedding it within other applications is a major purpose of
> the language, yes. It is becoming more mature as a stand-alone
> language, with more libraries, but it is very popular for adding to
> other programs. As you say, Lua is a common choice for scripting in
> games. I used it myself as a scripting language in an embedded program,
> many moons ago.
> > If you're
> > writing the game level editor then of course the programmer works
> > closely with the users, and it's acceptable to have the level editor
> > call a binary executable. But if you want scripting in the game itself then
> > you have to include the Lua source code.
> >
> > S yes, users rather than developers of Lua itself have to be able to
> > incorporate it into a project and compile it easily.
> >
> Sure. But if you want to do that, you read the relevant sections of the
> manual and see which files you need, which options you want, what
> configuration you want, and how you should combine it with your own
> code. You need to know how to integrate Lua with your code - how your
> application will start the Lua runtime or call Lua code, how the Lua
> code will call /your/ functions (in C or whatever), how to wrap your
> functions, variables, classes, etc., into Lua tables and functions.
> There is a lot involved here - it's not a "download and compile" task.
> But then, you wouldn't be doing this unless you actually wanted to use
> Lua in your program and are willing to invest the effort to do so.
>
I wonder if it's the answer for the problem of how to specify the output
format of pixels in the Baby X resource compiler?. It's a very heavy-weight
solution. But it would provide the necessary flexibility.

On 16/08/2023 02:20, Bart wrote:
> On 15/08/2023 14:22, Malcolm McLean wrote:
>> On Tuesday, 15 August 2023 at 13:15:38 UTC+1, Bart wrote:
>>> On 15/08/2023 11:53, Malcolm McLean wrote:
>>>> On Tuesday, 15 August 2023 at 11:45:39 UTC+1, Bart wrote:
>>>
>>>>> I downloaded CMake to build Malcolm's project. I followed the
>>>>> instructions and it didn't work.
>>>>>
>>>>> So, what do you want ME to do about that? Say that it is great
>>>>> anyway? I
>>>>> say what I see.
>>>>>
>>>>> This project can be built trivially using:
>>>>>
>>>>> gcc *.c freetype\*.c samplerate\*.c
>>>>>
>>>>> So What Is The Point of using a heavyweight product like CMake? Try
>>>>> selling THAT to me!
>>>>>
>>>> Well I'm the person responsible for that failure.
>>>> Thank you very much for finding out that the instructions didn't
>>>> work. I'm very close
>>>> to packaging everything up into a release, and I don't want to
>>>> release it with
>>>> instructions that don't work.
>>> My comment was a compliment not a criticism!
>>>
>>> Yes, there was implied criticism of CMake, but it was only highlighting
>>> that having a complex dependency brings extra ways to fail.
>>>
>> Of course. So what went wrong?
>
> I posted the results. But can't find that post (it was in that very long
> thread), and I no longer have CMake.
>
> But the gist of the main error was that it couldn't open 'nmake'. (There
> were other things about something being deprecated.)
>
> I don't know whether it expects that utility to be present, or why it
> needs it, since the cmakelists.txt file didn't mention it.
>
> If it is that, try hiding/renaming 'nmake' on your system (check by
> typing 'nmake') to try and force the error.
>

I can't remember the details of your post either (there's been a lot of
activity here recently). But were you attempting to install CMake on
Windows, or to /build/ CMake on Windows? Requiring "nmake" suggests you
were trying to build it - and the CMake website says you need an
existing binary of CMake in order to build CMake on Windows. (Yes, you
read that correctly. Please do not shoot the messenger.) The normal
way to get CMake on Windows, as on any platform, is to download a
pre-built binary.

On 16/08/2023 10:37, David Brown wrote:
> On 16/08/2023 02:05, Bart wrote:
>> But it's not understood by David Brown, and it gave him an excuse to
>> insult /me/.
>>
>> In his book, it's impossible for anything to go wrong, so if I can't
>> get something to work, it HAS to be my fault. It can NEVER be the
>> extra opportunities for error that complex makefiles provide, or even
>> simple ones.
>
> Oh, many things can go wrong. And it is quite possible for things to go
> wrong that are /not/ your fault. But when you claim you're giving
> things a fair test, yet fail to follow the simplest and most basic
> instructions (despite being helped with pointers), that's not a fair
> test.

I like how you tried desperately to make it all my fault. Oh, you should
have known this, should have known that. I bet you were surprised that
that Github repository was incomplete too!

> That is a determined intention to fail. (You are far too smart
> and experienced to use inability or ignorance as an excuse.)

You know, it really doesn't help when every makefile is called
'makefile'. Having specific names would have picked up my issue
instantly, since that particular project used two separate makefiles
both called 'makefile'.

You also know that that is a jolly good idea, but of course will never
admit it in a million years.

> You can't win until you decide to try to listen, learn, experiment, and
> progress as a developer.

You need to work a little more on being patronising.

> As long as your goal is to convince yourself
> that the entire software world, other than yourself, is wrong, and all
> tools other than your home-made systems are useless, unworkable and
> unnecessary, then no - you cannot win.

My battle is against unnecessary complex and bloat.

I like elegance and consistency in a programming language. I also like
that lessons are learned and things are improved.

I don't like elaborate solutions when simpler ones are far better.

I don't like clumsy, slow, error prone processes.

You're right that no one uses my stuff, but so what? You can think of it
as proof of concept that simpler, more elegant and more fool-proof
solutions can work.

Lua as a project is about the same size as many of mine. If written in
my language, the build process to creating lua.exe would be:

mm lua

The same on Linux if mm was ported there. (I have done that, the process
was ./mm lua). To create separate .exe and .dll, it might instead be 'mm
luac && mm -dll lualib'.

You can still use makefiles if you wish; they'd be rather short!

So my solutions are far advanced that the ones you use for C. You're
asking me, a developer, to step back a couple of decades to use obsolete
tools that people have been stuck with the same reasons that they have
to use -lm and get around a.out.

These days I'm more of a developer of languages than apps. And I
concentrate on aspects of language implementations that many ignore,
such as size, compactness, self-containment, speed, usability and
simplicity of the tool itself.

In short, I'm not a conformist.

> No one is asking you to like C, gcc, make, Linux, or any other of your
> pet hates. But it would be nice if you stopped spreading shite about
them.
>
> Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do
> XXX in C, therefore it is an unusable disaster and my own language is
> pure genius". Wouldn't that make a nice change, and make threads a bit
> more friendly and useful?

You can't change the language C. But most of this discussion has been on
aspects that are peripheral to the language, like those I touched on
above. And there things could be done differently.

Of course, you are NEVER going to admit that doing:

mm lua

might be a touch sweeter than those 330 lines of makefile crap below.

You can't do that in C, so there I used a solution what was 33 lines,
exactly 1/10th the size of the combined makefiles.

So, I'm on a hiding to nothing. You will always be convinced that I'm
some deviant that needs to brainwashed into taking the correct path and
having the right subservient attitudes, a bit like the protagonist at
the end of /1984/.

In any case, I'm done. I've deleted all my C compilers and all my C
related projects.

Including mine. But I'm keeping a ZIP in case I want to maintain it as a
test program; it's one of the best I have for my own language. Although
since it is for a C subset, I may develop that aspect, change it some
more, and give that language a different name.

Thank you for making 'C' and its development methods (and the attitudes
of its adherents) so unpalatable that I'm finally able to take that break.

(I'm still available for testing build systems, since I have a knack for
finding problems that seem to slip by everyone else!)

--------------------------------------------------------

# Makefile for installing Lua
# See doc/readme.html for installation and customization instructions.

# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================

# Your platform. See PLATS for possible values.
PLAT= guess

# Where to install. The installation starts in the src and doc directories,
# so take care if INSTALL_TOP is not an absolute path. See the local target.
# You may want to make INSTALL_LMOD and INSTALL_CMOD consistent with
# LUA_ROOT, LUA_LDIR, and LUA_CDIR in luaconf.h.
INSTALL_TOP= /usr/local
INSTALL_BIN= $(INSTALL_TOP)/bin
INSTALL_INC= $(INSTALL_TOP)/include
INSTALL_LIB= $(INSTALL_TOP)/lib
INSTALL_MAN= $(INSTALL_TOP)/man/man1
INSTALL_LMOD= $(INSTALL_TOP)/share/lua/$V
INSTALL_CMOD= $(INSTALL_TOP)/lib/lua/$V

# How to install. If your install program does not support "-p", then
# you may have to run ranlib on the installed liblua.a.
INSTALL= install -p
INSTALL_EXEC= $(INSTALL) -m 0755
INSTALL_DATA= $(INSTALL) -m 0644
# # If you don't have "install" you can use "cp" instead.
# INSTALL= cp -p
# INSTALL_EXEC= $(INSTALL)
# INSTALL_DATA= $(INSTALL)

# Other utilities.
MKDIR= mkdir -p
RM= rm -f

# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======

# Convenience platforms targets.
PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris

# What to install.
TO_BIN= lua luac
TO_INC= lua.h luaconf.h lualib.h lauxlib.h lua.hpp
TO_LIB= liblua.a
TO_MAN= lua.1 luac.1

# Lua version and release.
V= 5.4
R= $V.6

# Targets start here.
all: $(PLAT)

$(PLATS) help test clean:
@cd src && $(MAKE) $@

install: dummy
cd src && $(MKDIR) $(INSTALL_BIN) $(INSTALL_INC) $(INSTALL_LIB)
$(INSTALL_MAN) $(INSTALL_LMOD) $(INSTALL_CMOD)
cd src && $(INSTALL_EXEC) $(TO_BIN) $(INSTALL_BIN)
cd src && $(INSTALL_DATA) $(TO_INC) $(INSTALL_INC)
cd src && $(INSTALL_DATA) $(TO_LIB) $(INSTALL_LIB)
cd doc && $(INSTALL_DATA) $(TO_MAN) $(INSTALL_MAN)

uninstall:
cd src && cd $(INSTALL_BIN) && $(RM) $(TO_BIN)
cd src && cd $(INSTALL_INC) && $(RM) $(TO_INC)
cd src && cd $(INSTALL_LIB) && $(RM) $(TO_LIB)
cd doc && cd $(INSTALL_MAN) && $(RM) $(TO_MAN)

local:
$(MAKE) install INSTALL_TOP=../install

# make may get confused with install/ if it does not support .PHONY.
dummy:

# Echo config parameters.
echo:
@cd src && $(MAKE) -s echo
@echo "PLAT= $(PLAT)"
@echo "V= $V"
@echo "R= $R"
@echo "TO_BIN= $(TO_BIN)"
@echo "TO_INC= $(TO_INC)"
@echo "TO_LIB= $(TO_LIB)"
@echo "TO_MAN= $(TO_MAN)"
@echo "INSTALL_TOP= $(INSTALL_TOP)"
@echo "INSTALL_BIN= $(INSTALL_BIN)"
@echo "INSTALL_INC= $(INSTALL_INC)"
@echo "INSTALL_LIB= $(INSTALL_LIB)"
@echo "INSTALL_MAN= $(INSTALL_MAN)"
@echo "INSTALL_LMOD= $(INSTALL_LMOD)"
@echo "INSTALL_CMOD= $(INSTALL_CMOD)"
@echo "INSTALL_EXEC= $(INSTALL_EXEC)"
@echo "INSTALL_DATA= $(INSTALL_DATA)"

# Echo pkg-config data.
pc:
@echo "version=$R"
@echo "prefix=$(INSTALL_TOP)"
@echo "libdir=$(INSTALL_LIB)"
@echo "includedir=$(INSTALL_INC)"

# Targets that do not create files (not all makes understand .PHONY).
..PHONY: all $(PLATS) help test clean install uninstall local dummy echo pc

# (end of Makefile)
# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.

# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================

# Your platform. See PLATS for possible values.
PLAT= guess

CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra -DLUA_COMPAT_5_3 $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= -lm $(SYSLIBS) $(MYLIBS)

On 16/08/2023 11:57, David Brown wrote:
> On 16/08/2023 02:20, Bart wrote:

>> If it is that, try hiding/renaming 'nmake' on your system (check by
>> typing 'nmake') to try and force the error.
>>
>
> I can't remember the details of your post either (there's been a lot of
> activity here recently).  But were you attempting to install CMake on
> Windows, or to /build/ CMake on Windows?  Requiring "nmake" suggests you
> were trying to build it - and the CMake website says you need an
> existing binary of CMake in order to build CMake on Windows.  (Yes, you
> read that correctly.  Please do not shoot the messenger.)  The normal
> way to get CMake on Windows, as on any platform, is to download a
> pre-built binary.
>

CMake was installed, and the path to its main .exe file was in the PATH
variable.

I used Malcolm's instructions to build his project using CMake.