2- once again, why not use the linker support for initialization? If behavior has to depend on whether ECL was initialized yet, the initialization could consider in calling ecl_register_init_function, which depending on whether ECL was booted, would either call the function and/or add it to a hook. See once again attached files on how to use linker support for initialization.
Fact that we might bundle many objects in one archive doesn't mean that they don't have dependencies on one another. *I think* that we have to strictly control initialization order. It's possible that I'm wrong here though.
It *is* possible to strictly control initialization order while using linker functions: either ensure that you link objects in the correct order (duh), and/or have your ensure_foo_initialized functions explicitly call each other.
Also do we want to *always* initialize *everything* what is linked? We may have compiled-in support for number of lisp libraries in one module just for conveniance and require them on demand depending on the application using our code.
There again, the linker-called code could "just" register the initialization function to be called later, if that's what you want.
I'm guessing here since it's a design decision made by someone else. Your proposition is surely worth investigating - it is like it is because it was that way when I approached the codebase.
Some decisions that might have made sense 30 years ago when C++ was a new thing and linkers didn't specially support constructors don't make sense 30 years later when linkers do.
I'll attach my proof-of-concept code, that didn't make it to the list.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites