Re: Python recompile

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