Re: Python recompile

On 11/03/2025 01:33, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

On 10/03/2025 10:58, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

>
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
>
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..

>
"Minimalist" is not about size of the compiler.  Rather, it is
about possible support routines.  For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems.  Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries.  MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.

>
I still don't get this stuff.
>
I get the impression that a port of gcc to Windows is not simply about
building C programs, but building C programs that use a lot of features
from Linux.

 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.
This task can be done with a program called a 'compiler'.
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.
This is done even on smaller, simple applications, and also on those that are supposedly cross-platform that are to be built on the target.
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.
It should not rely on anything that is not native to the target platform.

 And people do not want
to reinvent the wheel, they prefer to use code written
by others.

What wheels are these that are being reinvented? I'm simply arguing for using either 2 or 4 wheels, not 18!
And I'm not suggesting reinventing those 2/4 either, just using the ones I have on my OS.

 Folks at Bell Labs had several good ideas
and shared them with others.  Those ideas are not limited
to Linux or Unix, you can look at old "Software tools in ..."
books to understand what I am talking about.  MinGW
_distribution_ bundles several tools.  This allows you
to compile programs when build process uses those tools.
You can also use the tools for your purpose.  Aparently
you have very strong "not invented here" syndrom and
insist on usig your own tools.

That's another aspect of it which is not that relevant, other than it shows just how simple things could be.
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.
(Those developers also seem to think that the only alternative to MSYS2, configure scripts etc is to use the monstrosity that is MS Visual Studio and all it comprises.)
If an application is written in C, then a C compiler should suffice.

 That is fine, as long
as you keep this to yourselfs.  But refusing other
folks right to use tools they want to use is not
fair.

Developers can do what they like. But they shouldn't inflict their choices on other people, especially those using other OSes.

 Or, to put it differently, when you refuse
the tools _you_ need to do by hand needed work.
You may be able to extract from work of others
something that fits your taste (like list of files
to compile), but that is your business.

Fine. In that case tell me what the files are! Lua actually does this (but it's not obvious, it's also unexpected since the majority of apps are unhelpful in such matters).
When I tried to build A68G, the whole build process, under VirtualBox Linux, took 5 minutes. I couldn't build under Windows because of a 30,000-line bash script.
However, with some effort, I was able to isolate the C files needed, and fortunately there was no synthesised code. Given that list of 12 files (!) building the app on Windows took my compiler one second.

If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of the
sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I can't
speak for MSVC.)

 You may be able to do some things using just a C compiler.
But requesting people to do other things by hand is as
wise as requesting them to code in assembler

What things, what assembly? I'm talking about building a program written in a HLL using an existing compiler.
That seems reasonable enough, yes?
The only info needed is the list of files to submit to said compiler.
  (assembler

may be converted to binary faster than C, and with enough
effort resulting binary will run faster than result of
C compilation :).  Another thing are libraries and
bigger applications.  Some folks want "true Windows look
and feel", some say that proper Windows DLL must be
compiled by MSVC

Any C compiler for Windows can generate DLL files.

(otherwise is lack some features that
they consider essential).  But there are people who
had to or wanted to use Windows, but also wanted to
use Unix applications.  Cygwin was addressed to such
folks: it allows you to compile substantial Unix
application so that it runs on Windows.  If you have
no interest in such applications, than fine, Cygwin
is probably not for you.  Today WSL may be better
for such a goal, but in the past Cygwin provided
easiest way to port Unix application to Windows.
If easy port was the goal and application was
substantial, then Cygwin usually was right choice.

As I understand it, POSIX is about 80 header files, of which ~30 are the standard C headers, leaving 50 POSIX headers that do not exist on Windows.
If your Linux app uses those headers, and you want to port it to Windows, then you have problems to solve.
But I would question whether the apps I want to build need all that. How does POSIX figure in the GMP library for example?
Why does so much code use open() for example instead of the standard fopen()?
So, not only are people relying the Linux eco-system for the build process, but they are also needlessly using POSIX-specific headers.
C is supposed to be that famous portable HLL, but in developer's minds, 'portable' seems to mean working only on any Unix-like system!
(My language, not C, has a std library that includes some OS functionality. But those are wrapped in a set of functions that reside in one OS-specific module, that provides the same API across Windows and Linux.
For example, the function 'os_getdllinst' is implemented on top of 'LoadLibrary' on Windows, and 'dlopen' on Linux.
What I don't do is directly use LoadLibrary, and insist that people running it on Linux have to install some emulation library to provide that Windows functionality. Which wouldn't work anyway as it would also work with .dll files rather than .so files.
You see the kind of thought I put into this stuff? I wish others would do the same! Instead of being so 'provincial'.)

To put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
>

>
I'm not interested in whatever Cygwin or Mingw are about.

 Oh, so you do not want to know.  In such case why you started
discussing it?

Because it comes up everwhere that gcc is used on Windows?
I started by saying I didn't know exactly what Mingw was. I used to think it was the compiler, and indeed obtaining gcc used to involve visiting sites where 'mingw' or 'mingw64' names figured heavily.
Some of my gcc files also have 'mingw32' in them; I don't know why:
   c:\tdm\bin>fc gcc.exe x86_64-w64-mingw32-gcc.exe
   Comparing files gcc.exe and X86_64-W64-MINGW32-GCC.EXE
   FC: no differences encountered
Apparently it is to do with some boring functions discussed in parallel subthreads.

If I were to
use libraries not part of the OS, then it would be ones like SDL2 to get
interesting things done. Not try and emulate bits of Linux that I'd
never heard of.

 I mentioned one case: about 90% of code in "my" library was
provided in fact by other libraries.  So using code provided
by other saved me a lot of work, turning something that
otherwise could be multiyear job into reasonably small effort.

Sure. Then just provide the binaries which somebody (or even some script) can build once, on a machine where everything is known to work.
This suits Windows which has famous binary compatibility. (If there is a 32-bit version of Windows 11, it can probably still run my 1990s 16-bit binaries!)

To use the libraries I had to work out build process, thanks
to tools it was very easy.

Thanks to tools designed to work within a labyrinthine build environment, working within such an environment.
Purely as an exercise, could you have produced a minimal viable bundle of source files, compiler (or recommendation for one), readme and what ever else was necessary, that would work in an alien environment? Say, Windows.

MinGW bundle is a good way to build such libraries.  Having
only a C compiler may be too little.

All I can say is that if /I/ produce software expressed in C, then you need a C compiler to run it.