On 14/02/2024 10:11, David Brown wrote:
On 14/02/2024 10:34, Malcolm McLean wrote:
Now I know that you think Bart should just use make. But let's say
it's agreed to proceed with the system I proposed, which is a C
interpeter to drive a build script. Now I suggested modifying one of
Bart's own compilers. But that's more difficult than I thought. So my
second option is Pico C. Now I think that is achievable. If there's
sufficient consensus that the system is worth producing, we can hook
up Pico C and thrash out a support library, with the resources we have
in this newsgroup, from people who are likely to want to contribute.
Now if you think we shouldn't do that because of the danger of the
scripting system being used in a critical environment and an error in
the boolean or other component of Pico C propagating, then how do you
think that we should proceed?
You do what you want here. I think your dream of getting regulars in
this newsgroup to work together to make a C based scripting system for building Bart's programs is, shall we say, somewhat unrealistic. Those
that have made any comments on the subject, other than Bart, have been
happy with the way they build their software, and I don't think anyone
other than you thinks C would be a good choice of scripting language.
(Bart has his own scripting language which seems a far better choice for
his own needs for any build system.)
All such choices have a flaw: you need to bundle a binary program to act
as scripting language, whether it is an interpreter for C or anything else.
This is what we're trying to avoid, otherwise we'd just build the app
ourselves and supply the binary.
If that scripting language is provided as source code, then the problem
we're trying to solve with building the app, then applies also to the
scripting language.
There is only one thing that can be assumed, or that can be stipulated,
which is that a C compiler is present.
This can only be made workable if the scripting part is a small enough C program. So it can't be my language (which is 40Kloc in one file), or
even Pico C (about 10Kloc in 26 files).
It needs to be a few hundred lines max. So it must directly do the job
if the dependencies need to be reduced to one C compiler.
However, who is going to use it?
For my purposes, 98% of the problems encountered are in building other
people's software, and there there is no sign of anyone moving away from complex configure scripts and makefiles. On the contrary, they are
finding even more elaborate solutions with bigger dependencies.
I could use such a scheme (a helper C file of a few hundred lines) to
build /some/ of those, once I've already solved the problem of (1)
getting those pesky *config.h files; (2) discovering all the necessary
modules and turning that into a simple list; (3) discovering any
additional needs (eg. creating multiple binaries).
But I'd still have to build it, on my machine, using something like:
gcc xxx.c -o xxx && xxx
Yuck. I might as well stick to simpler schemes like @files, or using my
#pragma idea for mcc, plus using BAT file for any extras.
So the big problem with such a scheme (providing an auxiliary C program,
as source code, to orchestrate the building of the main application) is
getting anyone to actually use it for their open source projects.
When /I/ supply C source code, it is already one single file anyway that
you can already build as 'gcc xxx.c -o xxx'.
I don't think it is good that Pico C is spread around, as long as it has
its current flaws in C conformity, unless these flaws and limitations
are clearly documented. If you want to call it an interpreter for a
C-like language, great. If you want to call it an interpreter for C
with certain limitations and differences from standard C, great. I
object to calling it a C interpreter, and promoting its use as such.
Howr about you let people use 'C' how they want (since they will do
anyway), and use 'Real C99' or 'Standard C11' etc, when being more rigorous.
I would prefer most of all to see its flaws and non-conformities fixed.
It should not be particularly hard to do.
No. Maybe you could do it next weekend.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)