Re: Python recompile

On 14/03/2025 22:15, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 14/03/2025 20:04, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 14/03/2025 18:00, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

[...]

What I'm suggesting goes in the middle. A minimal, streamlined set of
sources, possibly amalgamated (which helps if the user wants to
incorporate this product into their own), with a minimal set of
dependencies.

Why on earth would a developer do this just to make -your- life
easier?   Nobody else is complaining endlessly about it.

>
Perhaps you'd like to answer the question I posed about why bother
with distributing software as binaries if building from source is so
effortless.

Nobody said it was "effortless".  You made that up.

 No response to that?
 You misrepresent what others have said, and don't reply when it's
pointed out.
 If you can cite someone here actually saying that building from source
is "effortless", I'll retract this statement.

Every single post arguing against me implies that it is effortless: that is, all you have to do is type 'make'.
NO ONE wants to admit to building can be a difficult process. Or they do, they will not admit of any alternative but to provide a binary.

I can install a binary software package on my computer without
needing a compiler, and it typically takes a few seconds because
someone else has done the work of building it.  I happen to have
a compiler, but not everyone does.  If I have the sources, I can
probably install a newer version than my OS makes available, and
perhaps I can choose some configuration options.  And yes, it's a
bit more effort.

>
A 'bit more effort' is an understatement. It needs more
dependencies. It will take much longer. And it's more likely to fail.
>
So I suggested an intermediate compromise that is suited for when your
aim /isn't/ to work on the product yourself.

 If I understand correctly, you want one build system for developer and
a simpler one for end users.  Is that accurate?
 By all means feel free to make such a thing.  But having two different
build systems means they both have to be maintained.  It makes it more
likely that something works correctly for the developers and fails for
end users.

Wouldn't that be the case for both types of build? And which one kind is more likely to fail?
You can well find that a simpler build process results in fewer issues overall.

And it's useful only for end users who build from source.  I do that,
but most users don't.  Even in my case, the vast majority of the
software on my system is installed from pre-built binaries via the OS's
package management system.  For a more typical user, it's likely that
all of it is.

So in a sense the simpler build system you want already exists: copying
binary files to where they need to be.

If a binary files exists, and if AV will let me download it, or run it.
I have a problem supplying binaries to anyone who wants to run my programs on their Windows machine. So I use my own intermediate representations. They look like this:
   c:\qx>mc -c qc
   M6 Compiling qc.m---------- to qc.c
   c:\qx>dir qc.c
   14/03/2025  22:39         1,095,211 qc.c
'mc' is a transpiler which converts dozens of modules into one C file. That C file is what is downloaded by the user. The build process on Windows is this:
   c:\qx\gcc qc.c
You see how utterly simple it can be and how trivial it is to build?
The file I generate corresponds 1:1 with the binary file that I would have prefered to provide. It's as simple as a binary, and needs only that one-line step to turn into an actual binary.
The above is for Windows however; for Linux it's a bit harder:
   c:\qx>mc -c -linux qc -out:qu
   M6 Compiling qc.m---------- to qu.c
Here gcc on Linux needs a couple more options, and a binary would not be an option even without AV issues.
So, a build CAN be this simple. You might say, these are small products and real ones are more complicated. Well take a look at NASM: https://github.com/netwide-assembler/nasm/tree/master, and in INSTALL.
It supposedly builds on Windows, but I can't make head or tail of the instructions. There are 2000 files here in two dozen directories.
NASM is an x64 assembler; I have one of those too; I can also provide a single C file which can be trivially built.
So your arguments are spurious. You're making excuses about why such things are not possible or are too hard while knowing little about it.

As I showed, it is very easy when you dump the 'convoluted' build system!

 Great.  Show us how you can "dump the 'convoluted' build system" for,
say, GNU coreutils.

I don't know those products. Maybe they are already ten times more complex than need be. For the products I create (compilers, interpreters, assemblers, backends) there is no build system to speak of, and I've showed two examples.
The build process involved download and compiling one source file. Sorry, I haven't managed to reduce it to zero source files!