Re: Python recompile

On 07/03/2025 21:35, Lawrence D'Oliveiro wrote:

On Fri, 7 Mar 2025 14:00:13 +0000, bart wrote:
 

My view is that building from source should be made as simple as
possible. As easy as compiling hello.c.

 For nontrivial open-source projects, that cannot be done without some help
from the operating system. We have already seen, from your struggles with
the Python source, how proprietary OSes like Microsoft Windows seem to go
out of their way to make things difficult for users to build things.
 The whole design of Unix from the beginning was not to impose artificial
distinctions between “users” and “programmers”. Indeed, *nix systems allow
for a whole spectrum of usage patterns with different levels of automation
in them, from point-and-click GUIs, through scripting languages, to full-
on compile-link build workflows.
 

So, how about Linux? Here I don't believe in using conditional code, so
there is a special source version for Linux, let's say it's qu.c:

 That’s bad. Now you have to maintain two parallel sets of source.
 

* No configure scripts
>
* No makefiles
>
* No #ifdef blocks
>
* No header files (in fact virtually no macros in the source file)
>
* Virtually no compiler options, except what are mandatory. Users can
    add -O, -o and -s options if they want.
>
* And the entire distribution for your platform is a single C file

 All at the expense of requiring more work from the human developers/
maintainers.

You mean, more work in not needing to create makefiles, or work out dependency graphs, or generate configure scripts, or enumerate compiler options?
Have you considered how much effort could be saved by keeping things simple?
Some of this approach is actually used in some projects, for example the single-file version of sqlite3.c, or the single-file version of Lua, because it makes its deployment, embedded within an application, for example, far simpler and less error prone.
People have enough trouble with their own dependencies, without having to worry about a sprawling directory tree of a library they want to incorporate.
This what it looks like, even using gcc:
   c:\cx>gcc sql.c -o sql               # sql.c is shell.c + sqlite3.c
   c:\cx>sql
   SQLite version 3.25.3 2018-11-05 20:37:38
   Enter ".help" for usage hints.
   Connected to a transient in-memory database.
   Use ".open FILENAME" to reopen on a persistent database.
   sqlite> .q
   c:\cx>gcc lua.c -o lua
   c:\cx>lua hello.lua
   Hello
It can work on Linux too:
   root@DESKTOP-11:/mnt/c/cx# gcc lua.c -olua -lm -ldl
   root@DESKTOP-11:/mnt/c/cx# ./lua hello.lua
   Hello
Show me where the makefiles or configure scripts are; they don't exist!
You can still create a makefile if you like, but it would be quite a short one:
  lua.exe:
gcc lua.c -o lua
I guess this one has a bigger chance of success. You also don't need a tool to generate it.

Those of us who are accustomed to *nix systems consider the computer as a
tool to lift the burden of the hard work from us, not to make more work
for us.

I see it as generating unnecessary work. /You/ would never understand that until you realise that building your project first involves running 35,000 lines of gobbledygook in a language not supported by your machine.
Your view is that that 35Kloc *must* be absolutely essential, mine is that at least 99% of it is pointless.

Seems like Microsoft Windows inculcates a different attitude ...

I developed commercial apps for MSDOS then Windows for about 15 years. I never used the tools you seem to think are indispensable under Unix, and I never had any problems.
(But then, I never had the need to build, from source, third party libraries that originated on Unix-like systems which could only be built on those systems. I either used my own libraries, or binaries were included with Windows.)