Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Tue, 11 Mar 2025 22:02:37 +0000
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <vqqbtt$267fp$3@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <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> <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> <vqq6tp$25gtn$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 11 Mar 2025 23:02:38 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e0b1512e31c88b1cbe05a7f62cb3028b";
	logging-data="2301433"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19bEU6euT9AOnXwmxQt9tyi"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:SfUpTQnsmCvbZwdqVB8w/iwXTpE=
In-Reply-To: <vqq6tp$25gtn$3@dont-email.me>
Content-Language: en-GB
Bytes: 5619

On 11/03/2025 20:37, Lawrence D'Oliveiro wrote:
> On Tue, 11 Mar 2025 14:24:15 +0000, bart wrote:
> 
>> On 11/03/2025 01:33, Waldek Hebisch wrote:
>>
>>> You apparently do not get fact that people want tools to automate
>>> various routine tasks.
>>
>> What routine task is this? I'm talking exclusively about turning a bunch
>> of source files in some language (here it is C) into an executable
>> binary.
> 
> Interesting that you don’t see an app build as a “routine task”.
> 
> Think of how often, while developing a program in (at least partly) a
> compiled a language, you have to go through
> 
>      edit → build → run → crash
> 
> ad nauseam.
> 
> This is why we have makefiles, because usually the whole source does not
> need to be recompiled each time, only the parts that have changed since
> the last run.

That has never, ever been a problem. In the past, using independent 
compilation, because I was familiar with what need to be recompiled 
(altough a full build was only seconds anyway).

And now a full build is more or less instant using my own tools.

For me, independent compilation (of the modules of one binary) is old 
hat. Linking is old hat (whatever it does, I replaced it in about 1983).

You have machines now that are 1000 times faster than what I was using, 
and yet compilation time is still be an issue unless you use all these 
tricks?

Apparently the answer is to pile on more layers of complexity, that'll 
speed it up!

(Hint: if your car can only do 3mph, then you need to get a faster car, 
not either look for short cuts, or avoid going anywhere.)

> 
>> However, what I'm arguing about is that this simple task has become
>> unnecessarily elaborate on OSes like Linux, by introducing makefiles,
>> OS-specific scripts, and OS-specific utilities.
> 
> And yet all that automation makes it quite easy to build quite complex
> apps on Linux. You were the one who had trouble on Windows.
> 
>> If scripts are going to be used, then use them at the developer site
>> only, and make the script generate the streamlined set of files for the
>> particular platform of interest.
> 
> Funny, that’s how Autotools works (generating the configure script from
> the much more human-readable configure.ac source), and yet you were
> complaining about what an unreadable blob it produced.

The output would be something like this, to build a standalone Lua.exe 
on Windows for example:

gcc -O3 -o lua lua.c lapi.c lcode.c lctype.c ldebug.c ldo.c ldump.c 
lfunc.c  lgc.c llex.c lmem.c lobject.c lopcodes.c lparser.c lstate.c 
lstring.c ltable.c ltm.c lundump.c lvm.c lzio.c lauxlib.c lbaselib.c 
lcorolib.c ldblib.c liolib.c lmathlib.c loadlib.c loslib.c lstrlib.c 
ltablib.c lutf8lib.c linit.c -lm -ldl

>> It should not rely on anything that is not native to the target
>> platform.
> 
> Unfortunately that rules out developing for Windows completely, since
> there is essentially nothing development-related that is native to
> Windows. Everything has to be added on.

You have to assume a compiler, since this is not bundled with source 
code anyway. Then, what else is there that is not source code?


>> To build open source projects, I'm happy to use an existing C compiler.
>> I'm NOT happy about bending over backwards to use CYGWIN, MSYS2 or WSL
>> because the developers insist on forcing their Linux dependencies down
>> my throat.
> 
> Beggars can’t be choosers. As long as you don’t have the skills or
> patience to actually contribute to such development, you have to accept
> what you get.

Have you actually tried it? I mean what I suggested in taking a project, 
and extracting the most basic steps. Like the invocation of gcc above. 
You might start questioning all this pointless complexity yourself.

There's actually something magical about that gcc invocation: it works 
on both Windows and Linux. Pretty amazing, yes? (OK, I had to add the 
'-lm -ldl' bits.)