Re: Python recompile

On 10/03/2025 11:45, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

Oh dear, that hasn't worked either.

 Hmm, it AFAICS worked.  That is you wanted build failure and you
got build failure.

In last year's thread I did an experiment with I think 5 projects, and most failed to build using the provided tools.
In the case of Lua, there was an additional complication in that one lot of online sources was incomplete (missing the top directory layer). However what was provided still had a makefile, to confuse matters.
But even with the full sources, there was a catch - see below.

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.

It will nearly always do. In the case of LIBJPEG, there are 5 binaries to build including the two main ones (encode and decode). Each of those comprises 8 .c files, plus they share 46 other .c files.
The official makefile (the fallback one as there were lots!), built those 46 into a .a archive, but which was then /statically/ linked into each executable, so it didn't save any space.
I had to get it working once via the makefile, and arrange to capture the shell commands used in order to determine all this.
 From those, I was able to create two @ files so that I could build only using a compiler. Each file simply lists the 54 files that are needed, and is 4% the size of the makefile. (They can also use a shared @ file to avoid repeating the shared files.)
Using tcc, each program builds from source in 0.3 seconds using such a list, even though 46 source files are processed twice.

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.

I always build lua.exe. I mentioned that luac.c was for embedded, or something.

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

Actually, looking at the docs more carefully, it seems the makefiles only work for Linux.
For Windows you are on you own. But at least it does list the files involved.
However, I thought the point of 'make' was that you just typed 'make' and it goes and builds your program with no further input. Here, the makefile could have provided a helpful message saying that Windows was not supported.

 

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 ....

So they usually worked after you fixed all the problems? OK!

You miss important point of sources: having sources and free
licence means that anybody can develop program further.

There are two things you may want to do when building sources:
(1) You want to do further development as you say
(2) You simply want to build a working binary and have no interest in anything else.
Those two requirements are utterly different, yet most developers who provide sources ignore that, and simply provide the entire directory tree and a hundred other things that might be needed for (1).
For (2):
* You don't need a sprawling directory tree; files can be flattened into
one folder
* (You don't need separate files; they can be flattened into one file via various tools and scripts. In my case, I do that via a transpiler. For C, this provides the opportunity for whole-program optimisation.)
* You don't need makefiles with tons of dependency info. This stuff is for incremental compilation, but here we are only building once, so it has to be done from scratch anyway. It is not time-critical.
* You might still need to orchestrate the building of multiple binaries,
or to install the result, but for this there are better scripting languages than 'make'. Even C will do, for which the user will already have a compiler. (IMV installation is a quite different process from building.)
* If this is for a known platform, then the process can be streamlined further
Examples of (2) for me are GMP and LIBFFI libraries which are a nightmare to build on Windows.

 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.

You really want to fix things in gcc for example by messing with the source files? I think we establshed that there were at least 79,000 .c files. (Better set aside the rest of the decade to get familiar with it!)

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).

I provide source code for reason (2) above. This is likely to be amalgamated into one file, or transpiled to one C file
For (1), I can provide original source files, but building source in my personal language is problematical. For a start, you need a binary to get started, but people don't like binaries because of AV issues or lack of trust.
(They generally work for mainstream products on Windows; presumably the providers are whitelisted by MS, even if they are not in the MS Store.)