[Issue 9816] Export is mostly broken

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #19 from Martin Nowak <code at dawg.eu> 2013-08-29 15:05:57 PDT ---
(In reply to comment #18)
> - when does export mean dllimport and when dllexport. Newsgroup discussion
> brought up that we could enable dllimport/dllexport per module (including all
> submodules) via a command line switch.

There are some problems with the current implementation.

export void foo() {} // definition  => dllexport
export void foo();   // declaration => dllimport
export int a = 0;    // definition  => dllexport
export int a;        // declaration => dllimport // fails because it's actually
a definition
export extern int a; // declaration => dllimport

It would be great if we could avoid extra .di headers.

> - do we want a export all public symbols feature (discussion on the newsgroup
> brought up that c++ is trying to move away from this, maybe we should too)

Please let's try to go into the other direction on Unix too.
You can find more about the reasoning here.
http://gcc.gnu.org/wiki/Visibility
http://people.redhat.com/drepper/dsohowto.pdf

> - Should exporting of entire classes / structs be possible? E.g. marking a
> class es export, exports its vtable, typeinfo, all protected / public
> functions,
> static members, etc.

Yes, because there is no way to annotate compiler generated data.

Once again please stay away from abusing protection for export because it
creates too many problems for future language extensions, e.g. maintaining
private symbols for ABI compatibility, module definitions in multiple
files/objects, partial classes. Linking and symbol protection are fundamentally
different concepts and we should offer orthogonal control.

> - Which informations about modules need to be exported? Will they be
> automatically exported as soon as the module has a single exported function /
> class / variable?

Yes, it's hidden compiler data and you might need to link against the
ModuleInfo and some other symbols.

> 
> > Well, the question is, whether we can annotate symbols with "export" and still
> > create static libraries.
> 
> At the moment: no. But we should create a solution where this very case will
> work. Proposed solution. 'export' is always a no-op unless you specifiy
> otherwise using a command line switch to the compiler.

That sounds like a reasonable solution when we can't do better.
Also see the alias discussion on the newsgroup
http://forum.dlang.org/post/kvo9gm$8fs$1@digitalmars.com.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------