Re: Python recompile

bart <bc@freeuk.com> wrote:

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.

Libraries usualy save space compared to linking object files:
old-style linker includes all explicitely mentioned object
files, but only referenced object files from a library.
And library saves you effort to list object files, just
give single library name.

And compilng to .o files or .a saves time that otherwise would
be spent recompiling sources mutiple times.

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.

I would expect gcc-compiled libjpeg to be quite a bit faster.

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.

I had no need for Windows in recent time.  But Makefile looked fine,
I have no reason to doubt that it will work on Windows.  Of course,
the first thing uses 'uname' and will fail if appropiate directory
is not in the PATH.

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.

It first needed to check that you are on Windows with MinGW, but
apparently you prevented it from running program that would
detect this.

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!

If you consider properly installing a program and putting was
is needed in the PATH to be a problem, then yes I fixed the
problem.  You see, for people that used computers for some
time (even non-developers), those are obvious things.  And
usually what was needed were documented, so there was really
no need to think, just follow the instructions.  Current
users are conditioned to expect magic, that is programs
doing stuff like this behind the scene.  And part of crap
that you are complaining about is doing this.  But if you
interfere by hand then you break automation.  If your goal
is to complain that automation does not work, then you
get what you want.  If you want to do the job, manual
intervention must be complete, you need to compensate
for changes that you made.

Of course, I can not exclude bugs in say MinGW installer.
But you consistenly report troubles with things that work(ed)
for me and other folks.  And when you give some detail it
is clear that you do not follow instructions.  I know,
dong things "better" or "simpler" is tempting, and
several times I did thing my way (differently than official
way).  But if you do not _want_ to follow instructions, then
you are on your own resoling problems.

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

FYI, packages insist that to install files you run "install" program.
You may run it from a Makefile, you may run it from C code.
But if you have a Makefile for developement purpose, than it is
easier to run "install" from a Makefile.

You may be surprised, but packagers routinely apply modifications
to released sources.  Keeping track of them is easier when
there is no split between (1) and (2).  For example, packagers
for compatiblity reason may prefer keeping old version, but
selectively apply bug fix from developement version.  Or
packagers create a bugfix and want it included in developement
version.

And in general, not having separate "release build" is simpler.
In other worlds, splitting cases (1) and (2) adds to work of
all people developement releated work.

* 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!)

I fixed a few bugs in gcc.  Part of it is having options: at
configure time one can request inclusion of extra internal checks
in gcc, that simplifies debugging.  Part is proper use of debugger,
simplest things is segmentation violation.  In such case debugger
tells you exact locatiation of offending code.  So you can look
just at a single place in a single source file.  In other
cases breakpoint in error reporting function will tell you
which place detected error.  In case of wrong code it helps to
request dumps from various passes, that may give idea which
pass is responsible.  Of course, there is some work involved
in finding good fix.  Less popular programs may have very simple
bugs where fix is easy and can be done in few minutes.  In gcc
bugs with verys simple fix are less likely, so expect hours or
days of work in relatively easy cases.  And some things are
harder.

Point is, even if you do not want to debug gcc, there are
people which can do this.  And there is no need to understand
all of source code.

And you may wish to modify gcc.  Many years ago I did a
modification so that gcc treated all characters with codes
above 127 as letters.  At that time gcc did not support
Unicode in input, so for example source identifiers were
limited to ASCII.  With my patch gcc accepted various junk
in identifiers, but in particular all letters from popular
code pages and all UTF-8 letters.

You may get extra warnings or error messages or disable some
(modern gcc allows a lot of control of warnings and error
messages, but one may still wish for something special,
not coverd by existing options).

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

Well, I do not know what is your motivation for releasing your
code.  I have impression that you treat your code as a freeware,
that is release it for other to use, but do not care about their
ability to develop it.  IMO this combines worst aspect of
paid proprietary developement with worst aspect of open source
developement.  Namely, in open source case users can engage
in developement.  That could be in form of improvement or bug
fixes.  But also bug reports or developement suggestions.
In practice this leads to improved developement efficiency.
But without buildable source some of this is impossible
and what is possible is strongly discouraged (engagement
takes effort and why spent effort on something that may
become inaccessible if you slightly change your mind).
Paid proprietary developement uses more developement
resources, but is optimized to generate money to pay for
developement.  But freeware typically generates no money.

Concerning problem of needing binary to compile your
langiages, there are various approaches.  One possiblity
is to have binary and sources that rebuild this binary.
People can then check that binary indeed correspond to
provided sources.  Some project offer bootstraping via
C.  For example GNU Modula 2 has part written in Modula 2.
But it also has a Modula 2 to C converter, which is not
designed as general product, but used to compile first
version of compiler which is than used to compile final
version.  There is no warranty that people will want
to use your compiler if you release sources.  But
having developement sources and corresponding binary
(or generated C) is first step in overcoming doubts.
The point is that while theoretically inside binary
there could be self-replicating virus, it is quite
hard to hide it so that it survives undetected when
sources are modified.  With sources split into
reasonable small pieces it is frequently not so
hard to track correspondence between sources and
binary and check that there are no binary parts
without corresponding source.

Part of your trouble is that you want to develop on
Windows.  Apparently, it is hard to find people who
want to develop free software on Windows (at least
harder than finding people who want to develop free
software on Linux).  I am not saying that for small
free software project it is easy to find people who
want to develop on Linux, but is definitely harder
to find people wanting to develop on Windows.

--
                              Waldek Hebisch