SN Build OS link should be using static libraries.

[LeeTibbert]

Whilst reading recently merged PR #3548 I was reminded of a long opportunity to
improve the build and avoid a future failure.

Currently the SN build creates a large number (several hundred) of object (Linux .o) file and then
calls a OS-level linker with a single command line specifying flags and the fully qualified
names of those many .o files.

Most shell command line interpreters have a large but finite maximum line length. Someday
the current practice is going to break. Whenever I add a new file, I just hope that the person
doing the breaking is not me.

A more immediate concern is that usually taking a small time hit to create an static archive file (Linux .a),
filled with .o files as they are created, and linking the main .o with that archive is faster, more robust,
and uses less resources. Yes some linker magic can be necessary but the need for such magic is
usually an indication of poor design and/or deeper problems.

The benefit of the archive approach depends upon how many times the symbols in a given .o
need to be looked up. Usually, the overhead of creating & filling the archive is more than re-paid
by faster symbol lookups.

Much of the work to create such a set of archive files (one per sub-project?) may now already be in the build.

[keynmol]

I think this would be great for user code as well - if incremental compilation produces 1 file per package, then we can produce a single archive per module (and watch those single object files for changes, doing in-place replacement using ar) - meaning our linking commands will be much shorter and fewer roundtrips to filesystem.

[keynmol]

Oh, perhaps that's exactly what you mean by SN build? I think I'm confused.

[LeeTibbert]

This weekend, I was thinking about unit-tests, because that is where I have been spending my days & nights:
blinders.

As you, keymol, mention, this approach would primarily (my words, upon reflection) benefit linker user
executable files.

I think the required edits are larger than a breadbox/weekend not huge. May I have pepper, please,
when I eat those words?

This a thought for the future, not any soon pending work.