On 27.08.2013 15:40, Benjamin Thaut wrote:
Am 27.08.2013 15:33, schrieb Andrej Mitrovic:
On 8/27/13, Benjamin Thaut <[email protected]> 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?
