The current behaviour of export is not sufficient to create a shared runtime on windows. Its alos not working very well in a few other cases. For background information please read the links provided in the DIP. This DIP tries to solve the problem by imitating the proven preprocessor techniques used in C/C++ to create windows dlls.

Destroy.

Kind Regards
Benjamin Thaut

Well, a link would have been great:

http://wiki.dlang.org/DIP45

On Tuesday, 27 August 2013 at 10:16:24 UTC, Benjamin Thaut wrote:
> Well, a link would have been great:
>
> http://wiki.dlang.org/DIP45

I don't think that is the way to go.

We need a way to mark a module as being an "header" import for a shared lib.

With that solution, you'll ends up duplicating all modules with import and export, and putting the export(foobar) all over the place in a module.

Am 27.08.2013 13:28, schrieb deadalnix:
> On Tuesday, 27 August 2013 at 10:16:24 UTC, Benjamin Thaut wrote:
>> Well, a link would have been great:
>>
>> http://wiki.dlang.org/DIP45
>
> I don't think that is the way to go.
>
> We need a way to mark a module as being an "header" import for a shared
> lib.
>
> With that solution, you'll ends up duplicating all modules with import
> and export, and putting the export(foobar) all over the place in a module.

Well ideally it should be enough to put one

export(foobar): at the top of the file.

Also I don't see why there is any duplication of modules involved? What exactly do you mean?

And how should your header import for a shared lib work, if you link against exactly that lib statically?

Kind Regards
Benjamin Thaut

On 8/27/13, Benjamin Thaut <code@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.

Am 27.08.2013 15:33, schrieb Andrej Mitrovic:
> On 8/27/13, Benjamin Thaut <code@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?

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@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?

On 2013-08-29 08:43, Rainer Schuetze wrote:

> 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?

"export" is noop on Posix. Every symbol is accessible.

-- 
/Jacob Carlborg

On Thursday, 29 August 2013 at 06:54:46 UTC, Jacob Carlborg wrote:
> On 2013-08-29 08:43, Rainer Schuetze wrote:
>
>> 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?
>
> "export" is noop on Posix. Every symbol is accessible.

C++ is doing its best to move away from it. We should probably don't follow that convention.

Am 29.08.2013 09:24, schrieb deadalnix:
> On Thursday, 29 August 2013 at 06:54:46 UTC, Jacob Carlborg wrote:
>> On 2013-08-29 08:43, Rainer Schuetze wrote:
>>
>>> 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?
>>
>> "export" is noop on Posix. Every symbol is accessible.
>
> C++ is doing its best to move away from it. We should probably don't
> follow that convention.

Moving away from what exactly?

-- 
Kind Regards
Benjamin Thaut