Re: Python recompile

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.

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.  That can be alleviated by testing the end-user build system
before each release, but that testing is extra effort.

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.

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.

I don't know.  I haven't seen many such libraries.  Perhaps there are
more than I'm aware of.

[...]

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.

Build systems can be convoluted.

Next strawman?

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.

See <https://en.wikipedia.org/wiki/SQLite#Operating_systems> for a list
of 18 operating systems that include SQLite by default.  I haven't even
heard of all of them.

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!

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

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */