Re: Python recompile

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.

 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.
But people like you are downplaying the differences, and pissing all over my suggestions.
(Yet, when products that include part-compiled code, such as JVM, or that has final JIT-compilation applied at the user-site, will undoubtably be lauded here. Even though they are a similar concept.)

Or maybe, why single file amalagamations like sqlite3.c
exist. After all no one (according to you) was complaining about
grappling with 100 discrete files.

 Think about why single file amalgamations like sqlite3.c are so
rare.  There isn't much demand for them.

Is that true? Libraries whose source is presented as either one .h and one .c file, or even a single .h file, seem popular.
For example I use one called stb_image.h, which contains loaders or decoders for 9 different image format.
Contrast with LIBJPEG which needs 54 .c files (and a bunch of .h files) just to decode JPEG. Which one is going to be easier to deploy if you just want to statically add that capability to your project?
(Or will people still insist that want everyone wants to really do is mess about with the source code?)
There's a few more here: https://github.com/r-lyeh/single_file_libs
Here's a comment from Reddit in response to 'Are single header libraries good?':
"They're great for simple commonly-used things. Users don't have to download a crap ton of files, figure out some convoluted build system, or troubleshooting linking files together. You can usually just copy the header file and immediately use it by adding two lines of code."
BTW I didn't post that. In this newsgroup, no one here is ever going to admit that build systems can be convoluted. But it becomes important if trying to integrate such projects into yours.

I think that SQLite3 is
designed with portability in mind far more than most software is.
Presumably its developers expend considerable effort to keep it
that way, effort that developers of other software probably don't
feel the need to expend.

It works on Windows and Linux; that's not exactly ultra portable.

For most software packages, building them from source is reasonably
easy.  I don't care how big that the "configure" script is, because
99.9% of the time I don't even look at it.  It takes some time to
run, and sure, that could probably be streamlined, but I typically go
off and do other things while it's running.

sql.c (a standalone product using sqlite3.c) takes 0.25 seconds to build. Or 0.15 seconds if I choose to interpret it.
Even gcc only takes 7 seconds, and this is a 1MB excutable. Not really much time to do anything.

I'm aware that it's not
so easy in your environment.

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