Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Fri, 14 Mar 2025 15:15:17 -0700
Organization: None to speak of
Lines: 122
Message-ID: <87senfi7ii.fsf@nosuchdomain.example.com>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vqefn1$3flpt$1@dont-email.me>
	<vqeu5c$3imil$1@dont-email.me> <vqeun4$3iqbq$1@dont-email.me>
	<vqfcbe$3lkkc$1@dont-email.me>
	<871pv861ht.fsf@nosuchdomain.example.com>
	<20250308192940.00001351@yahoo.com> <vqi1ge$8jg8$1@dont-email.me>
	<vqmgjv$3a2il$1@paganini.bofh.team> <vqn4dn$1eb9s$1@dont-email.me>
	<vqo3ss$3hkas$1@paganini.bofh.team> <vqph2e$203bs$2@dont-email.me>
	<vqvtop$cpvn$1@paganini.bofh.team> <vr1nkh$1miii$1@dont-email.me>
	<G8_AP.37556$D_V4.24121@fx39.iad> <vr1uk1$1sb5s$1@dont-email.me>
	<874izvjs4m.fsf@nosuchdomain.example.com>
	<vr27td$22vgq$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 14 Mar 2025 23:15:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="bbf3b2da6e551caad2cd296cab2812d3";
	logging-data="2179411"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19LNJHjQsJaQcWUQIy79BPl"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:y4yoEvsQzmA2rs70aWgvup/x+zE=
	sha1:XnI5lxbSuCvGbvpXyN00AgUYn/8=

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 */