Re: Python recompile

bart <bc@freeuk.com> wrote:

On 07/03/2025 01:07, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:
 

If so, why doesn't the same apply to the main language of the
application? (Why isn't the application written in that language!)

 
You like benchmarks, so try some benchmarks of speed of shell
programs.  Or believe me that for computational problems shell
programs are dog slow (of order of 100 times slower than normal
interpreted languages like Python).

 
That wasn't a serious suggestion. But why not have a language that can
run anywhere? A compiler is a program that reads in some files and
writes one or more output files - you can't get anything more portable!

But some people took this seriously and implemented actual
applications in shell language.

I've also seen a project where the configuration program was a C file,
one which didn't need any special options, whose output was used to
build the main app.

 
Yes, that is a possiblity.  Some time ago I was thinking about
similar thing.  Basically, configure scripts are slow, ugly and
long due to limitations of shell and need to work with "any"
shell.  Could we write resonably small "better shell" to
execute simpler version of configure script?

 
You'd still have to sell me on the need for a configuration script at all.
 
I accept that sometimes scripting is needed to orchestrate certain
builds or to perform installation, but such programs would be 2-3
magnitudes smaller than that 35Kloc monstrosity.

This 35 Kloc is mechanicaly generated.  What matter for developers
is how much code they need to write by hand and how much effort
it takes.  Volume of hand written configuration code is much
smaller and it is likely that decreasing size of generated code
would require more hand written code.

Again, why can't the main app be made to work like the small one?

 
Modern applications depend on libraries.  Let me mention a dll
for Windows that I created many years ago.  My own code was
about 2000 (wc) lines of code, part of it numeric code that
provided main functionality (image transformation), rest was
glue code to the libraries.  Input data came from .tiff files
and I used libtiff to read them.  I needed some geometry code
which I found on the net.  I needed linear equation solver,
that I got from Lapack.  So there were 4 libraries (3 that
I used directly and libjpeg used by libtiff), and most
code in "my" dll actually came from the other libraries.
 
In this dll was doing rather special thing used as a part
of bigger process.  In modern times application like gimp
connects several things of similar complexity.  There is
a lot of image formats, so many libraries just to read and
write graphic files.  I did not look at gimp build process,
but at configure stage is must verify if all needed libraries
(probably tens if not more) are present. Libraries need to be
in sufficiently new versions and export needed functionality
(libraries frequently may be compiled skipping part of
functionality).  I am pretty sure that parts of gimp are
optional, that is you may include or skip them.  And some
other projects may wish to use parts of gimp, so build
probaly created quite a few of libraries (that is separate
things that need to be linked).

 
Some DLLS will be part of the OS. Some are easy to obtain by the user.
Some could be bundled.
 
However my apps (those mentioned below) would not fail if one was
missing; only if specific functions from a DLL were needed. (I think I
only needed one, to do with JPEG handling).
 
If I was still making apps, I would not have a dependency of an elusive
library. One such is GMPxxx.DLL; that was so difficult to source, or
even to build from source code (yes it has its own 30Kloc configure
file!) that I found it easier to create my own library.

When I need multiple precision artithmetic usually I also need
speed.  That requires special cases.  I do not need most GMP
"high level" functions, so I could simplify it a bit.  But most
complexity is in low level parts, in particular having fast code
on multiple targets (which I need).  So, _sometimes_ I can
use simpler and slower code, but to cover all my needs
it would take something of complexity comparable to GMP.
So using GMP is easier.

In modern times applications are supposed to be internationalized.
That is various messages should appear in selected language.
Normal practise in modern times is to have separate build
step to expract english messages from source files and
create connetion to translations.  That alone means that
build is more complex than simply compiling C files.

 
Actually my 1990s apps were internationalised (working in English,
French, German, Dutch). A dictionary of translations was provided by
distributors. There was some scripting to help with that, but the script
language was built-in to the app.
 
It was all taken care of. No need for makefiles or any stuff like that.
Supporting a different language didn't need a new build; just a data file.

You can do internationalization essentially by hand, that is
with extra developement effort.  If you control compiler you could
add apropriate compiler extention to automate large part of
this work.  Or you can use some scripting language (like your
own).  Point is that most projects do _not_ have own compiler
or own scripting language, so they prefer tools developed by
other folks.  Popular such tools are designed to work as
part of 'make' based build.

And yes, result of build is binary + base data file.  Translators
add translations to data file without need to recompile
main binary.

--
                              Waldek Hebisch