On 16/08/2023 12:56, Malcolm McLean wrote:
> On Wednesday, 16 August 2023 at 11:52:46 UTC+1, David Brown wrote:

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

If you are looking at Lua, then you could go a lot further than that.
For one thing, you could write the whole resource compiler in Lua - it
would be simpler and shorter than doing it in C. There are XML parsing
libraries in Lua.

You could also use Lua as the format for your configuration files,
rather than XML. I have often used Python as the configuration format
for Python programs I have written - then reading the configuration is
just an "import", without any need to make parsers. (Of course, you
have to be able to trust the users and the configuration file writers in
such cases.) This is particularly handy if you want loops or other
calculated configuration - if a resource configuration file is supposed
to include "image000.png" up to "image999.png", it's a lot easier in Lua
than doing a thousand copy-paste-edit operations in an XML file!

On 16/08/2023 13:15, Bart wrote:
> 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.

I am not desparate. I tried to tell you what you did wrong, so that you
could try to get it right. Since you repeatedly ignore that, I condense
it to saying you were wrong.

> Oh, you should
> have known this, should have known that. I bet you were surprised that
> that Github repository was incomplete too!

I wrote exactly that in a reply to Keith (which you might not have read
yet).

So I /do/ understand that you also found that surprising, and I don't
think it is an unreasonable guess, before reading anything about a given
project, to suppose that a GitHub repository connected to a project
would have the same files that are provided in releases of the project.

But understanding how you got this wrong does not mean you did not get
it wrong.

And since the GitHub page and readme contains multiple indications that
you should be looking at "www.lua.org" for downloads and build and
install instructions, and you were told in posts here about such
instructions, it becomes your /fault/ that you remained wrong.

You prefered to stay wrong, so that you could complain about problems
building the project - you never had any intention of trying to get it
right, and thus actively avoided doing so. That makes it your fault.

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

No, it does not. In the release tarballs, there are two separate files
- "Makefile" and "src/Makefile". Directories are relevant.

If you "organise" your code the way you said you do, with hundreds of
different unrelated files in one directory, then I can see why you would
dislike a common name like "makefile". But for people who organise
their projects and code in directories, a single common name is perfect
- "makefile", "README.md", etc.

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

When I have multiple makefiles in a single directory (sometimes I will
split a makefile into multiple parts, separating project-specific,
host-specific and generic sections) I give them different names.

But what would be the benefit of different names in this case? They are
clearly different files when they are in different directories. Calling
them "makefile" (or "Makefile") makes it immediately obvious what the
files are. If they were called "install.mk" and "build.mk" instead,
people would wonder what they were, and where the makefile is, and they
would have to write "make -f install.mk" instead of just "make".

Tell me what you see as the advantage here, and why /you/ think it would
be a jolly good idea, and maybe I'll agree. But you have to say why it
would be better for everyone, not just for you personally - you need
good reasons to change 50 year old conventions.

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

Why? For whom? Do you think you are achieving your goals here?

I mean, it's a noble aim. Don't misunderstand me - I /agree/ that all
other things being equal, it is better for software to be small, simple
and fast. The trouble with your position is that all other things are
/not/ equal. It is very rarely a good idea to target any particular
aspect to the extreme or to the exclusion of other things. Your
compiler may be much smaller and faster than gcc, but it does not have
the features people need. Writing "cc *.c" may be simpler than a
makefile, but it does not do the same thing.

Then there is the question of why it matters. PC disks are big. PC
CPUs are fast. Network speeds are high. Top quality development tools
and utilities are freely available - even on Windows. Size and speed
matters very little for software on PC's. (It matters a great deal on
small embedded systems.)

So who are you fighting for? Who are you fighting against? Do you
really think you are making a difference for some greater good here, or
even just for your own personal benefit? (There's nothing wrong with
doing it for your own benefit - I am not suggesting you have to fight
for other people.) Have you considered whether there are other battles
that would make more sense or have greater impact? Have you considered
forgetting it all, splashing out £300 on a new mini-PC, installing Linux
Mint, and going back to having fun with computers, learning new things,
and creating software without bothering about how much space gcc takes up?

I really don't understand your motivation for these pointless arguments
and battles - unless you simply enjoy the argument. You are not a
fanatic who thinks all software is evil unless written by your personal
religious cult, or that we'll all go back to C90 after the appocolypse.

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

But they /can't/ work - they don't do what people need. You /know/
this. You can write small and simple solutions for specific limited
use-cases - that's nothing new. But anything that will cover a wide
variety of needs of a wide variety of people is inevitably bigger and
more complex.

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

No - I am asking you to understand the world is bigger than you.

You could design a television with one button - for turning it on and
off. That would be beautifully simple and elegant. Why do people want
the complexity of choosing channels when BBC 1 has all you need? What's
the point of a volume control when the hardware can be fixed at the
ideal volume level for your preferences?

But would that television work for other people? Would it be better?
Simple and limited are great for specific cases - and maybe that
television would be better for your needs. But it won't suit others,
and cannot be a wide-scale solution.

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

That's fine - be yourself, not anyone else.

On 16/08/2023 13:19, Bart wrote:
> 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.
>

OK.

On 16/08/2023 14:16, David Brown wrote:
> On 16/08/2023 13:15, Bart wrote:
> I am not desparate. I tried to tell you what you did wrong, so that you
> could try to get it right. Since you repeatedly ignore that, I condense
> it to saying you were wrong.

And you are convinced that I must have been wrong, and that the blame
falls 100% on me.

I've spent a lot of time doing technical support with clients who were
endusers and encountered lots of different kinds of problems.

I got to have an idea of where things could be commonly or easily
misunderstood. I was also involved in writing user manuals and mine were
written with the possibility that things could go wrong and the
knowledge of which aspects could be misunderstood.

There was rarely a point where a customer was just plain stupid. If they
did something wrongly, I would see what I could change to make that less
likely and more foolproof.

Most manuals and references are written with the assumption that the
product is perfect, and so is the manual; it can never be ambiguous or
confusing.

> But understanding how you got this wrong does not mean you did not get
> it wrong.

It's not me! Building that product requires two makefiles, only one was
provided on that site.

So a bunch of .c and .h files, and a file called 'makefile'; hmmm.... Is
it not unreasonable for someone to make a wild stab and guess you built
the product using 'make'? Especially given the lack of the usual build
instructions.

The short readme does indeed say get releases from a website; but that
can be taken to mean (as I did) releases of binaries, since the Releases
section of the github page has only sources.

I take it that you wouldn't change that Readme at all just to make it a
bit clearer? After all lots of people will use 'github <appname>' to get
at the sources of projects.

But no, let's just leave it! Adding a few more lines of clarification to
a 6-line readme is too much effort.

>> might be a touch sweeter than those 330 lines of makefile crap below.
>
> I fail to see how that's better than "make" (or "make mingw" on
> Windows). I /do/ see how "make" is vastly superior, because the
> makefile has lots more in it than just the dependencies that could be
> found automatically. Where does "mm lua" put all the compiler flags?
> The pre-defined macros used to configure lua according to needs and
> preferences? The alternative build targets for tests? The warning
> flags? The choice of compiler?

'mm' /is/ the compiler, in the same way that 'cc' is the C compiler in
lots of similar examples in the rare cases that people invoke it directly.

I did say you can add a makefile if you want, or script it in any manner
you like. 'mm prog' takes care of locating the source files of a
project, which occupies most of a makefile. With that out of the way,
there is not a great deal left.

This is the script (putmm.bat) which builds a new version of mm using an
old version, then replaces that old version (backups are a separate script):

\m\mm mm -ext -opt
copy mm.exe \m\mm.exe

There are no intermediate files to clean up and no dependencies to worry
about.

'mm prog' turns a bunch of sources into one binary file. If an app is
more elaborfate than that, then some basic scripting might be needed to
invoke it more than once or copy files about etc.

Different configurations tend to have a differently named lead module.
Compiler options (there aren't many) can be added to the command line;
being options, you may not want them baked in.

The fundamental step is so simple, anyone can easily see how to apply
their own scripting for their needs.

> Short and sweet is all well enough - /if/ it is good enough and has the
> features that people want. "make" may be complex, but it does what is
> needed.

Suppose somebody wanted to know all the relevant files because they
wanted control of the whole build process? Or even, run their own
compiler that doesn't follow convention. That information is pretty much
opaque in makefiles; it's not meant to be human-readable.

(With mm, the relevant modules are listed in the lead module as part of
the module scheme. Support files, that used via 'include' or which are
embedded, are not listed in one place. But you can get a summary when
generating an amalgamated source file using -ma.)

> And the makefile for Lua is hardly complex or difficult to follow.

It's 331 lines for both of them. Can it be done better? Here's my stab
at it (based on one for Pico C as the Lua one is too abstruse):

# CC = tcc
CC = gcc

lua:
$(CC) -olua \
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 \
-lm

This had some problems with gcc, but it managed to produce executables
for both tcc and gcc. I had to run it under WSL, since my Windows at the
minute has problems running C compilers.

It is 4% the size of the two supplied makefiles: it's not just the
linecount; the latter are written horizontally. Any reason why they
can't list one file per line?

> What a truly silly thing to do. If someone told you your house was a
> horrible colour, would you burn it down?
>
> I'd make a copy of your archives while they are still functional.

It really doesn't matter. My main tools are still there, only the ones
which adversely affect my blood pressure are going.

On 16/08/2023 14:16, David Brown wrote:
> Tell me what you see as the advantage here, and why /you/ think it would
> be a jolly good idea, and maybe I'll agree. But you have to say why it
> would be better for everyone, not just for you personally - you need
> good reasons to change 50 year old conventions.

[Giving names to makefiles]

* You can have more than one project in the same folder

* You can have different configurations of the same project

* You can have different makefiles customised to different compilers
(Seed7 has nearly 20 different makefiles)

* You can split up a project into components with their own separately
invoked makefile

* You can differentiate between a makefile that is called directly,
and one that is called indirectly from another

* If you expected to build X according to the build instructions,
but the makefile is called Y, then you know something may be wrong

'make' must be unique in being an application that takes input from a
file, but the name of the file is hardcoded.

A few applications will use defaults when a filename is missing (even if
it's 'stdin'), but are generally used with a specific name.

I would actually make a missing filename an error for an application
like this.

Maybe make was written by the same person who hardcoded a.out as an
output filename. They missing a trick by not having a.c as the default
input for a C compiler; that makes as much sense.

On 16/08/2023 01: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 reinstalled CMake. The results I get are:

c:\bbx\build>cmake ..
CMake Deprecation Warning at CMakeLists.txt:5 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.

Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Error at CMakeLists.txt:9 (project):
Running

'nmake' '-?'

failed with:

The system cannot find the file specified

CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

On 16/08/2023 18:12, Bart wrote:
> On 16/08/2023 01: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 reinstalled CMake. The results I get are:
>
>
> c:\bbx\build>cmake ..
> CMake Deprecation Warning at CMakeLists.txt:5 (cmake_minimum_required):
>   Compatibility with CMake < 3.5 will be removed from a future version of
>   CMake.
>
>   Update the VERSION argument <min> value or use a ...<max> suffix to tell
>   CMake that the project does not need compatibility with older versions.
>
>
> CMake Error at CMakeLists.txt:9 (project):
>   Running
>
>    'nmake' '-?'
>
>   failed with:
>
>    The system cannot find the file specified

Hmm, maybe it's talking about a file called '-?', which seems to be the
subject of the other thread.

It still leaves the question of why it's using nmake, which I don't have
on my machine either.

It also suggests that that error message, for a 112MB application, could
be a lot better: if a file is missing, WHICH file is it exactly?

BTW line 9 of cmakelists.txt is this line:

project(babyxrc)

Bart <bc@freeuk.com> writes:
>On 16/08/2023 14:16, David Brown wrote:
> > Tell me what you see as the advantage here, and why /you/ think it would
> > be a jolly good idea, and maybe I'll agree. But you have to say why it
> > would be better for everyone, not just for you personally - you need
> > good reasons to change 50 year old conventions.

>'make' must be unique in being an application that takes input from a
>file, but the name of the file is hardcoded.

No, it is not. If you would trouble yourself to read the make manual
page, you'll find that:
1) the -f argument allows the specification of a arbitrary name for the
makefile.
2) Absent -f, make will look for 'makefile', 'GNUmakefile', or 'Makefile'.

$ man make

SYNOPSIS
make [ -f makefile ] [ options ] ... [ targets ] ...

....
Normally you should call your makefile either makefile or Makefile.
(We recommend Makefile because it appears prominently near the begin-
ning of a directory listing, right near other important files such as
README.) The first name checked, GNUmakefile, is not recommended for
most makefiles. You should use this name if you have a makefile that
is specific to GNU make, and will not be understood by other versions
of make. If makefile is `-', the standard input is read.
....
-f file, --file=file, --makefile=FILE
Use file as a makefile.

The usenet acronym 'RTFM' is always relevent.

Bart <bc@freeuk.com> writes:
>On 16/08/2023 01: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 reinstalled CMake. The results I get are:

https://stackoverflow.com/questions/69338088/error-while-configuring-cmake-project-running-nmake-failed

On 16/08/2023 18:43, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 16/08/2023 14:16, David Brown wrote:
>>> Tell me what you see as the advantage here, and why /you/ think it would
>>> be a jolly good idea, and maybe I'll agree. But you have to say why it
>>> would be better for everyone, not just for you personally - you need
>>> good reasons to change 50 year old conventions.
>
>> 'make' must be unique in being an application that takes input from a
>> file, but the name of the file is hardcoded.
>
> No, it is not. If you would trouble yourself to read the make manual
> page, you'll find that:
> 1) the -f argument allows the specification of a arbitrary name for the
> makefile.
> 2) Absent -f, make will look for 'makefile', 'GNUmakefile', or 'Makefile'.

I know about -f because I've seen it.

But most documented uses of 'make' seem with work with the default
filename 'makefile'.

Most projects I've seen with a makefile, have a file called 'makefile'.

In the project that has been discussed, there were two makefiles both
called 'makefile'. In the erroneous set of sources, one was missing.
That left a bunch of source files and a file called 'makefile'.

> Normally you should call your makefile either makefile or Makefile.

This is what I mean. No, you shouldn't.

Suppose you accidentally copy 'makefile' from elsewhere? You wouldn't be
able to tell; they're all called Bob!

David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.

And none of that requires building Lua from source.

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

> 'make' must be unique in being an application that takes input from a file,
> but the name of the file is hardcoded.

Not really. The input to make is something like a configuration file,
and lots of applications (in Unix land) read a configuration file
derived from the program name. bc reads .bcrc, fetchmail reads
..fetchmailrc and so on. Had the authors decided have make read a file
called .makerc it would look much like many others.

Of course, the makefile is something more than a simple configuration
file, but it's also more like one than the files make is operating on
that will be specified on the command line.

(I'm ignoring -f because being able to override the default does not
invalidate your comment.

> Maybe make was written by the same person who hardcoded a.out as an output
> filename. They missing a trick by not having a.c as the default input for a
> C compiler; that makes as much sense.

oh dear, I typed the above before reading this, but I'll post the
explanation anyway...

--
Ben.

On 16/08/2023 21:26, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> 'make' must be unique in being an application that takes input from
a file,
>> but the name of the file is hardcoded.
>
> Not really. The input to make is something like a configuration file,
> and lots of applications (in Unix land) read a configuration file
> derived from the program name. bc reads .bcrc, fetchmail reads
> .fetchmailrc and so on. Had the authors decided have make read a file
> called .makerc it would look much like many others.

No, what make does with 'makefile' is not what I'd associate with
configuration data which:

* May be shared by, and is constant, across different deployments of the
program when applied to different inputs

* Controls how the application works, and has nothing about the user's
data (at best, program settings the user has made which will carry over
into the next invocation)

* Is separate from the real user-supplied data for the application

For example, I had an application called M7.EXE, and it used (among
several config files), one called M7.INI that is read automatically.

But when M7 is invoked, it can be given the name of a real data file.

I don't have to copy my data (in this case a 3D data model) into M7.INI!

>> Maybe make was written by the same person who hardcoded a.out as an
output
>> filename. They missing a trick by not having a.c as the default
input for a
>> C compiler; that makes as much sense.
>
> oh dear, I typed the above before reading this, but I'll post the
> explanation anyway...

And I posted a civil reply anyway despite your snide remark.

Yes, some of these programs do look like the early efforts of a
beginning programmer. Decades later, people (even you) try to
rationalise their behaviour.

I just say it like it is.

On 16/08/2023 22:25, Bart wrote:
> On 16/08/2023 21:26, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> 'make' must be unique in being an application that takes input from
> a file,
> >> but the name of the file is hardcoded.
> >
> > Not really.  The input to make is something like a configuration file,
> > and lots of applications (in Unix land) read a configuration file
> > derived from the program name.  bc reads .bcrc, fetchmail reads
> > .fetchmailrc and so on.  Had the authors decided have make read a file
> > called .makerc it would look much like many others.
>
> No, what make does with 'makefile' is not what I'd associate with
> configuration data which:
>
> * May be shared by, and is constant, across different deployments of the
> program when applied to different inputs
>
> * Controls how the application works, and has nothing about the user's
> data (at best, program settings the user has made which will carry over
> into the next invocation)
>
> * Is separate from the real user-supplied data for the application
>

You know this is not what makefiles are for.

I think you're just being wrong on purpose.

On 17/08/2023 00:15, Richard Harnden wrote:
> On 16/08/2023 22:25, Bart wrote:
>> On 16/08/2023 21:26, Ben Bacarisse wrote:
>>  > Bart <bc@freeuk.com> writes:
>>  >
>>  >> 'make' must be unique in being an application that takes input
>> from a file,
>>  >> but the name of the file is hardcoded.
>>  >
>>  > Not really.  The input to make is something like a configuration file,
>>  > and lots of applications (in Unix land) read a configuration file
>>  > derived from the program name.  bc reads .bcrc, fetchmail reads
>>  > .fetchmailrc and so on.  Had the authors decided have make read a file
>>  > called .makerc it would look much like many others.
>>
>> No, what make does with 'makefile' is not what I'd associate with
>> configuration data which:
>>
>> * May be shared by, and is constant, across different deployments of
>> the program when applied to different inputs
>>
>> * Controls how the application works, and has nothing about the user's
>> data (at best, program settings the user has made which will carry
>> over into the next invocation)
>>
>> * Is separate from the real user-supplied data for the application
>>
>
> You know this is not what makefiles are for.
>
> I think you're just being wrong on purpose.

Somebody compared the 'makefile' of 'make' to a configuration file of an
aplication.

I'm saying no, configuration files are different; they do this. So
clearly I was not saying that's what makefiles do.

So maybe /you're/ wrong being wrong on purpose just to make me look bad.

Please stop it.

Bart <bc@freeuk.com> writes:

> On 16/08/2023 21:26, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> 'make' must be unique in being an application that takes input from a
> file,
>>> but the name of the file is hardcoded.
>>
>> Not really. The input to make is something like a configuration file,
>> and lots of applications (in Unix land) read a configuration file
>> derived from the program name. bc reads .bcrc, fetchmail reads
>> .fetchmailrc and so on. Had the authors decided have make read a file
>> called .makerc it would look much like many others.
>
> No, what make does with 'makefile' is not what I'd associate with
> configuration data which:
>
> * May be shared by, and is constant, across different deployments of the
> program when applied to different inputs

You mean like a makefile?

> * Controls how the application works, and has nothing about the user's data
> (at best, program settings the user has made which will carry over into
> the next invocation)

That's a curious restriction! So a makefile with only general rules and
settings qualifies? But as soon as it mentions any specific file it
stops being "somewhat like" a configuration file (which is all I
claimed)?

> * Is separate from the real user-supplied data for the application

Too vague for me. What is separate? What is the unreal data?

Anyway, I did not expect to convince you. I hope you enjoyed
considering a perspective that differs from your own.

> I just say it like it is.

You say it like you see it (as do I). To consider that as "like it is"
takes more self confidence than I can muster.

--
Ben.

On Wednesday, August 16, 2023 at 1:52:46 PM UTC+3, David Brown wrote:
> 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.

Did it work?
I mean, not an easy technical part of embedding an interpreter.
Did the "human" part work? Did people that were supposed to write
scripts bothered to learn the language and to start writing?

On 17/08/2023 02:56, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 16/08/2023 21:26, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> 'make' must be unique in being an application that takes input from a
>> file,
>>>> but the name of the file is hardcoded.
>>>
>>> Not really. The input to make is something like a configuration file,
>>> and lots of applications (in Unix land) read a configuration file
>>> derived from the program name. bc reads .bcrc, fetchmail reads
>>> .fetchmailrc and so on. Had the authors decided have make read a file
>>> called .makerc it would look much like many others.
>>
>> No, what make does with 'makefile' is not what I'd associate with
>> configuration data which:
>>
>> * May be shared by, and is constant, across different deployments of the
>> program when applied to different inputs
>
> You mean like a makefile?
>
>> * Controls how the application works, and has nothing about the
user's data
>> (at best, program settings the user has made which will carry
over into
>> the next invocation)
>
> That's a curious restriction! So a makefile with only general rules and
> settings qualifies? But as soon as it mentions any specific file it
> stops being "somewhat like" a configuration file (which is all I
> claimed)?
>
>> * Is separate from the real user-supplied data for the application
>
> Too vague for me. What is separate? What is the unreal data?

Configuration files for me are more like this:

APPLICATION < -- > USER DATA
^
|
v
[CONFIG FILE]

Config data is more like meta-data. (Maybe, a little like cookies used
by a program within a website; say one used to format user-supplied XML
data.)

It is not the primary data of the application.

For Make, the makefile /is/ the primary data. It belongs at that top
right. And it deserves a proper name.

Any configuration files are unlikely to have variable, user-provided names.

I think you were justifying Make using mainly fixed, hardcoded names for
its primary data, by classifying that data as configuration. I don't buy
it. That would make Make even more peculiar.

(What next, build Make from source with your project files listed in the
source code?)

>
> Anyway, I did not expect to convince you. I hope you enjoyed
> considering a perspective that differs from your own.
>
>> I just say it like it is.
>
> You say it like you see it (as do I). To consider that as "like it is"
> takes more self confidence than I can muster.

Make seems to mostly use a local file called 'makefile' for its primary
data. Certainly that's what it will use if no alternate is provided.

That's like 'it is'.

I have a Python benchmark where the input file name is hardcoded in the
source code. There's a comment to adjust that name to suit (or people
can use the same name for their own data). I couldn't be bothered to
process argv parameters.

Make is pretty much at that level.

On 16/08/2023 19:07, Bart wrote:
> On 16/08/2023 14:16, David Brown wrote:
> > Tell me what you see as the advantage here, and why /you/ think it would
> > be a jolly good idea, and maybe I'll agree.  But you have to say why it
> > would be better for everyone, not just for you personally - you need
> > good reasons to change 50 year old conventions.
>
> [Giving names to makefiles]
>
> * You can have more than one project in the same folder

Makefiles can have multiple targets - that is, in fact, very common.
But usually it's a bad idea to have multiple different projects in the
same folder.

>
> * You can have different configurations of the same project

I do that all the time with a single makefile.

>
> * You can have different makefiles customised to different compilers
>   (Seed7 has nearly 20 different makefiles)

You can do that with a single makefile.

>
> * You can split up a project into components with their own separately
>   invoked makefile

You can do that with a single main makefile, and invoke submakes with
different makefiles if you like. Typically, these components and their
makefiles are in different subdirectories.

>
> * You can differentiate between a makefile that is called directly,
>   and one that is called indirectly from another

Call the main one "makefile", and the other one "other_bit.mak" - this
is fine and perfectly normal.

>
> * If you expected to build X according to the build instructions,
>   but the makefile is called Y, then you know something may be wrong

So making things more difficult for the user, flouting decades-old
conventions and expectations, is a good thing in your eyes?

>
> 'make' must be unique in being an application that takes input from a
> file, but the name of the file is hardcoded.

The /default/ file name is hardcoded (well, both "makefile" and
"Makefile" are supported). But as I mentioned before, if you want a
different name just use "make -f other_file_name". (Use a file
extension of your choice, if you want - make does not care.)

>
> A few applications will use defaults when a filename is missing (even if
> it's 'stdin'), but are generally used with a specific name.
>

For some programs it is common practice - such as for "make". And also,
I believe, for "CMake", "ant", "bake", "nmake", and all other build
tools I have seen. Basically, people building a project find it really
easy to go to the project directory and type "make" (or whatever).
Typing "make -f project_name.mk" would be an unnecessary inconvenience.
But of course you are free to do that if you want.

> I would actually make a missing filename an error for an application
> like this.
>
> Maybe make was written by the same person who hardcoded a.out as an
> output filename. They missing a trick by not having a.c as the default
> input for a C compiler; that makes as much sense.
>

I think you should get some experience with project organisation and
build tools - then you will understand better. Otherwise, just accept
that the way these things are done by other people makes a lot of sense
to everyone else.

On 16/08/2023 21:55, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> 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.
>
> And none of that requires building Lua from source.
>

It might do. But it won't use the plain build instructions.

For some uses, you can probably use a prebuilt lua runtime library. In
other cases, you /do/ want to build the source - but you are not
building the normal "lua" and "luac" programs. You are building object
files as part of your main application, with whatever configuration you
want for the lua parts. For example, lua normally uses 64-bit integers
as its only integer type, while in an 32-bit embedded system you might
prefer to use 32-bit integers in your embedded lua. And of course you'd
be using a cross-compiler, not a host compiler.

On 17/08/2023 11:14, Michael S wrote:
> On Wednesday, August 16, 2023 at 1:52:46 PM UTC+3, David Brown wrote:
>> 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.
>
> Did it work?
> I mean, not an easy technical part of embedding an interpreter.
> Did the "human" part work? Did people that were supposed to write
> scripts bothered to learn the language and to start writing?
>

Yes, at least for some simple cases. But those people were just me in
that particular case - I used Lua as a convenient way to write hardware
test scripts for the system. I haven't actually made much use of it
since, and that project was cancelled (nothing to do with lua or any of
the electronics or software - the mechanics were too expensive).
However, it is definitely something I would use again if I felt that
something more than a very simple command-line interface were useful in
an embedded project, and the hardware was big enough to support the
overhead (something like 60-70 KB code, IIRC).

Michael S <already5chosen@yahoo.com> writes:
>On Wednesday, August 16, 2023 at 1:52:46=E2=80=AFPM UTC+3, David Brown wrot=
>e:
>> Certainly embedding it within other applications is a major purpose of=20
>> the language, yes. It is becoming more mature as a stand-alone=20
>> language, with more libraries, but it is very popular for adding to=20
>> other programs. As you say, Lua is a common choice for scripting in=20
>> games. I used it myself as a scripting language in an embedded program,=
>=20
>> many moons ago.
>
>Did it work?
>I mean, not an easy technical part of embedding an interpreter.
>Did the "human" part work? Did people that were supposed to write
>scripts bothered to learn the language and to start writing?

We also have some stand-alone[*] software that runs on our CPUs
that uses an embedded lua interpreter. Users have had no problems
with it at all.

[*] in this context, bare-metal sans OS.

On Thursday, August 17, 2023 at 7:01:51 PM UTC+3, Scott Lurndal wrote:
> Michael S <already...@yahoo.com> writes:
> >On Wednesday, August 16, 2023 at 1:52:46=E2=80=AFPM UTC+3, David Brown wrot=
> >e:
> >> Certainly embedding it within other applications is a major purpose of=20
> >> the language, yes. It is becoming more mature as a stand-alone=20
> >> language, with more libraries, but it is very popular for adding to=20
> >> other programs. As you say, Lua is a common choice for scripting in=20
> >> games. I used it myself as a scripting language in an embedded program,=
> >=20
> >> many moons ago.
> >
> >Did it work?
> >I mean, not an easy technical part of embedding an interpreter.
> >Did the "human" part work? Did people that were supposed to write
> >scripts bothered to learn the language and to start writing?
> We also have some stand-alone[*] software that runs on our CPUs
> that uses an embedded lua interpreter. Users have had no problems
> with it at all.
>
> [*] in this context, bare-metal sans OS.

Who are users in this case?

On 16/08/2023 14:16, David Brown wrote:
> On 16/08/2023 13:15, Bart wrote:
> Then there is the question of why it matters. PC disks are big. PC
> CPUs are fast. Network speeds are high. Top quality development tools
> and utilities are freely available - even on Windows. Size and speed
> matters very little for software on PC's. (It matters a great deal on
> small embedded systems.)

And yet... when I reinstalled CMake, it took nearly 10 minutes to unzip
7300 files into 112MB, on an SSD. I don't why it took that long, but it did.

(There's also the mystery of why it takes such a humungous program to
.... turn a file-spec info into a makefile? I could do that by hand in
less than 10 minutes! In the end CMake couldn't even complete the task:
maybe 7300 files wasn't quite enough.

But I think you're not keen on CMake anyway.)

When I tried to install VS once, although on an older machine with a
hard drive, it took 90 minutes. Each time it started up (usually
inadvertently because of a file association), it took 90 seconds.

On the same machine, my programs started instantly.

>
> So who are you fighting for? Who are you fighting against? Do you
> really think you are making a difference for some greater good here, or
> even just for your own personal benefit?

There are a huge number of benefits to keeping things small and
managable. You don't understand what they are because of using top-end
hardware, and using systems and tools that many people use in your field
so that things run smoothly; an issues will have been fixed or patches.

Lots of people have also piled on extra complexity to get around
problems of sluggishness: being extra clever in avoiding repeating the work.

Or just throwing an extra 31 cores at the problem.

> (There's nothing wrong with
> doing it for your own benefit - I am not suggesting you have to fight
> for other people.)

This is an analogy I have used before regarding LLVM, which is a backend
for language implementations. It is quite large and complex.

Once I needed a side-gate for my house. I made it myself, and ended up
with a 6' high wooden gate, of just the right size.

Now if I'd gone to the LLVM shop as a solution, the gate would have been
9 miles high - if I could ever figure it out.

> Have you considered whether there are other battles
> that would make more sense or have greater impact? Have you considered
> forgetting it all, splashing out £300 on a new mini-PC, installing Linux
> Mint, and going back to having fun with computers, learning new things,
> and creating software without bothering about how much space gcc
takes up?

Lots of people are having fun with retrocomputing, where they can be 99%
responsible for what's going on rather than 1%. And there is it can
challenging, in a fun way, to have limits on what is possible.

However, you're wrong about space ceasing to be an issue: devices such
as smartphones, despite having GBs of storage rapidly get filled up
because every downloaded app is 10s of MB and sometimes 100s.

Because nobody cares anymore.

>>
>> 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.
>
> I fail to see how that's better than "make" (or "make mingw" on
> Windows).

And here is the crux. You really believe that you can solve 'complexity'
by hiding it away in a box and providing one simple launch button.

My preference is to tackle complexity by actually (gasp!) making it
simpler not just piling on even more stuff.

(Here's the David Brown approach to editing a messy 10,000-page draft of
a book down to 500 pages: just print it in a smaller font to fit into
500 pages; easy!

Or publish it on Kindle: nobody has a clue how long anything is on one
of those anyway. It will just take ages to get from 0% to 1%.

You might object, but this is exactly what happens with software: there
we now have unlimited amounts of program memory, and NOBODY apparently
cases about size, bloat, inefficiency and gratuitous complexity.

Well, until it comes to the difference between say Tcc and gcc/LLVM,
where 99% of the latter's build time is spent making programs twice as
fast as with the 180KB tcc.exe.

Then that mere 2.0 factor becomes hugely important, it cutting down
lesser compilers down to size.

> I /do/ see how "make" is vastly superior, because the
> makefile has lots more in it than just the dependencies that could be
> found automatically. Where does "mm lua" put all the compiler flags?

If you wanted to build my 'qq' interpreter, I could provide these three
files:

c:\demo>dir
17/08/2023 16:51 17 makefile
17/08/2023 16:54 438,272 mm.exe
17/08/2023 16:52 581,891 qq.ma

Unlike a normal source bundle, I provide the compiler needed. This is
one of many advantages of a small self-contained compiler. The source
files have also been bundled into one file.

The makefile contains this:

qq:
mm qq.qa

(I can't test it because make disappeared with gcc. I tried downloading
one but it had missing DLLs. So, forget it.)

So to build, you can either do:

make # needs 'make' installed

or:

mm qq.qa

Satisfied? My compiler is intrinsically simple. The end result is a
working interpreter.

Michael S <already5chosen@yahoo.com> writes:
>On Thursday, August 17, 2023 at 7:01:51=E2=80=AFPM UTC+3, Scott Lurndal wro=
>te:
>> Michael S <already...@yahoo.com> writes:=20
>> >On Wednesday, August 16, 2023 at 1:52:46=3DE2=3D80=3DAFPM UTC+3, David B=
>rown wrot=3D=20
>> >e:=20
>> >> Certainly embedding it within other applications is a major purpose of=
>=3D20=20
>> >> the language, yes. It is becoming more mature as a stand-alone=3D20=20
>> >> language, with more libraries, but it is very popular for adding to=3D=
>20=20
>> >> other programs. As you say, Lua is a common choice for scripting in=3D=
>20=20
>> >> games. I used it myself as a scripting language in an embedded program=
>,=3D=20
>> >=3D20
>> >> many moons ago.=20
>> >=20
>> >Did it work?=20
>> >I mean, not an easy technical part of embedding an interpreter.=20
>> >Did the "human" part work? Did people that were supposed to write=20
>> >scripts bothered to learn the language and to start writing?
>> We also have some stand-alone[*] software that runs on our CPUs=20
>> that uses an embedded lua interpreter. Users have had no problems=20
>> with it at all.=20
>>=20
>> [*] in this context, bare-metal sans OS.
>
>Who are users in this case?

Firmware engineers, customer field support engineers and in some
cases, customers.