Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Fri, 14 Mar 2025 11:32:17 +0200
Organization: A noiseless patient Spider
Lines: 405
Message-ID: <20250314113217.0000634b@yahoo.com>
References: <vq1qas$j22$1@gallifrey.nk.ca>
	<vq7g1p$1vmg5$1@dont-email.me>
	<vq94dt$2boso$1@dont-email.me>
	<vqcsk7$23bfo$1@paganini.bofh.team>
	<vqefn1$3flpt$1@dont-email.me>
	<vqeu5c$3imil$1@dont-email.me>
	<vqeun4$3iqbq$1@dont-email.me>
	<vqfcbe$3lkkc$1@dont-email.me>
	<871pv861ht.fsf@nosuchdomain.example.com>
	<20250308192940.00001351@yahoo.com>
	<vqi1ge$8jg8$1@dont-email.me>
	<vqmgjv$3a2il$1@paganini.bofh.team>
	<vqn4dn$1eb9s$1@dont-email.me>
	<vqo3ss$3hkas$1@paganini.bofh.team>
	<vqph2e$203bs$2@dont-email.me>
	<vqvtop$cpvn$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 14 Mar 2025 10:32:20 +0100 (CET)
Injection-Info: dont-email.me; posting-host="943fe49e92ae1a26c80cdfc20df6ad74";
	logging-data="1089891"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ItHeP7WknvSc1ijnCZoXoRcp66x0wWf4="
Cancel-Lock: sha1:B1snjB4IH5M4mBW9NHHAMWvqUSo=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 21162

On Fri, 14 Mar 2025 00:37:48 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:

> bart <bc@freeuk.com> wrote:
> > On 11/03/2025 01:33, Waldek Hebisch wrote: =20
> >> bart <bc@freeuk.com> wrote: =20
> >>> On 10/03/2025 10:58, Waldek Hebisch wrote: =20
> >>>> bart <bc@freeuk.com> wrote: =20
> >>>>>
> >>>>> 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.. =20
> >>>>
> >>>> "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. =20
> >>>
> >>> 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. =20
> >>=20
> >> You apparently do not get fact that people want tools to
> >> automate various routine tasks. =20
> >=20
> > 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.
> >=20
> > This task can be done with a program called a 'compiler'. =20
>=20
> You ignore fact that people are developing programs.  And developement
> is much more than "turning a bunch of source files into an
> executable". GPL says "The source code for a work means the preferred
> form of the work for making modifications to it".  And that nicely
> captures the idea: sources are in form that is convenient for
> developer and may require several steps before one gets the
> executable.
>=20
> > However, what I'm arguing about is that this simple task has become=20
> > unnecessarily elaborate on OSes like Linux, by introducing
> > makefiles, OS-specific scripts, and OS-specific utilities. =20
>=20
> There is not much OS-specific in "Linux tools".  'make' is
> problematic on zOS, because files have no timestamps there,
> but most normal OS-es have timestamps (and IIUC even zOS
> has USS where timestamps are available).  You need ability
> to invoke a program from a different program, exact form
> of this is OS-dependent, but ability is there in any
> semi-reasonable general purpose OS.  You need ability
> to get exit status of a program, again exact form is
> OS-dependent but ability is there.
>=20
> FYI, is started using "Linux tools" on MS-DOS, before I
> heard about Linux.  And tools are widely available,
> IIUC classic zOS is problematic, but I think that USS
> is OK.  Some systems may be prone to breakage, when
> there is small number of _active_ users and nobody bothers
> to timely report real problems.
>=20
> Coming back to developement, in many cases it is desirable
> to generate some C files.  C preprocessor can do some
> transformations, but is may be convenient to transform
> source in a way hard to do via proprocessor.  Also,
> this is C group, but big programs frequently have parts
> in different languages, an then it is good to have
> language-neutral tools.  Simple tools to transform
> or generate files are 'sed' and 'awk'.  Some people
> use 'perl' or 'python' for such purpose and in principle
> there is much more possiblities.
>=20
> More specialised are compiler-writing tools like 'bison'
> and 'flex'.  You can write a parser by hand, but using
> 'bison' one does not need to know much to write working
> parser.  'flex' helps in writing scanners, but IMO
> is quite useful for text processing task (its support
> for regular expressions is nicer than Perl or Python
> offer, and speed frequently is much better too).
>=20
> Users beside binary need also documentation.  In principle
> documentation could be provided as plain text, but there
> is now tendency to offer nicely formatted documentation
> and to offer multiple formats.  Which means that there is
> need for formatting tools.  Old ones are Texinfo and TeX.
> And some moment there was push towards SGML and formats
> like DocBook.  This needs appropriate tools.  Some people
> now prefer tools like 'sphinx' (which needs Python with
> several extention packages).  There is 'doxygen' which
> extract information from source files and presents nicely
> formated info about API (I am not a fan of 'doxygen' but
> is seems to be widely used).
>=20
> Beside building program and documentation one wants some
> automatic way of running tests.  And people want to
> automate more tasks, for example removal of generated
> files or installation.
>=20
> Automation requires some scripting language.  For authors
> of free programs important point is free availability
> (preferably with sources) of choosen language.  That
> ruled out things like MS Basic or 'command.com' (and
> 'command.com' is quite limited).  Unix shell was
> available as port of OS on Unix systems and quite early
> there were free ports of Unix shell to other systems.
> So there were natural preference to Unix shell, simply
> because of wide availability.  Similarly with other
> classic Unix tools.  One can argue that those classic
> tools are now dated, but there is stong inertia in
> action: tools are widely used, widely availeble, there
> is knowldege how to use them so people keep using them.
>=20
> When one thinks about possible replacements, it is not an
> easy job.  Namely, Unix tools evolved and are designed
> to work together.  Different tool either must cooperate
> nicely with existing tools, which forces similar
> behaviour to current tools, or must provide replacement
> for the whole toolkit which is much more complicated
> than replacing a single tool.
>=20
> When you look at bloat, I expect competing tools to be
> much more bloated than classic Unix tools.  Namely,
> Unix tools were designed to be simple and power comes
> from possibility to compose them.  It is hard to
> imagine way of composing tools that is both simple
> and offers more possibilities than Unix way.  So
> one can have simpler/smaller tools but less powerful.
> Or one can increase fuctionality of each tools separately
> (to some degree this is happening with Unix tools), but
> this increases complexity of each tool.  One can try
> to make one tool that replaces the whole toolkit, but
> experiance suggest that such a single tool would be
> much more complicated.  To summarize, more powerful
> tools are likely to be more complicated, hence more
> bloated than classic Unix tools.  Given that classic
> Unix tools are quite small compared to modern systems
> (they can be implemented in few megabytes of code)
> incentive to make smaller tools is rather low.
>=20
> > 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. =20
>=20
> You can have basic toolkit running on rather wide set of systems.
> So this is not a big burden for recipients, in particuar since
> the same toolkit may be used to build many programs.
> =20
> > 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. =20
>=20
> Current free software ecosystem is colaborative work of many people.
> In particular, there are people creating binary packages and if
> all you want is running binary you may be better off getting a
> package from them.  Now, people creating binaries want to do
> this in an automated way.  For them having to give a list of files
> to compiler each time when they build a package is too mach work.
========== REMAINDER OF ARTICLE TRUNCATED ==========