Re: Python recompile

On 11/03/2025 20:37, Lawrence D'Oliveiro wrote:

On Tue, 11 Mar 2025 14:24:15 +0000, bart wrote:
 

On 11/03/2025 01:33, Waldek Hebisch wrote:
>

You apparently do not get fact that people want tools to automate
various routine tasks.

>
What routine task is this? I'm talking exclusively about turning a bunch
of source files in some language (here it is C) into an executable
binary.

 Interesting that you don’t see an app build as a “routine task”.
 Think of how often, while developing a program in (at least partly) a
compiled a language, you have to go through
      edit → build → run → crash
 ad nauseam.
 This is why we have makefiles, because usually the whole source does not
need to be recompiled each time, only the parts that have changed since
the last run.

That has never, ever been a problem. In the past, using independent compilation, because I was familiar with what need to be recompiled (altough a full build was only seconds anyway).
And now a full build is more or less instant using my own tools.
For me, independent compilation (of the modules of one binary) is old hat. Linking is old hat (whatever it does, I replaced it in about 1983).
You have machines now that are 1000 times faster than what I was using, and yet compilation time is still be an issue unless you use all these tricks?
Apparently the answer is to pile on more layers of complexity, that'll speed it up!
(Hint: if your car can only do 3mph, then you need to get a faster car, not either look for short cuts, or avoid going anywhere.)

 

However, what I'm arguing about is that this simple task has become
unnecessarily elaborate on OSes like Linux, by introducing makefiles,
OS-specific scripts, and OS-specific utilities.

 And yet all that automation makes it quite easy to build quite complex
apps on Linux. You were the one who had trouble on Windows.
 

If scripts are going to be used, then use them at the developer site
only, and make the script generate the streamlined set of files for the
particular platform of interest.

 Funny, that’s how Autotools works (generating the configure script from
the much more human-readable configure.ac source), and yet you were
complaining about what an unreadable blob it produced.

The output would be something like this, to build a standalone Lua.exe on Windows for example:
gcc -O3 -o lua 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 -ldl

It should not rely on anything that is not native to the target
platform.

 Unfortunately that rules out developing for Windows completely, since
there is essentially nothing development-related that is native to
Windows. Everything has to be added on.

You have to assume a compiler, since this is not bundled with source code anyway. Then, what else is there that is not source code?

To build open source projects, I'm happy to use an existing C compiler.
I'm NOT happy about bending over backwards to use CYGWIN, MSYS2 or WSL
because the developers insist on forcing their Linux dependencies down
my throat.

 Beggars can’t be choosers. As long as you don’t have the skills or
patience to actually contribute to such development, you have to accept
what you get.

Have you actually tried it? I mean what I suggested in taking a project, and extracting the most basic steps. Like the invocation of gcc above. You might start questioning all this pointless complexity yourself.
There's actually something magical about that gcc invocation: it works on both Windows and Linux. Pretty amazing, yes? (OK, I had to add the '-lm -ldl' bits.)