Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: bart Newsgroups: comp.lang.c Subject: Re: Python recompile Date: Tue, 11 Mar 2025 14:24:15 +0000 Organization: A noiseless patient Spider Lines: 251 Message-ID: References: <20250304092827.708@kylheku.com> <871pv861ht.fsf@nosuchdomain.example.com> <20250308192940.00001351@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 11 Mar 2025 15:24:15 +0100 (CET) Injection-Info: dont-email.me; posting-host="e0b1512e31c88b1cbe05a7f62cb3028b"; logging-data="2100604"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ooP8iOLFijTqRsmwEujtV" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:kpHkGQyC2Ao6kboNcNyTvBnPLOI= Content-Language: en-GB In-Reply-To: Bytes: 11924 On 11/03/2025 01:33, Waldek Hebisch wrote: > bart wrote: >> On 10/03/2025 10:58, Waldek Hebisch wrote: >>> bart 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 ========== REMAINDER OF ARTICLE TRUNCATED ==========