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, 7 Mar 2025 14:00:13 +0000
Organization: A noiseless patient Spider
Lines: 113
Message-ID: <vqeu5c$3imil$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq3oag$18iv6$1@dont-email.me>
 <vq4hf2$1brf7$1@dont-email.me> <vq4l3d$1ck9e$1@dont-email.me>
 <vq4m0u$1ctpn$1@dont-email.me> <vq4n05$1d5dv$1@dont-email.me>
 <vq4om7$1dbo2$2@dont-email.me> <vq6dqh$1pskk$1@dont-email.me>
 <vq6f8p$1pmnk$1@dont-email.me> <vq6gqc$1qcp8$1@dont-email.me>
 <vq6ips$1pmnk$2@dont-email.me> <vq6j5h$1qosf$1@dont-email.me>
 <20250304092827.708@kylheku.com> <vq7g1p$1vmg5$1@dont-email.me>
 <vq94dt$2boso$1@dont-email.me> <vqcsk7$23bfo$1@paganini.bofh.team>
 <vqefn1$3flpt$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 07 Mar 2025 15:00:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ef0e5752bdffd2710a2294b6a977f418";
	logging-data="3758677"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18YNI/58a22RC4YeMJTS2un"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:mkNoBVZe1BGeNNfzNFQvQABJSWw=
Content-Language: en-GB
In-Reply-To: <vqefn1$3flpt$1@dont-email.me>
Bytes: 5909

On 07/03/2025 09:53, Muttley@DastardlyHQ.org wrote:
> On Thu, 6 Mar 2025 19:21:45 -0000 (UTC)
> antispam@fricas.org (Waldek Hebisch) wibbled:
>> In comp.lang.c Muttley@dastardlyhq.org wrote:
>>> On Tue, 4 Mar 2025 18:16:25 +0000
>>> bart <bc@freeuk.com> wibbled:
>>>> The CPython source bundle doesn't come with any makefiles. The first
>>>> step appears to be to run a 35,000-line 'configure' script. Part of its
>>>
>>> Frankly any build system that has a 35K configure file needs revisiting.
>>> No package is so complex as to require that much setup. OS specific code
>>> should be dealt with some appropriate ifdefs in the source and libraries
>>> and linking should be a few 10s of lines.
>>>
>>> Back in the day packages used to hve different preprepared Makefiles for
>>> each system they could build on and IME that tended to work a lot better
>>> than configure scripts that tried to figure things out on the fly.
>>
>> I remember times when source package came with README file saying
>> edit this and that to configure for your system.  Typically one
>> had to edit Makefile and possibly something like config.h.  For
> 
> Header files should never have to be manually edited unless the person who
> wrote the code didn't know wtf they were doing. #ifdef exists for a reason
> and if thats not enough makefiles can always manually concat stuff into a
> header.
> 
>> me it worked quite well.  But those times are gone.  Most people
>> now do not know essential information about system they use, so
>> are unable to provide sensible values.  And modern programs are
> 
> Those sorts of people should just install prepackaged binaries, not be building
> from source.

My view is that building from source should be made as simple as 
possible. As easy as compiling hello.c.

I think it was 2014 that I first posted here a link to a C file that did 
exactly that, just about. It was a single file implementation of a 
substantial interpreter project, nearly 20Kloc, but transpiled from its 
original non-C language.

I don't have that anymore, the nearest is the 'qc.c' example used below, 
which is 40Kloc. This works with multiple compilers on Windows, here 
tested with three:

   c:\qx>bcc qc
   Compiling qc.c to qc.exe

   c:\qx>gcc qc.c

   c:\qx>tcc qc.c -luser32 c:\windows\system32\kernel32.dll 
-fdollars-in-identifiers

gcc generates a.exe so needs an extra option for that, but then so does 
hello.c. tcc doesn't like '$' in names, so needs that special option 
(why doesn't it just allow them?!). I couldn't just use -lkernel32 
either as one imported symbol was missing.

So, how about Linux? Here I don't believe in using conditional code, so 
there is a special source version for Linux, let's say it's qu.c:

   root@DESKTOP-11:/mnt/c/qx# gcc qu.c -lm -ldl -fno-builtin

Here it's a little bit more work, and it produces a.out. But tcc is 
about the same:

   root@DESKTOP-11:/mnt/c/qx# tcc qu.c -lm -ldl -fdollars-in-identifiers

So:

* No configure scripts

* No makefiles

* No #ifdef blocks

* No header files (in fact virtually no macros in the source file)

* Virtually no compiler options, except what are mandatory. Users can
   add -O, -o and -s options if they want.

* And the entire distribution for your platform is a single C file

Note that if downloadeding pre-built binaries, you will usually have a 
separate binary file for each platform. The same here: a separate C file 
per platform.

When I posted about this before, lots of people got the notion that my 
development process was also based single monolithic source file. That's 
completely wrong. (This project is about 30 modules and the C file is 
generated with a tool.)

This is about the distribution of a working, finished product to 
somebody who wants to build from source code so they can use it.

Too many projects just expect that user, to grapple with the same, 
sprawling directory structure that the developer works with. Which means 
elaborate makefiles full of dependency info.

What I provided was one step back from a binary file.

(Actually, with my bcc compiler, the product can be run from source:

    c:\qx>bcc -r qc hello
    Compiling qc.c to qc.(run)
    Hello, World! 7-Mar-2025 13:57:12

So you could consider this an 'executable'. But it might blow some 
people's minds though.)