[M3devel] bootstrapping wrinkle, incrementality bug when toggling build_standalone

[Jay K]

I found a new bootstrapping wrinkle tonight.
Based on that we typically have pairs of libraries:
NT: foo.lib, foo.lib.sa
Posix: libfoo.a, libfoo.a.sa?
 
 
If there is incompatibility introduced in m3core,
such as I introduced just now for set_member/set_singleton,
it *seems* you can get into a situation where only
one of the two libraries is updated.
 
 
Perhaps because I was hacking shared = false, perhaps
to workaround other problems.
 
 
Anyway, the general technique might be useful.
 ==> move foo.lib.sa to foo.lib
 
 
More generally there IS an obvious problem in the system.
IF I have a library that was previously not standalone,
therefore having both foo.lib and foo.lib.sa,
 
 
and then I change it to always be standalone,
therefore only having foo.lib,
 
 
and then I link a standalone application to it,
the out of date foo.lib.sa will be found and used.
 
 
Solutions include:
 - when shipping, delete related neighboring files.
   i.e. when shipping a non-standalone library, delete the shipped foo.lib.sa.
 - or, always make foo.lib and foo.lib.sa, just that
   they might be identical.
 - or, lame...probe contents not name? if foo.lib appears to be
   standalone, don't probe for foo.lib.sa? Not difficult on NT...
 
 
(This goes to show something I can never very well explain why:
file existance checks, probes, generally indicate problems.)
 
 
 - Jay