[monolith builds]

[Faré]

>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constructor0.c
Type: text/x-csrc
Size: 1739 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20151004/6ab3b9f5/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constructor1.c
Type: text/x-csrc
Size: 1109 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20151004/6ab3b9f5/attachment-0001.c>