librarians that do Make

12.14: co.self/dream/adda/librarians that do Make:
. in a compiler system, the info managed by the Make file,
can instead by generated by the library;
the info to be gathered by the linker
includes the hashes of everything that is linked
(so it knows when anything has been modified)
and a database of which wares are required each other;
it is builing a requires-list for
each piece that got linked to anything ...
[. upon waking,
I started looking around for how usable that was;
actually, a hash of each module is not the only thing you want;
because, if an impl' has changed but its interface has not,
then the libary should not need to recompile it .
because it's still promising to serve the same interface as before .
1118:
. however, you would want to do re-apply
any unit testing scripts,
and then passing that would also trigger
any related integration testing scripts .]

12.14: adda/librarians that do Make:

. as the compiler is generating binaries from text,
the Make file is the place for describing dependencies;
so then, if a dependency can be checked for freshness:
if the source text in newer than the binary,
then it needs to be recompiled .
. if the inteface is newer than the binary,
then all clients need to be recompiled .
. we routinely reuse binaries from others;
(most people are users, not developers)
and, so, for a compiler to be doing
Make file duties,
it needs to be exchanging Make info
with other compilers .

. to know if an import is serving a particular interface
it actually needs a text or symbolic version of that interface

which needs to resove to the same typenames,
or optionally to any similar datatype,
depending on whether the given type describes itself as
new
where it simply uses other types for implementing its model,
it doesn't expect to be seen as a synonym for the type it used .

. the ada lang allows both new types and reuse of types;
ie, a new type means you have an impl reusing an old type
but you don't want to be seen as being compatable with the old type,
you want to be compat only to your name
or at least only to the interface your name represents .
. eg,
a character string may be impl'd as a c string, or a safe string,
but both are serving the same model, type"string;
whereas, gasoline tank may be an integer modeling volume,
but it doesn't want to be confused with other integers,
nor operated on by just anything that can modify integers .

. we have ideas for features addx should have,
make sure to separate that from how features should be impl'd .

. if there's a new version with a fix from an exporter,
your librarian needs  to accept it
but if it's accepting c or python code,
then user needs to be informed that the system is less secure
if they go ahead with reuse by non-adda coders .
(the reason you're safe with adda code,
is that it's compiled by adda, a trusted app
-- unless your machine's os has been
compromised by malware --
adda code has been translated into python or c,
which can be trusted as much python's core library,
and your own os (that depends on
your own security policy:
do you run your browser in a vm?
keep your os updated?
know where your usb drives have been? ...)

sync's:
. the model that the librarian needs to have in order to
accept imports,
is to accept sync's with other librarians
and then synchs download interfaces of sharables
so your librarian can list them when you've asked what's available .
. if you do use an external,
it downloads the associated body,
the list shows too where your names conflict .
. it doesn't require you to rename conflicts because
all listings are qualified by the exporting librarian's name,
except for the entries of the local librarian .
. the user's rename can make an export appear to be local,
while yet being maintained by an exporter .
. local librarian is thus a language translator,
having a separate set of names for {user, other librarians}.

12.14: todo.adda/unify sync'd librarians with version control systems:
. the need to unify sync'd librarians
has to do with version control systems .