DIP45: fixing the dllimport/dllexport issue

[Rainer Schuetze]

On 27.08.2013 15:40, Benjamin Thaut wrote:
> Am 27.08.2013 15:33, schrieb Andrej Mitrovic:
>> On 8/27/13, Benjamin Thaut <code at benjamin-thaut.de> wrote:
>>> Well, a link would have been great:
>>>
>>> http://wiki.dlang.org/DIP45
>>
>> Using export(identifier) is not going to be reliable, since chances of
>> clashes are high.
>> E.g. if libFoo uses export(Foo) and libBar also uses export(Foo), you
>> won't be able to distinguish between the two.
>>
>> Instead I think 'identifier' should be a module name.
>>
>> However, I have a better idea. Why not only introduce compiler
>> switches that are based on module names rather than having to annotate
>> what export does in code? For example:
>>
>> dmd -m64 -export libB.* -import libA.* -of"libB.dll" dllmain.d libB.d
>> -L/DLL -L/IMPLIB:"libB.lib" -LlibA.lib
>>
>> "-export libB.*" means all modules and subpackages of the libB package
>> should be exported, whereas "-import libA.*" means the opposite for
>> libA.
>>
>> This way you don't have to edit any existing code.
>>
>
> I thought about something along those lines aswell. But wouldn't that
> create a very long command line if you do it for druntime?

I think export (at module granularity) can be handled by building the 
modules with symbols to export using a command line switch "-exportall", 
and all other modules without.

I'd prefer if the compilation against the imported library would be 
agnostic whether it is later linked against a static or dynamic library.

How is this done on linux right now? It does not need "export"/"import" 
to build against a shared phobos library. Is "import" assumed for any 
data access and later removed by some magic in the linker?