Re: Python recompile

On 08/03/2025 15:51, Muttley@dastardlyhq.com wrote:

On Sat, 8 Mar 2025 14:09:17 +0000
bart <bc@freeuk.com> gabbled:

My idea is similar to supplying binaries, but replacing each binary file with one C source file. This now needs a C compiler to turn into a binary, but nothing else. No configure, no makefiles, virtually no special options, no special compiler needed and no special version.

 So instead of just typing "make" the user has to know how to invoke the
compiler, possibly with certain switches set. Not sure how thats any better.

I've just typed 'make' in a Windows prompt. Nothing happens ('command not recognised'). That's a good start!
If I look at my gcc binaries, there's a program called 'mingw32-make.exe'. Maybe that's the one. However, build instructions call for 'make' so it will immediately fail.
What Make does is take a mountain of complexity called a 'makefile', which is special kind of arcane language, and tries to run it. It might work, it might fail immediately, or it might grind away for several minutes and then it stops.
Why I am aiming for is to be able to just type:
    gcc prog.c
But apparently that won't do. Some smart-arses will point out that that's more typing than 'make'. Others, less smart, don't actually know how to directly invoke a compiler like this.
Now, it's been a while since I've argued about makefiles and all their woes. But maybe things have changed. If I copy that file above to 'make.exe', and navigate to a folder full of Lua source files, I see it also has this:
   c:\luac>dir make*
   02/02/2024  13:18             7,722 Makefile
So according to you, this should be a piece of piss. OK, I'll try it:
   c:\luac>make
   makefile:103: target 'AIX' given more than once in the same rule
   makefile:117: target 'FreeBSD' given more than once in the same rule
   Guessing `uname`
   make[1]: Entering directory 'c:/luac'
   makefile:103: target 'AIX' given more than once in the same rule
   makefile:117: target 'FreeBSD' given more than once in the same rule
   make[1]: *** No rule to make target '`uname`'.  Stop.
   make[1]: Leaving directory 'c:/luac'
   make: *** [makefile:101: guess] Error 2
That went well! Maybe this is the wrong one, and I've been messing about with these files. So I download a fresh Lua versiom as a .tar.gz file and install it. Yes, there were in fact two makefiles, one in a higher directory level:
   c:\ll\lua-5.4.7>dir
   13/06/2024  22:16    <DIR>          .
   08/03/2025  16:15    <DIR>          ..
   13/06/2024  22:16    <DIR>          doc
   08/05/2024  21:47             3,150 Makefile
   13/06/2024  22:16               151 README
   13/06/2024  22:15    <DIR>          src
I now follow the instructions from here: https://www.lua.org/download.html and do this:
   c:\ll\lua-5.4.7>make all test
   make[1]: Entering directory 'c:/ll/lua-5.4.7/src'
   makefile:101: target 'AIX' given more than once in the same rule
   makefile:115: target 'FreeBSD' given more than once in the same rule
   .....
   make[2]: Leaving directory 'c:/ll/lua-5.4.7/src'
   make[1]: *** [makefile:99: guess] Error 2
   make[1]: Leaving directory 'c:/ll/lua-5.4.7/src'
   make: *** [makefile:55: guess] Error 2
Oh dear, that hasn't worked either. So now what? Maybe forget all that, and just for a prebuilt binary here: https://github.com/rjpcomputing/luaforwindows/releases. However, that's an old 5.1 version.
Or I could just build Lua the easy way:
   c:\ll\lua-5.4.7\src>del luac.c
   c:\ll\lua-5.4.7\src>gcc *.c -o lua
   c:\ll\lua-5.4.7\src>lua
   Lua 5.4.7  Copyright (C) 1994-2024 Lua.org, PUC-Rio
   >
This works! No crappy makefiles needed. Here I happened to know it involves compiling 33 of the 34 C files supplied (luac.c is for embedded I think).
The makefiles are full of useless dependency info. Lua is a small program, and I just want to use it, not develop it. So it only needs to be built once, and the makefile then could then be ultra-simple; it might even work!
In any case, tcc builds it in 1/4 of a second.

which has a load of ifdefs in the code itself and the user doesn't

have to

do anything except pick the correct makefile or for windows project

file.
>
I suspect you either haven't done much building of open source software on Windows, or were remarkably lucky.

 True. I've done a small amount of C/C++ dev on Windows but these days I wouldn't touch it with a 10 foot pole and rubber gloves.

The problem is not with Windows!
The real problem is that you are so over-reliant on all the variety of tools within your Linux eco-system, that you are lost in an environment where that doesn't exist.
I find it easy to develop on Windows because I have few dependencies, and I would find it easy to develop on Linux - if I had to. (However it has some annoying things would drive me up the wall.)