On Tuesday, 15 August 2023 at 12:56:15 UTC+3, Malcolm McLean wrote:
> On Tuesday, 15 August 2023 at 10:08:32 UTC+1, David Brown wrote:
> > On 14/08/2023 15:39, Bart wrote:
> > > On 14/08/2023 13:49, David Brown wrote:
> > > > On 13/08/2023 15:53, Bart wrote:
> > > >> OK. I'm surprised (since you say you work on embedded systems) that
> > > >> software for those can be so elaborate.
> > > >>
> > > >
> > > > I work on embedded systems - mostly microcontroller systems. But why
> > > > would that mean few files in a project? Like most programmers, I
> > > > organise my source files and split things up in logical sections. So
> > > > even the smallest of programs might have 15 or more C files. And this
> > > > particular program is not small, and includes things like a network
> > > > stack, an RTOS, and a large number of manufacturer-supplied driver files
> > > > in the microcontroller's SDK. The final binary is about 200 KB in size.
> > >
> > > So several different components. Would you really need to build all the
> > > other components when working on only one of them, if you didn't have a
> > > makefile to tell you where each belonged?
> > >
> > "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?
> >
> The problem with that is that the make files will contain 500 or more characters
> of lots of warning flags, carefully chosen options, pre-defined macros, directory
> paths for source code, object code, listing files, include paths, etc). It's OK
> whilst you are developing the project, because everything is set up just so.
>
> But what happens if you need to dust it off some years later? What if something
> goes wrong?
>
Then you get errors. Tools and languages change over time. Some are more
widely used and mature than others. Therefore likelihood of not finding something
that processes old makefiles is lower than not finding something that processes
say old .pro files of qmake.

> I'm not saying there's an easy answer.
>
> But code broke for me just this morning. Someone had added a test to the test suite,
> and messed with the CMake script so that it always searched for CppuTest instead
> of only when tests were being built. So it broke my build, and I was in the CMake files
> and git history, trying to work out what was wrong. But at least CMake gives good errors
> and has intuitive syntax.
>
CMake is designed to be more helpful than make indeed ... but try to sell that to
Bart then.

On 15/08/2023 10:00, David Brown wrote:
> On 14/08/2023 19:00, Bart wrote:
>> On 14/08/2023 16:49, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> So, how did you do it? I assume this is proper Windows and not WSL.
>>>>
>>>> On the downloaded source bundle from Github, there were no such
>>>> instructions.
>>>
>>> You've been pointed to the instructions more than once in this
>>> thread.
>>
>> And I've twice said I've found them.
>
> Apparently not.
>
>> I also said how I eventually managed to build that program (hint: it
>> didn't involve a makefile).
>>
>> But what those other commentators have not said is how they would
>> build it or have built it.
>
> I told you how /I/ built it on Windows - by following the instructions,
> using "make" on Windows. And now in another post I've given even more
> details, which I hope will answer all your questions.
>
>> With a working Windows makefile or not? I still don't know.
>
> You would have known if you'd read my post yesterday in which I said
> that is /exactly/ what I did.

Your post yesterday said this:

>I opened a command prompt on my Windows PC, downloaded lua source and
built it according to the "detailed instructions". All told, it took
about a minute, including reading the instructions. "make" on Windows
works fine.

You didn't say how you invoked it. Today you said it was "make mingw".
(But you also have a funny idea of what 'proper Windows' is. For me it
is not using CYGWIN, MSYS2 or WSL.)

For me it didn't work. Please post the makefile you used; it should only
be 210 lines. If isn't 210 lines, then that can explain some things.

>> I do know that all 5 projects I mentioned could be trivially built
>> with the simplest script. Yet all through the other thread everybody
>> was pushing make and makefiles.
>>
>
> Probably all projects /could/ be built with scripts - though for many
> projects, it would not be trivial. But that does not make scripts the
> best choice for building them. And such scripts are certainly not the
> best choice when developing projects (as distinct from distributing
> complete ready-to-use projects, which is a very different thing).

I've used simple lists of source files for developing software for my
whole career.

But then, I've always taken care of everything to do with development,
and written all the software which I use at the source code level.

So I've been able to ensure the process was always usable, simple, and
fast. Even using floppies.

>> But then you always make these drive-past comments in claiming
>> something that isn't true, or suggesting I'm lying about something, or
>> saying my in-house languages were hobby projects, and never back them
>> up or admit you were wrong.
>>
>> It seems like a personal campaign against me.
>>
>
> When you are saying one thing, and everyone else is saying something
> different, does it ever occur to you that perhaps /you/ are the one that
> is in the wrong?

When I complain about people deifying C, you say but of course other
people can see its shortcomings.

But 'make' really is perfect? I find it totally and utterly unusable.
And yes I have tried to read the 240-page manual, I gave up on page 10.

And as explained, I have tried to use other people's makefiles, and
found them prone to failures. But since they are so impenetrable, I
can't fix them.

As a language designer it just offended me. That must be a better way to
do what it does, if it that is even necessary.

>
> This is not a "campaign against you". These threads are (for me, at
> least), an attempt to educate you and help you at least appreciate why
> other people use tools like make and gcc, even if /you/ don't like them.
> And they are also to counter misinformation and confusion that you
> post - other people might read your posts and think they are accurate or
> represent reality for C development.

People will read YOUR posts and get the idea that if THEY find 'make'
hard going, then it must be their fault for being too thick or not
having the right aptitude.

Since it can't possibly be because make is a terrible language.

And YES, simple solutions can work, the KISS principle.

On Tuesday, 15 August 2023 at 13:08:13 UTC+3, Bart wrote:
> On 15/08/2023 08:54, David Brown wrote:
>
> > Is it /that/ hard to read a few lines on a webpage?
>
> Hand-on-heart, would you say that page was clearly written for Windows
> users?

You mean that page? <http://lua-users.org/wiki/BuildingLua>
IMHO it explains all ways of building it on Windows in detail. That is good
indeed as no one knows maybe our use case involves vc6 or borland c
or whatever.
You are directed there for example by <https://www.lua.org/faq.html#1.1>
And FAQ link is right on download page <https://www.lua.org/download.html>
"If you have trouble building lua read faq"

Or maybe you talk of some other page. I don't know for me the helpfulness
there is on side of impressive. Have enjoyed commercial products order
of magnitude worse supported.

On 15/08/2023 11:23, Öö Tiib wrote:
> On Tuesday, 15 August 2023 at 12:56:15 UTC+3, Malcolm McLean wrote:
>> On Tuesday, 15 August 2023 at 10:08:32 UTC+1, David Brown wrote:
>>> On 14/08/2023 15:39, Bart wrote:
>>>> On 14/08/2023 13:49, David Brown wrote:
>>>>> On 13/08/2023 15:53, Bart wrote:
>>>>>> OK. I'm surprised (since you say you work on embedded systems) that
>>>>>> software for those can be so elaborate.
>>>>>>
>>>>>
>>>>> I work on embedded systems - mostly microcontroller systems. But why
>>>>> would that mean few files in a project? Like most programmers, I
>>>>> organise my source files and split things up in logical sections. So
>>>>> even the smallest of programs might have 15 or more C files. And this
>>>>> particular program is not small, and includes things like a network
>>>>> stack, an RTOS, and a large number of manufacturer-supplied driver files
>>>>> in the microcontroller's SDK. The final binary is about 200 KB in size.
>>>>
>>>> So several different components. Would you really need to build all the
>>>> other components when working on only one of them, if you didn't have a
>>>> makefile to tell you where each belonged?
>>>>
>>> "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?
>>>
>> The problem with that is that the make files will contain 500 or more characters
>> of lots of warning flags, carefully chosen options, pre-defined macros, directory
>> paths for source code, object code, listing files, include paths, etc). It's OK
>> whilst you are developing the project, because everything is set up just so.
>>
>> But what happens if you need to dust it off some years later? What if something
>> goes wrong?
>>
> Then you get errors. Tools and languages change over time. Some are more
> widely used and mature than others. Therefore likelihood of not finding something
> that processes old makefiles is lower than not finding something that processes
> say old .pro files of qmake.
>
>> I'm not saying there's an easy answer.
>>
>> But code broke for me just this morning. Someone had added a test to the test suite,
>> and messed with the CMake script so that it always searched for CppuTest instead
>> of only when tests were being built. So it broke my build, and I was in the CMake files
>> and git history, trying to work out what was wrong. But at least CMake gives good errors
>> and has intuitive syntax.
>>
> CMake is designed to be more helpful than make indeed ... but try to sell that to
> Bart then.

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!

On Tuesday, 15 August 2023 at 11:45:39 UTC+1, Bart wrote:
> On 15/08/2023 11:23, Öö Tiib wrote:
> > On Tuesday, 15 August 2023 at 12:56:15 UTC+3, Malcolm McLean wrote:
> >> On Tuesday, 15 August 2023 at 10:08:32 UTC+1, David Brown wrote:
> >>> On 14/08/2023 15:39, Bart wrote:
> >>>> On 14/08/2023 13:49, David Brown wrote:
> >>>>> On 13/08/2023 15:53, Bart wrote:
> >>>>>> OK. I'm surprised (since you say you work on embedded systems) that
> >>>>>> software for those can be so elaborate.
> >>>>>>
> >>>>>
> >>>>> I work on embedded systems - mostly microcontroller systems. But why
> >>>>> would that mean few files in a project? Like most programmers, I
> >>>>> organise my source files and split things up in logical sections. So
> >>>>> even the smallest of programs might have 15 or more C files. And this
> >>>>> particular program is not small, and includes things like a network
> >>>>> stack, an RTOS, and a large number of manufacturer-supplied driver files
> >>>>> in the microcontroller's SDK. The final binary is about 200 KB in size.
> >>>>
> >>>> So several different components. Would you really need to build all the
> >>>> other components when working on only one of them, if you didn't have a
> >>>> makefile to tell you where each belonged?
> >>>>
> >>> "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?
> >>>
> >> The problem with that is that the make files will contain 500 or more characters
> >> of lots of warning flags, carefully chosen options, pre-defined macros, directory
> >> paths for source code, object code, listing files, include paths, etc).. It's OK
> >> whilst you are developing the project, because everything is set up just so.
> >>
> >> But what happens if you need to dust it off some years later? What if something
> >> goes wrong?
> >>
> > Then you get errors. Tools and languages change over time. Some are more
> > widely used and mature than others. Therefore likelihood of not finding something
> > that processes old makefiles is lower than not finding something that processes
> > say old .pro files of qmake.
> >
> >> I'm not saying there's an easy answer.
> >>
> >> But code broke for me just this morning. Someone had added a test to the test suite,
> >> and messed with the CMake script so that it always searched for CppuTest instead
> >> of only when tests were being built. So it broke my build, and I was in the CMake files
> >> and git history, trying to work out what was wrong. But at least CMake gives good errors
> >> and has intuitive syntax.
> >>
> > CMake is designed to be more helpful than make indeed ... but try to sell that to
> > Bart then.
> 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.
As you say, at least there is a fallback. But that's not really good enough..

The point of CMake is that a lot of people will want to look at the code in an IDE.

On 15/08/2023 11:42, Öö Tiib wrote:
> On Tuesday, 15 August 2023 at 13:08:13 UTC+3, Bart wrote:
>> On 15/08/2023 08:54, David Brown wrote:
>>
>>> Is it /that/ hard to read a few lines on a webpage?
>>
>> Hand-on-heart, would you say that page was clearly written for Windows
>> users?
>
> You mean that page? <http://lua-users.org/wiki/BuildingLua>
> IMHO it explains all ways of building it on Windows in detail. That
is good
> indeed as no one knows maybe our use case involves vc6 or borland c
> or whatever.
>
> You are directed there for example by <https://www.lua.org/faq.html#1.1>
> And FAQ link is right on download page
<https://www.lua.org/download.html>
> "If you have trouble building lua read faq"
>
> Or maybe you talk of some other page. I don't know for me the helpfulness
> there is on side of impressive. Have enjoyed commercial products order
> of magnitude worse supported.
>

From what Ben and David have said, the start point appears to be this:

https://www.lua.org/

This is the site mentioned in the makefile in the sources. Clicking on
/downloads/ as I think Ben said (remember I've already downloaded the
sources), takes you here:

https://www.lua.org/download.html

Under Building it says 'Lua is very easy to build and install'. There is
a linked called 'detailed instructions' which has been mentioned by BB
and DB, which takes you to:

https://www.lua.org/manual/5.4/readme.html

This is the page I'm referring to.

Your link does at least mention 'make mingw' directly, but also in the
context of mingw-msys; I don't know what that is. In all it is a lot
more complicated and confusing.

To build 5.4.6, from the top-level folder lua-5.4.6 which contains all
the .c and .h files, I created this file 'fred' (using 'dir/b *.c >fred,
then editing to remove the ones not needed, like luac.c), which contains:

lua.c
lapi.c
lcode.c
lctype.c
ldebug.c
ldo.c
ldump.c
lfunc.c
lgc.c
llex.c
lmem.c
lobject.c
lopcodes.c
lparser.c
lstate.c
lstring.c
ltable.c
ltm.c
lundump.c
lvm.c
lzio.c
lauxlib.c
lbaselib.c
lcorolib.c
ldblib.c
liolib.c
lmathlib.c
loadlib.c
loslib.c
lstrlib.c
ltablib.c
lutf8lib.c
linit.c

(Note: lua.c being first means no output file needed for bcc/lcc, as
they use the name of the first file.)

I then typed:

gcc -lua @fred

to get lua.exe. Now you can tweak the build using -O3 and -s for
example. Those options get you a 350KB executable.

Using 'bcc -old @fred' gets me a 340KB lua.exe. While 'tcc @fred'
creates a 370KB one.

I even started WSL, and typed this (note it needs that utterly pointless
-lm flag):

gcc -lua @fred -lm

and got lua (that is, the executable file 'lua'; an extension would be
useful!) running under Linux. So my simple script is cross-platform too!

THAT is simple. Now tell me what CMake would bring to the table.

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.

> As you say, at least there is a fallback. But that's not really good enough.

> The point of CMake is that a lot of people will want to look at the code in an IDE.

I'm not sure what the connection is between CMake and IDEs. Don't the
latter have a built-in way of displaying all the sources files in the
currrent and nested directories?

On Tuesday, 15 August 2023 at 14:15:03 UTC+3, Bart wrote:
> On 15/08/2023 11:42, Öö Tiib wrote:
> > On Tuesday, 15 August 2023 at 13:08:13 UTC+3, Bart wrote:
> >> On 15/08/2023 08:54, David Brown wrote:
> >>
> >>> Is it /that/ hard to read a few lines on a webpage?
> >>
> >> Hand-on-heart, would you say that page was clearly written for Windows
> >> users?
> >
> > You mean that page? <http://lua-users.org/wiki/BuildingLua>
> > IMHO it explains all ways of building it on Windows in detail. That
> is good
> > indeed as no one knows maybe our use case involves vc6 or borland c
> > or whatever.
> >
> > You are directed there for example by <https://www.lua.org/faq.html#1.1 " rel="nofollow" target="_blank">https://www.lua.org/faq.html#1.1>
> > And FAQ link is right on download page
> <https://www.lua.org/download.html " rel="nofollow" target="_blank">https://www.lua.org/download.html>
> > "If you have trouble building lua read faq"
> >
> > Or maybe you talk of some other page. I don't know for me the helpfulness
> > there is on side of impressive. Have enjoyed commercial products order
> > of magnitude worse supported.
> >
> From what Ben and David have said, the start point appears to be this:
>
> https://www.lua.org/
>
> This is the site mentioned in the makefile in the sources. Clicking on
> /downloads/ as I think Ben said (remember I've already downloaded the
> sources), takes you here:
>
> https://www.lua.org/download.html
>
> Under Building it says 'Lua is very easy to build and install'. There is
> a linked called 'detailed instructions' which has been mentioned by BB
> and DB, which takes you to:
>
> https://www.lua.org/manual/5.4/readme.html
>
> This is the page I'm referring to.
>
Yes, it also suggests mingw as xxx for make xxx, when plain make doesn't
cut it.

> Your link does at least mention 'make mingw' directly, but also in the
> context of mingw-msys; I don't know what that is. In all it is a lot
> more complicated and confusing.
>
The MinGW is runtime environment on Windows. Currently there
is advancement project MinGW-w64. The MSYS is collection of tools
and libraries compatible with MinGW ... it has also advancement
project MSYS2.

Nothing to do, decades old platform like Windows has accumulated
several production tool stacks over time and so there are no one-liner
answer that satisfies users of all of those.

> To build 5.4.6, from the top-level folder lua-5.4.6 which contains all
> the .c and .h files, I created this file 'fred' (using 'dir/b *.c >fred,
> then editing to remove the ones not needed, like luac.c), which contains:
>
> lua.c
> lapi.c
> lcode.c
> lctype.c
> ldebug.c
> ldo.c
> ldump.c
> lfunc.c
> lgc.c
> llex.c
> lmem.c
> lobject.c
> lopcodes.c
> lparser.c
> lstate.c
> lstring.c
> ltable.c
> ltm.c
> lundump.c
> lvm.c
> lzio.c
> lauxlib.c
> lbaselib.c
> lcorolib.c
> ldblib.c
> liolib.c
> lmathlib.c
> loadlib.c
> loslib.c
> lstrlib.c
> ltablib.c
> lutf8lib.c
> linit.c
>
> (Note: lua.c being first means no output file needed for bcc/lcc, as
> they use the name of the first file.)
>
That is interpreter. Typically people might want all of lua (the interpreter),
luac (the compiler), and liblua (the library). Lua's main appeal is that it
is embeddable script engine, and so most usual usage of it is for to make
a product scriptable.

> I then typed:
>
> gcc -lua @fred
>
> to get lua.exe. Now you can tweak the build using -O3 and -s for
> example. Those options get you a 350KB executable.
>
> Using 'bcc -old @fred' gets me a 340KB lua.exe. While 'tcc @fred'
> creates a 370KB one.
>
> I even started WSL, and typed this (note it needs that utterly pointless
> -lm flag):
>
> gcc -lua @fred -lm
>
> and got lua (that is, the executable file 'lua'; an extension would be
> useful!) running under Linux. So my simple script is cross-platform too!
>
> THAT is simple. Now tell me what CMake would bring to the table.
>
The CMake is compiler-independent. So it allows easier integration to
more varying tools and tool stacks. You might want programmers to
edit same product in both Android Studio and XCode, build the product
differently instrumented automatically on continuous integration,
deploy it to various test systems automatically, test it there automatically,
produce reports etc. Without CMake it all is of course possible but may
take too much work time of people who can do something more
interesting.

In article <ubfeqj$2oop4$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
....
>This is not a "campaign against you".

Of course it is.

But it is absolutely obligatory, when launching a campaign against someone,
to deny that you are doing so. So, well done. You are sticking to form.

--
"Unattended children will be given an espresso and a free kitten."

On 15/08/2023 12:40, Bart wrote:
> On 15/08/2023 10:00, David Brown wrote:
> > On 14/08/2023 19:00, Bart wrote:
> >> On 14/08/2023 16:49, Scott Lurndal wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>
> >>>> So, how did you do it? I assume this is proper Windows and not WSL.
> >>>>
> >>>> On the downloaded source bundle from Github, there were no such
> >>>> instructions.
> >>>
> >>> You've been pointed to the instructions more than once in this
> >>> thread.
> >>
> >> And I've twice said I've found them.
> >
> > Apparently not.
> >
> >> I also said how I eventually managed to build that program (hint: it
> >> didn't involve a makefile).
> >>
> >> But what those other commentators have not said is how they would
> >> build it or have built it.
> >
> > I told you how /I/ built it on Windows - by following the instructions,
> > using "make" on Windows.  And now in another post I've given even more
> > details, which I hope will answer all your questions.
> >
> >> With a working Windows makefile or not? I still don't know.
> >
> > You would have known if you'd read my post yesterday in which I said
> > that is /exactly/ what I did.
>
> Your post yesterday said this:
>
> >I opened a command prompt on my Windows PC, downloaded lua source and
> built it according to the "detailed instructions".  All told, it took
> about a minute, including reading the instructions.  "make" on Windows
> works fine.
>
> You didn't say how you invoked it. Today you said it was "make mingw".

I gave more details today, yes - but yesterday I had already said I used
"make".

> (But you also have a funny idea of what 'proper Windows' is. For me it
> is not using CYGWIN, MSYS2 or WSL.)

What a truly bizarre "No true Scotsman" argument! Would you also say
that it is impossible to write documents on "proper Windows" because
Windows doesn't come with a word processor?

>
> For me it didn't work. Please post the makefile you used; it should only
> be 210 lines. If isn't 210 lines, then that can explain some things.

I downloaded the tarball referenced (lua-5.4.6.tar.gz). There is a
Makefile in the main directory, of 106 lines, and a Makefile in the src
directory of 225 lines.

Did you not even /try/ to follow the instructions before complaining
that nothing worked for you?

> > When you are saying one thing, and everyone else is saying something
> > different, does it ever occur to you that perhaps /you/ are the one that
> > is in the wrong?
>
> When I complain about people deifying C, you say but of course other
> people can see its shortcomings.

No one thinks C is perfect.

>
> But 'make' really is perfect?

No one thinks "make" is perfect.

> I find it totally and utterly unusable.

That's just you. Plenty of people find it entirely usable, and
extremely useful. Other people find it hard to use, or prefer other tools.

You are not unique in disliking "make", or not finding it useful. But I
think you /are/ unique in how strongly you are convinced that you,
personally, are the only one who understands how terrible and useless
tools such as "make", "gcc", and the C language are, and how everyone
else who believes they have been using these tools for nearly 50 years
is just imagining that they work.

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?
> > As you say, at least there is a fallback. But that's not really good enough.
>
> > The point of CMake is that a lot of people will want to look at the code in an IDE.
> I'm not sure what the connection is between CMake and IDEs. Don't the
> latter have a built-in way of displaying all the sources files in the
> currrent and nested directories?
>
You've got to set up a project and import all the files into it. Whilst it's not hard
thing to do, it takes a minute or so, and that's enough to be barrier to someone
wanting to use the code.
Wiht CMake you type cmake -G <your IDE generator> .. and it makes an IDE for
you,
CMake has a "source group" command which groups source files and gives it a
hint what the navigation sidebar of the IDE should hold.

On 15/08/2023 11:56, Malcolm McLean wrote:
> On Tuesday, 15 August 2023 at 10:08:32 UTC+1, David Brown wrote:
>> On 14/08/2023 15:39, Bart wrote:
>>> On 14/08/2023 13:49, David Brown wrote:
>>>> On 13/08/2023 15:53, Bart wrote:
>>>>> OK. I'm surprised (since you say you work on embedded systems) that
>>>>> software for those can be so elaborate.
>>>>>
>>>>
>>>> I work on embedded systems - mostly microcontroller systems. But why
>>>> would that mean few files in a project? Like most programmers, I
>>>> organise my source files and split things up in logical sections. So
>>>> even the smallest of programs might have 15 or more C files. And this
>>>> particular program is not small, and includes things like a network
>>>> stack, an RTOS, and a large number of manufacturer-supplied driver files
>>>> in the microcontroller's SDK. The final binary is about 200 KB in size.
>>>
>>> So several different components. Would you really need to build all the
>>> other components when working on only one of them, if you didn't have a
>>> makefile to tell you where each belonged?
>>>
>> "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?
>>
> The problem with that is that the make files will contain 500 or more characters
> of lots of warning flags, carefully chosen options, pre-defined macros, directory
> paths for source code, object code, listing files, include paths, etc). It's OK
> whilst you are developing the project, because everything is set up just so.
>
> But what happens if you need to dust it off some years later? What if something
> goes wrong?
>

I /do/ dust it off some years later. My record is making a change to a
customer program a few months shy of 20 years after I had last used it.
I unpacked it from my archives, on a completely different computer,
typed "make" and checked that the binary was identical to the archived
binary.

This is one of the reasons why I use make - I want /exactly/ the same
results, every time, on every machine. (Toolchains are obviously also
part of my archives.)

If you want to support multiple different compilers and versions on
different systems, that's fine too. Clearly you will not be using so
many different flags as I do, but few projects need that many. Most
people will find "-O2 -Wall" to cover many use-cases, but that's for
different kinds of development than I do.

And makefiles let you easily use variables to handle things like
different compiler paths, or common sets of flags - this is quite
normal. That means that even if you do need to make changes when moving
to a different host or different compiler, you only need to change a few
variables, not every invocation line for the compiler.

> I'm not saying there's an easy answer.

And I am not saying "make" is perfect, or will solve every potential
problem - but it can do a great deal to help.

>
> But code broke for me just this morning. Someone had added a test to the test suite,
> and messed with the CMake script so that it always searched for CppuTest instead
> of only when tests were being built. So it broke my build, and I was in the CMake files
> and git history, trying to work out what was wrong. But at least CMake gives good errors
> and has intuitive syntax.

Debugging is part of life for any tools.

On Tuesday, 15 August 2023 at 14:31:08 UTC+1, David Brown wrote:
> On 15/08/2023 11:56, Malcolm McLean wrote:
>
> > But what happens if you need to dust it off some years later? What if something
> > goes wrong?
> >
> I /do/ dust it off some years later. My record is making a change to a
> customer program a few months shy of 20 years after I had last used it.
> I unpacked it from my archives, on a completely different computer,
> typed "make" and checked that the binary was identical to the archived
> binary.
>
> This is one of the reasons why I use make - I want /exactly/ the same
> results, every time, on every machine. (Toolchains are obviously also
> part of my archives.)
>
I don't want exactly the same binaries. I would hope that compilers in 20
years' time would produce slightly more efficient code than modern ones.
And of course new processors might have been developed. And whilst exactly
the same results bit for bit would be nice, it's no practical to expect it, because
of a certain amount of slop in floating point calculations.
>
But you see the wisdom of using the Baby X resource compiler instead of the
Python scripts that call external dependencies. If you want to package up
everything so it's reproducible, you can package the Baby X resource
compiler source, and, because it has no dependencies other than the standard
library, compile it.
>
> If you want to support multiple different compilers and versions on
> different systems, that's fine too. Clearly you will not be using so
> many different flags as I do, but few projects need that many. Most
> people will find "-O2 -Wall" to cover many use-cases, but that's for
> different kinds of development than I do.
>
I've discovered the clang fsanitizer flag which is great for debug builds.
But I don't need any options to get the correct results, except
CRT_SECURE_NO_WARNINGS on Windows.
>
> And makefiles let you easily use variables to handle things like
> different compiler paths, or common sets of flags - this is quite
> normal. That means that even if you do need to make changes when moving
> to a different host or different compiler, you only need to change a few
> variables, not every invocation line for the compiler.
>
The problem is that even a tiny change can mean "you've messed with it.
So any problems are no longer our responsibility. You're on your own."
>
> > I'm not saying there's an easy answer.
> And I am not saying "make" is perfect, or will solve every potential
> problem - but it can do a great deal to help.
> >
> > But code broke for me just this morning. Someone had added a test to the test suite,
> > and messed with the CMake script so that it always searched for CppuTest instead
> > of only when tests were being built. So it broke my build, and I was in the CMake files
> > and git history, trying to work out what was wrong. But at least CMake gives good errors
> > and has intuitive syntax.
> Debugging is part of life for any tools.
>
Exactly. Which is where make isn't very good and CMake is much better.

On 2023-08-15, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Tuesday, 15 August 2023 at 14:31:08 UTC+1, David Brown wrote:
>> On 15/08/2023 11:56, Malcolm McLean wrote:
>>
>> > But what happens if you need to dust it off some years later? What if something
>> > goes wrong?
>> >
>> I /do/ dust it off some years later. My record is making a change to a
>> customer program a few months shy of 20 years after I had last used it.
>> I unpacked it from my archives, on a completely different computer,
>> typed "make" and checked that the binary was identical to the archived
>> binary.
>>
>> This is one of the reasons why I use make - I want /exactly/ the same
>> results, every time, on every machine. (Toolchains are obviously also
>> part of my archives.)
>>
> I don't want exactly the same binaries. I would hope that compilers in 20
> years' time would produce slightly more efficient code than modern ones.

I suspect David wants the same results when the same compiler
installation is used to compile the same code baseline.

This is called reproducibility and is a worthwhile feature of the change
management. Arguably, you don't have change management nailed down right
if you can't build again, bit for bit, something you built a week,
month or year ago.

Some GNU/Linux distros have made reproducibility a goal. So for instance
there are environment variables for freezing the build time that goes
into __DATE__ and __TIME__, and such. It's a bit involved. Everything
has to be bit exact, including generated documentation. Tools like
PDF generators that put time stamps into documents become problematic.

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

On 15/08/2023 13:53, Öö Tiib wrote:
> On Tuesday, 15 August 2023 at 14:15:03 UTC+3, Bart wrote:
>> https://www.lua.org/manual/5.4/readme.html

>> This is the page I'm referring to.
>>
> Yes, it also suggests mingw as xxx for make xxx, when plain make doesn't
> cut it.

If your read my post, it suggests that in a section whose first line
talks about Unix-like systems, with xxx in a list of mostly Unix-based
OSes, in a page where later on there is a separate section devoted to
building it on 'other systems', and which starts off saying 'if you're
not using the usual Unix tools', someone could well be forgiven for
missing it.

Especially if scanning for Windows-build information.

Of course, after I said I couldn't see it, you all minutely scrutinised
every line of it, and or maybe you started off in the Unix-specific
section out of habit, while /I/ skip it out of habit.

There is no reason to make it hard.

Why is Windows, the world's mostly popular OS and most successful OS in
the 1990s, barely mentioned? If I go into a computer shop even now and
buy a desktop PC, it will likely have Windows installed.

So there is no reason, other than churlishness, not to have a section
titled:

Building Lua on Microsoft Windows

But they'd better make sure that 'make mingw' works. The 210-line
makefile in the downloads, I'm pretty sure is not the one they have in
mind here.

If I instead download a .tgz version of Lua from here:
http://www.lua.org/ftp/, then sure enough the makefile there is 160
lines and looks at the supplied platform parameter.

But that is not the only thing: the directory structure is different
with sources in ./src, not at the top level.

The source I got from Github, either from 'Download ZIP' or the
source-code .zip from Releases, had a different structure and makefile.
Both lots are for 5.4.6.

But the .tar.gz version from Releases has the correct structure and
makefile and I believe matchs the releases from lua.org.

So the problem appears to be this:

On GitHUB, the .zip and .tar.gz versions differ in their contents. The
folder structure is different, and the makefile is different.

Oddly, the .zip version, usually associated with Windows, has a makefile
that doesn't build under Windows, and if I try it under Linux, fails to
link symbols because of that are part of WinAPI.

So, there appears to be an actual problem with that Github repository.

But I bet I'm not going to get any apologies: I'm still just a bumbling,
incompetent idiot.

I'm also the idiot that highlighted clarity issues in the Readme file,
and discovered a discrepancy in the .zip and .tar.gz versions.

The Github directory displayed, and the makefile, are also incorrect as
they correspond to the ZIP versions.

>> Your link does at least mention 'make mingw' directly, but also in the
>> context of mingw-msys; I don't know what that is. In all it is a lot
>> more complicated and confusing.
>>
> The MinGW is runtime environment on Windows. Currently there
> is advancement project MinGW-w64. The MSYS is collection of tools
> and libraries compatible with MinGW ... it has also advancement
> project MSYS2.
I have mingw which I believe refers to implementations of gcc on Windows.

MSYS is a separate product.

>
> Nothing to do, decades old platform like Windows has accumulated
> several production tool stacks over time and so there are no one-liner
> answer that satisfies users of all of those.
There is always plain Windows. CYGWIN, MSYS2 and WSL are just extra
layers. Ones that are necessary for a project as simple as this.

On 15/08/2023 15:58, Malcolm McLean wrote:
> On Tuesday, 15 August 2023 at 14:31:08 UTC+1, David Brown wrote:
>> On 15/08/2023 11:56, Malcolm McLean wrote:
>>
>>> But what happens if you need to dust it off some years later? What if something
>>> goes wrong?
>>>
>> I /do/ dust it off some years later. My record is making a change to a
>> customer program a few months shy of 20 years after I had last used it.
>> I unpacked it from my archives, on a completely different computer,
>> typed "make" and checked that the binary was identical to the archived
>> binary.
>>
>> This is one of the reasons why I use make - I want /exactly/ the same
>> results, every time, on every machine. (Toolchains are obviously also
>> part of my archives.)
>>
> I don't want exactly the same binaries. I would hope that compilers in 20
> years' time would produce slightly more efficient code than modern ones.

That's fine for many uses. For embedded systems, and other situations
where you want high reliability and repeatability, you want repeatable
builds. (It's become increasingly of interest in the Linux world too -
Debian, for example, has an ongoing project to make its entire source
base support repeatable builds.)

I generally aim for the most modern practical toolchain for new
projects, but once a project is solidly established and real versions
are delivered to the customer, I won't change toolchains without very
good reason. The possibility of introducing new bugs or issues is
unacceptable - long term testing is of a binary, not of source code.

> And of course new processors might have been developed. And whilst exactly
> the same results bit for bit would be nice, it's no practical to expect it, because
> of a certain amount of slop in floating point calculations.

I am not talking about the output of sloppy programs - I am talking
about the compiled binary image (striped of debug information and that
kind of thing, of course). I don't see why variable floating point
calculations would affect the result of a compilation or link.

And floating point, done to IEEE standards, should also be repeatable.

I would therefore expect something like an mp3 decoder used in a
resource compiler as part of a build, to give identical results every
time, even on different hardware, even if using floating point.
Obviously the particular version of the mp3 decoder would also have to
be considered as part of the toolchain and archived accordingly.

>>
> But you see the wisdom of using the Baby X resource compiler instead of the
> Python scripts that call external dependencies. If you want to package up
> everything so it's reproducible, you can package the Baby X resource
> compiler source, and, because it has no dependencies other than the standard
> library, compile it.

That could be an advantage in some cases, yes. It would not be in my
own use-cases, as the generated could would not be affected by the
version of Python or its libraries, but I certainly agree that while it
is easier to archive a Python script than your Baby X resource compiler,
it is easier to archive your resource compiler than a Python installation.

>>
>> If you want to support multiple different compilers and versions on
>> different systems, that's fine too. Clearly you will not be using so
>> many different flags as I do, but few projects need that many. Most
>> people will find "-O2 -Wall" to cover many use-cases, but that's for
>> different kinds of development than I do.
>>
> I've discovered the clang fsanitizer flag which is great for debug builds.
> But I don't need any options to get the correct results, except
> CRT_SECURE_NO_WARNINGS on Windows.

"Correct" can mean many things. For embedded systems, "runs as fast as
required" can be part of "correct", as can be "as compact as needed".
But also there are many flags to select details of devices in use -
microcontrollers are not as generic as PC's.

>>
>> And makefiles let you easily use variables to handle things like
>> different compiler paths, or common sets of flags - this is quite
>> normal. That means that even if you do need to make changes when moving
>> to a different host or different compiler, you only need to change a few
>> variables, not every invocation line for the compiler.
>>
> The problem is that even a tiny change can mean "you've messed with it.
> So any problems are no longer our responsibility. You're on your own."

That is not a problem unless you mess with it.

But our company supports its customers - we do not say "you're on your
own", as a general rule.

>>
>>> I'm not saying there's an easy answer.
>> And I am not saying "make" is perfect, or will solve every potential
>> problem - but it can do a great deal to help.
>>>
>>> But code broke for me just this morning. Someone had added a test to the test suite,
>>> and messed with the CMake script so that it always searched for CppuTest instead
>>> of only when tests were being built. So it broke my build, and I was in the CMake files
>>> and git history, trying to work out what was wrong. But at least CMake gives good errors
>>> and has intuitive syntax.
>> Debugging is part of life for any tools.
>>
> Exactly. Which is where make isn't very good and CMake is much better.
>

That may be true - "make" can be difficult to debug. But you learn the
tricks there too, and there are always ways to debug it.

On 15/08/2023 14:21, David Brown wrote:
> On 15/08/2023 12:40, Bart wrote:
>> (But you also have a funny idea of what 'proper Windows' is. For me it
>> is not using CYGWIN, MSYS2 or WSL.)
>
> What a truly bizarre "No true Scotsman" argument! Would you also say
> that it is impossible to write documents on "proper Windows" because
> Windows doesn't come with a word processor?

What is bizarre is thinking WSL (ie. Ubuntu) is proper Windows. I can't
build under WSL and send the binary to somebody running Windows. Not
unless they also run it under their Ubuntu.

So why even bother with Windows?

MSYS2, I've no idea what I'll end up with there. Either way, none of
these extra layers is necessary.

Compiling C under pure Windows is not hard!

>>
>> For me it didn't work. Please post the makefile you used; it should
>> only be 210 lines. If isn't 210 lines, then that can explain some
things.
>
> I downloaded the tarball referenced (lua-5.4.6.tar.gz). There is a
> Makefile in the main directory, of 106 lines, and a Makefile in the src
> directory of 225 lines.
>
> Did you not even /try/ to follow the instructions before complaining
> that nothing worked for you?

My recent post goes into this in more detail. But, I've believe the ZIP
files from the Github Lua repository are incorrect. This applies to:

* The displayed file hierarchy

* The ZIP from Download ZIP

* The ZIPs (the latest at least) from Releases.

They don't match the contents of the .tar.gz versions. I think this the
first directory layer is missing, so it only has the inner makefile, not
the outer makefile of 106 lines.

I tried building only via those ZIPs.

So, whose fault is that?

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.

Bart <bc@freeuk.com> writes:

>So why even bother with Windows?

A good question, indeed.

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
x lua-5.4.6/
x lua-5.4.6/Makefile
x lua-5.4.6/doc/
x lua-5.4.6/doc/luac.1
x lua-5.4.6/doc/manual.html
x lua-5.4.6/doc/manual.css
x lua-5.4.6/doc/contents.html
x lua-5.4.6/doc/lua.css
x lua-5.4.6/doc/osi-certified-72x60.png
x lua-5.4.6/doc/logo.gif
x lua-5.4.6/doc/lua.1
x lua-5.4.6/doc/index.css
x lua-5.4.6/doc/readme.html
x lua-5.4.6/src/
x lua-5.4.6/src/ldblib.c
x lua-5.4.6/src/lmathlib.c
x lua-5.4.6/src/loslib.c
x lua-5.4.6/src/lvm.c
x lua-5.4.6/src/ldo.h
x lua-5.4.6/src/lua.h
x lua-5.4.6/src/lgc.h
x lua-5.4.6/src/ltm.h
x lua-5.4.6/src/loadlib.c
x lua-5.4.6/src/lmem.c
x lua-5.4.6/src/lstate.h
x lua-5.4.6/src/Makefile
x lua-5.4.6/src/lzio.h
x lua-5.4.6/src/luaconf.h
x lua-5.4.6/src/lopcodes.c
x lua-5.4.6/src/lua.c
x lua-5.4.6/src/lundump.h
x lua-5.4.6/src/ljumptab.h
x lua-5.4.6/src/lbaselib.c
x lua-5.4.6/src/ltable.c
x lua-5.4.6/src/ldump.c
x lua-5.4.6/src/liolib.c
x lua-5.4.6/src/llimits.h
x lua-5.4.6/src/lfunc.h
x lua-5.4.6/src/lualib.h
x lua-5.4.6/src/lzio.c
x lua-5.4.6/src/lopnames.h
x lua-5.4.6/src/lctype.c
x lua-5.4.6/src/lmem.h
x lua-5.4.6/src/llex.h
x lua-5.4.6/src/ltable.h
x lua-5.4.6/src/lstring.c
x lua-5.4.6/src/ldebug.h
x lua-5.4.6/src/lprefix.h
x lua-5.4.6/src/llex.c
x lua-5.4.6/src/linit.c
x lua-5.4.6/src/lobject.h
x lua-5.4.6/src/lapi.h
x lua-5.4.6/src/ldebug.c
x lua-5.4.6/src/ldo.c
x lua-5.4.6/src/lvm.h
x lua-5.4.6/src/lauxlib.c
x lua-5.4.6/src/luac.c
x lua-5.4.6/src/lctype.h
x lua-5.4.6/src/lstring.h
x lua-5.4.6/src/lcorolib.c
x lua-5.4.6/src/lutf8lib.c
x lua-5.4.6/src/lgc.c
x lua-5.4.6/src/lstate.c
x lua-5.4.6/src/lundump.c
x lua-5.4.6/src/ltablib.c
x lua-5.4.6/src/lauxlib.h
x lua-5.4.6/src/ltm.c
x lua-5.4.6/src/lparser.c
x lua-5.4.6/src/lcode.h
x lua-5.4.6/src/lobject.c
x lua-5.4.6/src/lcode.c
x lua-5.4.6/src/lopcodes.h
x lua-5.4.6/src/lfunc.c
x lua-5.4.6/src/lapi.c
x lua-5.4.6/src/lparser.h
x lua-5.4.6/src/lua.hpp
x lua-5.4.6/src/lstrlib.c
x lua-5.4.6/README

See:
https://learn.microsoft.com/en-us/virtualization/community/team-blog/2017/20171219-tar-and-curl-come-to-windows

On 15/08/2023 17:11, Bart wrote:
> On 15/08/2023 14:21, David Brown wrote:
> > On 15/08/2023 12:40, Bart wrote:
> >> (But you also have a funny idea of what 'proper Windows' is. For me it
> >> is not using CYGWIN, MSYS2 or WSL.)
> >
> > What a truly bizarre "No true Scotsman" argument!  Would you also say
> > that it is impossible to write documents on "proper Windows" because
> > Windows doesn't come with a word processor?
>
> What is bizarre is thinking WSL (ie. Ubuntu) is proper Windows. I can't
> build under WSL and send the binary to somebody running Windows. Not
> unless they also run it under their Ubuntu.
>
> So why even bother with Windows?
>
> MSYS2, I've no idea what I'll end up with there.

Right, so you'll condemn it from the get-go despite having no idea about
it? That's a great attitude.

> Either way, none of
> these extra layers is necessary.

Apparently they are. Certainly I had no problems and built Lua in under
a minute (including downloading and reading the instructions), resulting
in an executable that will work on any Windows system. You, who do not
have msys2 or anything else that even hints of coming from the *nix
world, have had all sorts of trouble.

>
> Compiling C under pure Windows is not hard!
>
>
> >>
> >> For me it didn't work. Please post the makefile you used; it should
> >> only be 210 lines. If isn't 210 lines, then that can explain some
> things.
> >
> > I downloaded the tarball referenced (lua-5.4.6.tar.gz).  There is a
> > Makefile in the main directory, of 106 lines, and a Makefile in the src
> > directory of 225 lines.
> >
> > Did you not even /try/ to follow the instructions before complaining
> > that nothing worked for you?
>
> My recent post goes into this in more detail. But, I've believe the ZIP
> files from the Github Lua repository are incorrect. This applies to:
>
> * The displayed file hierarchy
>
> * The ZIP from Download ZIP
>
> * The ZIPs (the latest at least) from Releases.
>

The build instructions and the releases are from lua.org, not github.
That's for development work (which is most likely targeting Linux).

> They don't match the contents of the .tar.gz versions. I think this the
> first directory layer is missing, so it only has the inner makefile, not
> the outer makefile of 106 lines.
>
> I tried building only via those ZIPs.
>
> So, whose fault is that?

Yours - you did not read the build instructions, but ploughed on with
your own guesswork and got into trouble.

>
> 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.

On Tuesday, 15 August 2023 at 17:57:24 UTC+3, Bart wrote:
> On 15/08/2023 13:53, Öö Tiib wrote:
> > On Tuesday, 15 August 2023 at 14:15:03 UTC+3, Bart wrote:
> >> https://www.lua.org/manual/5.4/readme.html
>
> >> This is the page I'm referring to.
> >>
> > Yes, it also suggests mingw as xxx for make xxx, when plain make doesn't
> > cut it.
> If your read my post, it suggests that in a section whose first line
> talks about Unix-like systems, with xxx in a list of mostly Unix-based
> OSes, in a page where later on there is a separate section devoted to
> building it on 'other systems', and which starts off saying 'if you're
> not using the usual Unix tools', someone could well be forgiven for
> missing it.
>
> Especially if scanning for Windows-build information.
>
> Of course, after I said I couldn't see it, you all minutely scrutinised
> every line of it, and or maybe you started off in the Unix-specific
> section out of habit, while /I/ skip it out of habit.
>
I did not, like I said, I did check what is so bad about it on Windows
(having nothing but a MacBook anyway at the moment) and was
on <http://lua-users.org/wiki/BuildingLua> that looked like
good page (to me) with majority of information being how to build
it on Windows.

> There is no reason to make it hard.
>
> Why is Windows, the world's mostly popular OS and most successful OS in
> the 1990s, barely mentioned? If I go into a computer shop even now and
> buy a desktop PC, it will likely have Windows installed.
>
> So there is no reason, other than churlishness, not to have a section
> titled:
>
> Building Lua on Microsoft Windows
>
> But they'd better make sure that 'make mingw' works. The 210-line
> makefile in the downloads, I'm pretty sure is not the one they have in
> mind here.
>
> If I instead download a .tgz version of Lua from here:
> http://www.lua.org/ftp/, then sure enough the makefile there is 160
> lines and looks at the supplied platform parameter.
>
> But that is not the only thing: the directory structure is different
> with sources in ./src, not at the top level.
>
> The source I got from Github, either from 'Download ZIP' or the
> source-code .zip from Releases, had a different structure and makefile.
> Both lots are for 5.4.6.
>
> But the .tar.gz version from Releases has the correct structure and
> makefile and I believe matchs the releases from lua.org.
>
> So the problem appears to be this:
>
> On GitHUB, the .zip and .tar.gz versions differ in their contents. The
> folder structure is different, and the makefile is different.
>
> Oddly, the .zip version, usually associated with Windows, has a makefile
> that doesn't build under Windows, and if I try it under Linux, fails to
> link symbols because of that are part of WinAPI.
>
> So, there appears to be an actual problem with that Github repository.
>
> But I bet I'm not going to get any apologies: I'm still just a bumbling,
> incompetent idiot.
>
> I'm also the idiot that highlighted clarity issues in the Readme file,
> and discovered a discrepancy in the .zip and .tar.gz versions.
>
> The Github directory displayed, and the makefile, are also incorrect as
> they correspond to the ZIP versions.
>
Why anyone has to apologise? Lua is free and open source, provided in
fair hope that it helps, not in hope that it confuses. If it confused you
then that likely happened because everyone have different experiences,
needs and expectations. Similarly someone expecting something like
JavaScript, Python or Ruby from Lua might be confused ... but so it
went.

> >> Your link does at least mention 'make mingw' directly, but also in the
> >> context of mingw-msys; I don't know what that is. In all it is a lot
> >> more complicated and confusing.
> >>
> > The MinGW is runtime environment on Windows. Currently there
> > is advancement project MinGW-w64. The MSYS is collection of tools
> > and libraries compatible with MinGW ... it has also advancement
> > project MSYS2.
> I have mingw which I believe refers to implementations of gcc on Windows.
>
> MSYS is a separate product.
>
Yes, I said nothing contradicting with it, it is made to help with installation
and usage of various open source programming tools and libraries. If it does
not help you then do not use. But also do not demonise groundlessly.

> >
> > Nothing to do, decades old platform like Windows has accumulated
> > several production tool stacks over time and so there are no one-liner
> > answer that satisfies users of all of those.
>
> There is always plain Windows. CYGWIN, MSYS2 and WSL are just extra
> layers. Ones that are necessary for a project as simple as this.
>
A plain Windows comes without software development tools whatsoever.
That is because vast majority of its users are not software developers.
So one obviously needs to install something for to write programs on
it.

In article <1dcd9ed8-d345-45f1-8b9b-7ef1f2f4cb04n@googlegroups.com>,
MJ OS_EXAMINE <m6502x64@gmail.com> wrote:
>On Tuesday, August 15, 2023 at 11:12:10AM 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:

Yes, but "modern" Windows is crap.

Last good version: XP
Last usable version: 7

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/DanQuayle

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?

In article <qbOCM.632529$TPw2.568059@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> 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, true, but irrelevant.

I believe David is asserting that the lua tarball (which *is* the thing we
are discussing) does not have any such issues.

Whether that is actually true or not, I have no idea. Nor do I care.

--
Politics is show business for ugly people.

Sports is politics for stupid people.

On 15/08/2023 17:03, David Brown wrote:
> On 15/08/2023 17:11, Bart wrote:
>> My recent post goes into this in more detail. But, I've believe the
>> ZIP files from the Github Lua repository are incorrect. This applies to:
>>
>> * The displayed file hierarchy
>>
>> * The ZIP from Download ZIP
>>
>> * The ZIPs (the latest at least) from Releases.
>>
>
> The build instructions and the releases are from lua.org, not github.
> That's for development work (which is most likely targeting Linux).
>
>> They don't match the contents of the .tar.gz versions. I think this
>> the first directory layer is missing, so it only has the inner
>> makefile, not the outer makefile of 106 lines.
>>
>> I tried building only via those ZIPs.
>>
>> So, whose fault is that?
>
> Yours - you did not read the build instructions, but ploughed on with
> your own guesswork and got into trouble.

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.

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.

This is from a Github page about downloading source code archives:

"(4) To download the source code, click Source code (zip) or Source
code (tar.gz)."

(https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives)

Notice it says 'zip' OR 'tar.gz'. Presumably it shouldn't matter which.

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

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.

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

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'. And when challenged, you say that doing
it under MSYS2 is also 'installing it on Windows'.

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.)

This is what /I/ achieved in trying to build this project:

* I managed it without make

* I managed it in plain Windows

* I managed it even from the faulty Github ZIP files with the missing
outer layer

* I /discovered/ there was a missing outer layer (you're welcome)

* I found out the lua.org's Readme should be overhauled as the Windows
build info is unclear (you of course couldn't give a cuss about that, so
long as you can prove me wrong about the info being in there, if you
joined enough dots)

So, what have /you/ achieved?