Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Fri, 14 Mar 2025 23:16:06 +0000
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <vr2dbm$2995t$1@dont-email.me>
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>
 <87senfi7ii.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 15 Mar 2025 00:16:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="14d72ed8b9f39470873bf90fad2cad9d";
	logging-data="2401469"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+68k1jVkIdUFdz8TXE2z28"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qpRxSaTQXPK94y32gmOgE1fz+38=
Content-Language: en-GB
In-Reply-To: <87senfi7ii.fsf@nosuchdomain.example.com>
Bytes: 6917

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!