I'm trying to the get the "package modules" working in the new package std.serialization I'm working on. I have a sample file I'm compiling, looking like this:

import std.serialization;
import std.serialization.archives;

class Foo
{
    int a;
}

void main ()
{
    auto archive = new XmlArchive!();
    auto serializer = new Serializer(archive);

    auto foo = new Foo;
    foo.a = 3;

    serializer.serialize(foo);
    auto foo2 = serializer.deserialize!(Foo)(archive.untypedData);

    assert(foo2.a == 3);
    assert(foo.a == foo2.a);
}

When I compile it I get these linker errors:

Undefined symbols for architecture x86_64:
  "_D3std13serialization12__ModuleInfoZ", referenced from:
      _D4main12__ModuleInfoZ in main.o
  "_D3std13serialization8archives12__ModuleInfoZ", referenced from:
      _D4main12__ModuleInfoZ in main.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
--- errorlevel 1

If I instead only import the exact modules that are needed, like this:

import std.serialization.serializer;
import std.serialization.archives.xmlarchive;

Everything works as expected.

I have a module declaration in std/serialization/package.d, like this:

module std.serialization;

And in std/serialization/archives/package.d

module std.archives;

First, I don't know if I should have any module declarations at all in these "package modules". Or if they should be like above or something like "module std.archives.package;".

If I remove the module declarations in the package modules I get this assertion in the compiler:

Assertion failed: (p->isPkgMod == PKGmodule), function load, file import.c, line 136.
Abort trap:

I don't know if I'm doing something wrong of if this new feature isn't working properly.

The code is available there: https://github.com/jacob-carlborg/phobos/tree/serialization

-- 
/Jacob Carlborg

On 8/14/13, Jacob Carlborg <doob@me.com> wrote:
> And in std/serialization/archives/package.d
>
> module std.archives;

I think that should be 'module std.serialization.archives'.

On Wednesday, 14 August 2013 at 14:43:47 UTC, Jacob Carlborg wrote:
> I'm trying to the get the "package modules" working in the new package std.serialization I'm working on. I have a sample file I'm compiling, looking like this:
>
> import std.serialization;
> import std.serialization.archives;
>
> class Foo
> {
>     int a;
> }
>
> void main ()
> {
>     auto archive = new XmlArchive!();
>     auto serializer = new Serializer(archive);
>
>     auto foo = new Foo;
>     foo.a = 3;
>
>     serializer.serialize(foo);
>     auto foo2 = serializer.deserialize!(Foo)(archive.untypedData);
>
>     assert(foo2.a == 3);
>     assert(foo.a == foo2.a);
> }
>
> When I compile it I get these linker errors:
>
> Undefined symbols for architecture x86_64:
>   "_D3std13serialization12__ModuleInfoZ", referenced from:
>       _D4main12__ModuleInfoZ in main.o
>   "_D3std13serialization8archives12__ModuleInfoZ", referenced from:
>       _D4main12__ModuleInfoZ in main.o
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status
> --- errorlevel 1
>
> If I instead only import the exact modules that are needed, like this:
>
> import std.serialization.serializer;
> import std.serialization.archives.xmlarchive;
>
> Everything works as expected.
>
> I have a module declaration in std/serialization/package.d, like this:
>
> module std.serialization;
>
> And in std/serialization/archives/package.d
>
> module std.archives;
>
> First, I don't know if I should have any module declarations at all in these "package modules". Or if they should be like above or something like "module std.archives.package;".
>
> If I remove the module declarations in the package modules I get this assertion in the compiler:
>
> Assertion failed: (p->isPkgMod == PKGmodule), function load, file import.c, line 136.
> Abort trap:
>
> I don't know if I'm doing something wrong of if this new feature isn't working properly.
>
> The code is available there: https://github.com/jacob-carlborg/phobos/tree/serialization

Looks to me like you are trying to import the package. It never worked. That is why over the time two groups of D developers emerged. Those who use the /path/to/package/all.d and those who use /path/to/package/_.d ... I belong to the first group, and would expect something like: import std.serialization.all; or import std.serialization._;
Some guys rightfully argued about not being able to be more selective, but so far I think the approach above works perfectly.

On Wednesday, 14 August 2013 at 15:35:37 UTC, Dejan Lekic wrote:
> On Wednesday, 14 August 2013 at 14:43:47 UTC, Jacob Carlborg wrote:
>> I'm trying to the get the "package modules" working in the new package std.serialization I'm working on. I have a sample file I'm compiling, looking like this:
>>
>> import std.serialization;
>> import std.serialization.archives;
>>
>> class Foo
>> {
>>    int a;
>> }
>>
>> void main ()
>> {
>>    auto archive = new XmlArchive!();
>>    auto serializer = new Serializer(archive);
>>
>>    auto foo = new Foo;
>>    foo.a = 3;
>>
>>    serializer.serialize(foo);
>>    auto foo2 = serializer.deserialize!(Foo)(archive.untypedData);
>>
>>    assert(foo2.a == 3);
>>    assert(foo.a == foo2.a);
>> }
>>
>> When I compile it I get these linker errors:
>>
>> Undefined symbols for architecture x86_64:
>>  "_D3std13serialization12__ModuleInfoZ", referenced from:
>>      _D4main12__ModuleInfoZ in main.o
>>  "_D3std13serialization8archives12__ModuleInfoZ", referenced from:
>>      _D4main12__ModuleInfoZ in main.o
>> ld: symbol(s) not found for architecture x86_64
>> collect2: ld returned 1 exit status
>> --- errorlevel 1
>>
>> If I instead only import the exact modules that are needed, like this:
>>
>> import std.serialization.serializer;
>> import std.serialization.archives.xmlarchive;
>>
>> Everything works as expected.
>>
>> I have a module declaration in std/serialization/package.d, like this:
>>
>> module std.serialization;
>>
>> And in std/serialization/archives/package.d
>>
>> module std.archives;
>>
>> First, I don't know if I should have any module declarations at all in these "package modules". Or if they should be like above or something like "module std.archives.package;".
>>
>> If I remove the module declarations in the package modules I get this assertion in the compiler:
>>
>> Assertion failed: (p->isPkgMod == PKGmodule), function load, file import.c, line 136.
>> Abort trap:
>>
>> I don't know if I'm doing something wrong of if this new feature isn't working properly.
>>
>> The code is available there: https://github.com/jacob-carlborg/phobos/tree/serialization
>
> Looks to me like you are trying to import the package. It never worked. That is why over the time two groups of D developers emerged. Those who use the /path/to/package/all.d and those who use /path/to/package/_.d ... I belong to the first group, and would expect something like: import std.serialization.all; or import std.serialization._;
> Some guys rightfully argued about not being able to be more selective, but so far I think the approach above works perfectly.

Ignore this, I did not see your package.d file there...

On Wednesday, 14 August 2013 at 15:35:37 UTC, Dejan Lekic wrote:
> Looks to me like you are trying to import the package. It never worked. That is why over the time two groups of D developers emerged. Those who use the /path/to/package/all.d and those who use /path/to/package/_.d ... I belong to the first group, and would expect something like: import std.serialization.all; or import std.serialization._;
> Some guys rightfully argued about not being able to be more selective, but so far I think the approach above works perfectly.

Package imports work now with 'import std.serialization' actually importing std.serialization.package which then publicly imports what it needs. I don't remember which version this feature is in but I think it was 2.063(?) or perhaps master.

On Wednesday, 14 August 2013 at 15:45:58 UTC, Kapps wrote:
> On Wednesday, 14 August 2013 at 15:35:37 UTC, Dejan Lekic wrote:
>> Looks to me like you are trying to import the package. It never worked. That is why over the time two groups of D developers emerged. Those who use the /path/to/package/all.d and those who use /path/to/package/_.d ... I belong to the first group, and would expect something like: import std.serialization.all; or import std.serialization._;
>> Some guys rightfully argued about not being able to be more selective, but so far I think the approach above works perfectly.
>
> Package imports work now with 'import std.serialization' actually importing std.serialization.package which then publicly imports what it needs. I don't remember which version this feature is in but I think it was 2.063(?) or perhaps master.

Yeah, I was too fast, did not see the package.d, as I said in my previous post... Sorry... :)

On Wednesday, 14 August 2013 at 15:32:25 UTC, Andrej Mitrovic wrote:
> On 8/14/13, Jacob Carlborg <doob@me.com> wrote:
>> And in std/serialization/archives/package.d
>>
>> module std.archives;
>
> I think that should be 'module std.serialization.archives'.

Good catch Andrej! :)