Re: Future of export

2017-08-26 Thread Jerry via Digitalmars-d
Export was being implemented as an attribute last I saw of it, by 
the guy that made that DIP. Looks like he last worked on it some 
time in July.


https://github.com/Ingrater/dmd/commits/DllSupportD2


Re: Future of export

2017-08-23 Thread Nicholas Wilson via Digitalmars-d

On Thursday, 24 August 2017 at 00:31:26 UTC, solidstate1991 wrote:
There's already a DIP on the subject 
(https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md), but it's pretty much abandoned. I however would like to see it becoming a subject of discussion. DIP45 should be done as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language.


Thanks. The interesting bit of that DIP w.r.t DIP1012 is


A single meaning of export

The classical solution to handle dllexport/dllimport attributes 
on Windows is to define macro that depending on the current 
build setting expands to __declspec(dllexport) or to 
__declspec(dllimport). This complicates the build setup and 
means that object files for a static library can't be mixed 
well with object files for a DLL. Instead we propose that 
exported data definitions are accompanied with an _imp_ pointer 
and always accessed through them. See the implementation detail 
section for how this will work for data symbols and function 
symbols. That way a compiled object file can be used for a DLL 
or a static library. And vice versa an object file can be 
linked against an import library or a static library.


I can't comment on the build system complexity that DIP1012 would 
add but It would allow us to do the C/C++ solution of export 
management.


I'll have a proper look over DIP45's review thread and put a 
summary here and see if we can get some discussion on it.


Re: Future of export

2017-08-23 Thread solidstate1991 via Digitalmars-d
On Wednesday, 23 August 2017 at 03:19:55 UTC, Nicholas Wilson 
wrote:

I have as part of DIP 1012

```
enum SymbolExport
{
neither,
dynamicImport,
dynamicExport
}

alias dynamicImport = SymbolExport .dynamicImport;
alias dynamicExport = SymbolExport .dynamicExport;
```

to replace the `export` storage visibility, So that one can do

```
version(MyLib_Build)
enum MyLibExport = dynamicExport;
else
enum MyLibExport = dynamicImport;

// Exported when building the shared object,
//imported when linking against the shared object.
@MyLibExport void foo(int x) { ... }
```

However Martin said in 
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaR120 that "That's not what is planned for export"


Last I heard (from Benjamins Thaut's DConf 2016 talk) was that 
nobody was using export because there was no corresponding 
import and no way to switch between them. Benjamin suggested 
that making it an attribute would fix that, hence it is part of 
DIP 1012.


What is planned for export?


There's already a DIP on the subject 
(https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md), but it's pretty much abandoned. I however would like to see it becoming a subject of discussion. DIP45 should be done as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language.


Future of export

2017-08-22 Thread Nicholas Wilson via Digitalmars-d

I have as part of DIP 1012

```
enum SymbolExport
{
neither,
dynamicImport,
dynamicExport
}

alias dynamicImport = SymbolExport .dynamicImport;
alias dynamicExport = SymbolExport .dynamicExport;
```

to replace the `export` storage visibility, So that one can do

```
version(MyLib_Build)
enum MyLibExport = dynamicExport;
else
enum MyLibExport = dynamicImport;

// Exported when building the shared object,
//imported when linking against the shared object.
@MyLibExport void foo(int x) { ... }
```

However Martin said in 
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaR120 that "That's not what is planned for export"


Last I heard (from Benjamins Thaut's DConf 2016 talk) was that 
nobody was using export because there was no corresponding import 
and no way to switch between them. Benjamin suggested that making 
it an attribute would fix that, hence it is part of DIP 1012.


What is planned for export?