Re: Python recompile

bart <bc@freeuk.com> wrote:

On 14/03/2025 19:37, Richard Harnden wrote:

On 14/03/2025 19:04, bart wrote:

After all no one (according to you) was complaining about grappling
with 100 discrete files.

 
100 discrete files helps 100 developers not to step on each other's toes.
 
And most of those 100 .o's won't need to be recompiled on every make.
It's quicker and easier.
 

 
That may be true about the people who /develop/ this sqlite3 product.
 
But this is a file created to ease deployment by people who want to
/use/ it.
 
I don't know why nobody in this group can grasp that concept even though
I've explained it a hundred times. For example, I have a transpiler
product that turns a 50-module project in my language into a single,
easy-to-build C source file.
 
But everyone makes the same point about it being hard to manage. No one
is even going to look inside it!

Do you realize that your amalgamation destroys most of C
modularization?  In C there is no conflict between static
objects at file scope in different files, even is they use
the same name.  In single file there may be conflict.
Avoiding such conflicts is an extra developement effort.

In case of libraries you loose one feature which may be
important, namely ability of linker to link in only used
files (that is the main reason that libraries used a
lot of very small files).  Modern compiler + linker combo
may offer better feature, but this better freature
has its own limitations so people still depend on
classic liker behaviour.

You like idea of amalgamation, but for most uses it helps
nothing and may create troubles.

Concerning looking inside: I frequently look inside code
that I use.  One reason may be because description is not
clear enough.  Or I would like to see how something is
done.

--
                              Waldek Hebisch