Path: ...!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Mon, 10 Mar 2025 11:45:30 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vqmjco$3a86r$1@paganini.bofh.team>
References: <vq1qas$j22$1@gallifrey.nk.ca>   <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> <vqeu5c$3imil$1@dont-email.me> <vqeun4$3iqbq$1@dont-email.me> <vqfcbe$3lkkc$1@dont-email.me> <vqh569$3e9d$1@dont-email.me> <vqhj2e$5u26$1@dont-email.me> <vqhp18$75es$1@dont-email.me> <vqhs8o$7o8n$1@dont-email.me>
Injection-Date: Mon, 10 Mar 2025 11:45:30 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="3481819"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 7581
Lines: 141

bart <bc@freeuk.com> wrote:
> On 08/03/2025 15:51, Muttley@dastardlyhq.com wrote:
>> On Sat, 8 Mar 2025 14:09:17 +0000
>> bart <bc@freeuk.com> gabbled:
>>> My idea is similar to supplying binaries, but replacing each binary 
>>> file with one C source file. This now needs a C compiler to turn into 
>>> a binary, but nothing else. No configure, no makefiles, virtually no 
>>> special options, no special compiler needed and no special version.
>> 
>> So instead of just typing "make" the user has to know how to invoke the
>> compiler, possibly with certain switches set. Not sure how thats any 
>> better.
> 
> I've just typed 'make' in a Windows prompt. Nothing happens ('command 
> not recognised'). That's a good start!
> 
> If I look at my gcc binaries, there's a program called 
> 'mingw32-make.exe'. Maybe that's the one. However, build instructions 
> call for 'make' so it will immediately fail.
> 
> What Make does is take a mountain of complexity called a 'makefile', 
> which is special kind of arcane language, and tries to run it. It might 
> work, it might fail immediately, or it might grind away for several 
> minutes and then it stops.
> 
> Why I am aiming for is to be able to just type:
> 
>    gcc prog.c
> 
> But apparently that won't do. Some smart-arses will point out that 
> that's more typing than 'make'. Others, less smart, don't actually know 
> how to directly invoke a compiler like this.
> 
> Now, it's been a while since I've argued about makefiles and all their 
> woes. But maybe things have changed. If I copy that file above to 
> 'make.exe', and navigate to a folder full of Lua source files, I see it 
> also has this:
> 
>   c:\luac>dir make*
>   02/02/2024  13:18             7,722 Makefile
> 
> So according to you, this should be a piece of piss. OK, I'll try it:
> 
>   c:\luac>make
>   makefile:103: target 'AIX' given more than once in the same rule
>   makefile:117: target 'FreeBSD' given more than once in the same rule
>   Guessing `uname`
>   make[1]: Entering directory 'c:/luac'
>   makefile:103: target 'AIX' given more than once in the same rule
>   makefile:117: target 'FreeBSD' given more than once in the same rule
>   make[1]: *** No rule to make target '`uname`'.  Stop.
>   make[1]: Leaving directory 'c:/luac'
>   make: *** [makefile:101: guess] Error 2
> 
> That went well! Maybe this is the wrong one, and I've been messing about 
> with these files. So I download a fresh Lua versiom as a .tar.gz file 
> and install it. Yes, there were in fact two makefiles, one in a higher 
> directory level:
> 
>   c:\ll\lua-5.4.7>dir
>   13/06/2024  22:16    <DIR>          .
>   08/03/2025  16:15    <DIR>          ..
>   13/06/2024  22:16    <DIR>          doc
>   08/05/2024  21:47             3,150 Makefile
>   13/06/2024  22:16               151 README
>   13/06/2024  22:15    <DIR>          src
> 
> I now follow the instructions from here: 
> https://www.lua.org/download.html and do this:
> 
>   c:\ll\lua-5.4.7>make all test
>   make[1]: Entering directory 'c:/ll/lua-5.4.7/src'
>   makefile:101: target 'AIX' given more than once in the same rule
>   makefile:115: target 'FreeBSD' given more than once in the same rule
>   .....
>   make[2]: Leaving directory 'c:/ll/lua-5.4.7/src'
>   make[1]: *** [makefile:99: guess] Error 2
>   make[1]: Leaving directory 'c:/ll/lua-5.4.7/src'
>   make: *** [makefile:55: guess] Error 2
> 
> Oh dear, that hasn't worked either.

Hmm, it AFAICS worked.  That is you wanted build failure and you
got build failure.  Of course you are an export on building
Windows programs and have your tricks.  In this case a simple
one, like not having MinGW tools in the patch probably will do.

> Or I could just build Lua the easy way:
> 
>   c:\ll\lua-5.4.7\src>del luac.c
>   c:\ll\lua-5.4.7\src>gcc *.c -o lua
>   c:\ll\lua-5.4.7\src>lua
>   Lua 5.4.7  Copyright (C) 1994-2024 Lua.org, PUC-Rio
>   >
> 
> This works! No crappy makefiles needed. Here I happened to know it 
> involves compiling 33 of the 34 C files supplied (luac.c is for embedded 
> I think).

Not reading instructions help in writing newsgroup post.  If you
read documentation you would see that build process is supposed to
build 3 related products: Lua library, Lua interpreter and Lua
compiler (whatever the last things means).  The is explicit list
of files giving you the Lua library.  Link it with one extra file
(that is 'lua.c') and you get Lua interpteter.  Link the library
with 'luac.c' and you get the compiler.

Documentation also mention explicit targets, like 'make mingw'.
But you probably arranged things so that it fails too.

> The makefiles are full of useless dependency info. Lua is a small 
> program, and I just want to use it, not develop it.

AFAICS you want something to compile with your compiler and
claim that make fails.  When I needed to build programs on
Windows make usually worked.  Of course, I had to install
dependencies first.  I had to look at the PATH, in particular
watch out for Borland 'make' which was normally quite early
in the path, but Borland 'make' was to crappy and unable to
handle most Makefiles.  I am not sure if I needed to do this
on Windows, but on some systems I needed to correct sources
to get working program.  For such cases having all development
info was quite useful.

You miss important point of sources: having sources and free
licence means that anybody can develop program further.  In
particular people can do simple customization or bug fixes.
So if I find program useful, it is my decision if I want
to do work needed to keep it running on my system or port to
a different system.  I case of binaries it is usually unfeasible
to fix bugs or port it (people use emulators, but this has
limitations).  And if program is useful enough there is good
chance that sombody else already did the work.

BTW: I did have trouble with some Windows sources, and main
trouble was that source was incomplete or missed some needed
changes.  That is trouble was due to people who did not care
about distributing sources (but should have cared, as those cases
were Windows adaptions of GPL-ed things).

-- 
                              Waldek Hebisch