September 25, 2006
> Example:
>    import a.b.c;
> 
> Looks for
>     a.b.c.o

I think that DMD looks for a/b/c.o (a\b\c.obj on windows).
September 25, 2006
On Sun, 24 Sep 2006 23:17:22 -0300, Miles wrote:

>> Example:
>>    import a.b.c;
>> 
>> Looks for
>>     a.b.c.o
> 
> I think that DMD looks for a/b/c.o (a\b\c.obj on windows).

Oops. Of course your right.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
25/09/2006 12:21:45 PM
September 25, 2006
Derek Parnell wrote:
> 
> So a further complication is what should Build do if the module source
> files are more recent than the matching library? Currently, it recompiles
> the source files and uses the resulting object files in the linkage.

Shouldn't a module be recompiled if its object file is older than the module or any of its dependencies?  If -inline is specified at any rate.


Sean
September 26, 2006
Lars Ivar Igesund wrote:
> Bruno Medeiros wrote:
> 
>> Gregor Richards wrote:
>>>         o The only rule is that any module must be in the most
>>> specifically-named library corresponding to that module. That is, if you
>>> have libD.a.b.so.0 and libD.a.so.0, the module a.b.c should be in
>>> libD.a.b.so.0, not libD.a.so.0. Doing otherwise is fairly ridiculous
>>> anyway.
>>>
>>>
>>>
>> Why so? Why should a given library be splited across multiple so/dll
>> files according to package, instead of being compiled in just one file?
>>
>>
> 
> You totally missed the point, if the library _is_ split, then there should
> be a standardized way to decide which part a module is in.
> 

I see.

Well, But then I think it is a bad code "convention" to have subdivisions (packages) are not at the same level. That means that one should either have:
  a.*   // a lib with 'a' and all subpackages and modules
or have:
  // three related libs, each with it's subpackages and modules.
  a.b.*
  a.c.*
  a.d.*
This means that in the second option, package 'a' cannot have sub-modules, only sub-packages.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
September 26, 2006
Bruno Medeiros wrote:
> Lars Ivar Igesund wrote:
> 
>> Bruno Medeiros wrote:
>>
>>> Gregor Richards wrote:
>>>
>>>>         o The only rule is that any module must be in the most
>>>> specifically-named library corresponding to that module. That is, if you
>>>> have libD.a.b.so.0 and libD.a.so.0, the module a.b.c should be in
>>>> libD.a.b.so.0, not libD.a.so.0. Doing otherwise is fairly ridiculous
>>>> anyway.
>>>>
>>>>
>>>>
>>> Why so? Why should a given library be splited across multiple so/dll
>>> files according to package, instead of being compiled in just one file?
>>>
>>>
>>
>> You totally missed the point, if the library _is_ split, then there should
>> be a standardized way to decide which part a module is in.
>>
> 
> I see.
> 
> Well, But then I think it is a bad code "convention" to have subdivisions (packages) are not at the same level. That means that one should either have:
>   a.*   // a lib with 'a' and all subpackages and modules
> or have:
>   // three related libs, each with it's subpackages and modules.
>   a.b.*
>   a.c.*
>   a.d.*
> This means that in the second option, package 'a' cannot have sub-modules, only sub-packages.
> 

No it doesn't - the rule is that a module is in the /most specific/ library.  So, if you wanted to split out a.b, a.c and a.d, but had a module a.mod, there would be a library libD.a.{so,a,lib,whatever}, but it would only contain the module a.mod, no subpackages.  A library is not assumed to be fully inclusive - it is assumed to be inclusive of everything that isn't in a more specifically-named library.

 - Gregor Richards

PS: Yes, I thought this all through :)
September 28, 2006
Gregor Richards wrote:
> Bruno Medeiros wrote:
>> Lars Ivar Igesund wrote:
>>
>>> Bruno Medeiros wrote:
>>>
>>>> Gregor Richards wrote:
>>>>
>>>>>         o The only rule is that any module must be in the most
>>>>> specifically-named library corresponding to that module. That is, if you
>>>>> have libD.a.b.so.0 and libD.a.so.0, the module a.b.c should be in
>>>>> libD.a.b.so.0, not libD.a.so.0. Doing otherwise is fairly ridiculous
>>>>> anyway.
>>>>>
>>>>>
>>>>>
>>>> Why so? Why should a given library be splited across multiple so/dll
>>>> files according to package, instead of being compiled in just one file?
>>>>
>>>>
>>>
>>> You totally missed the point, if the library _is_ split, then there should
>>> be a standardized way to decide which part a module is in.
>>>
>>
>> I see.
>>
>> Well, But then I think it is a bad code "convention" to have subdivisions (packages) are not at the same level. That means that one should either have:
>>   a.*   // a lib with 'a' and all subpackages and modules
>> or have:
>>   // three related libs, each with it's subpackages and modules.
>>   a.b.*
>>   a.c.*
>>   a.d.*
>> This means that in the second option, package 'a' cannot have sub-modules, only sub-packages.
>>
> 
> No it doesn't - the rule is that a module is in the /most specific/ library.  So, if you wanted to split out a.b, a.c and a.d, but had a module a.mod, there would be a library libD.a.{so,a,lib,whatever}, but it would only contain the module a.mod, no subpackages.  A library is not assumed to be fully inclusive - it is assumed to be inclusive of everything that isn't in a more specifically-named library.
> 
>  - Gregor Richards
> 
> PS: Yes, I thought this all through :)

It doesn't have to in *your* rule. But I was not describing your rule, I was describing mine. That is, I was saying that I would prefer a rule where a lib named "foo.{so|a|lib|whatever}" would mean that the lib "foo" contains all sub-packages of 'foo', not just the sub-modules.

Since that lib is almost surely dependent on that packages. No, it is just not dependent one those packages, it is *made by* those packages. And what if those packages change between versions, can you imagine the confusion? Consider these two versions of the same lib:

lib.foo.1.so
lib.foo.bar.1.so
lib.foo.gok.1.so

lib.foo.2.so
lib.foo.bar.2.so
lib.foo.newgok.2.so
lib.foo.zap.2.so

Now see how they look sorted in a lib dir:

lib.foo.1.so
lib.foo.2.so
lib.foo.bar.1.so
lib.foo.bar.2.so
lib.foo.gok.1.so
lib.foo.newgok.2.so
lib.foo.zap.2.so

It's quite a mess.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
September 28, 2006
Bruno Medeiros wrote:
> It doesn't have to in *your* rule. But I was not describing your rule, I was describing mine. That is, I was saying that I would prefer a rule where a lib named "foo.{so|a|lib|whatever}" would mean that the lib "foo" contains all sub-packages of 'foo', not just the sub-modules.

That was my original thought.

But that doesn't work.

> 
> Since that lib is almost surely dependent on that packages.

In the general case, module a.b.c is dependent on module a.c, NOT the reverse.  Dependency within a tree usually goes up or across the tree, not down.  Across is simply interlibrary dependency, up is where our point of contention is.

> No, it is just not dependent one those packages, it is *made by* those packages. And what if those packages change between versions, can you imagine the confusion? Consider these two versions of the same lib:
> 
> lib.foo.1.so
> lib.foo.bar.1.so
> lib.foo.gok.1.so

This is not the standard way of naming UNIX library versions, but OK, continuing ...

> 
> lib.foo.2.so
> lib.foo.bar.2.so
> lib.foo.newgok.2.so
> lib.foo.zap.2.so
> 
> Now see how they look sorted in a lib dir:
> 
> lib.foo.1.so
> lib.foo.2.so
> lib.foo.bar.1.so
> lib.foo.bar.2.so
> lib.foo.gok.1.so
> lib.foo.newgok.2.so
> lib.foo.zap.2.so

Makes sense to me.

> 
> It's quite a mess.
> 

I see no mess.

 - Gregor Richards
October 02, 2006
Gregor Richards wrote:
> Bruno Medeiros wrote:
>> It doesn't have to in *your* rule. But I was not describing your rule, I was describing mine. That is, I was saying that I would prefer a rule where a lib named "foo.{so|a|lib|whatever}" would mean that the lib "foo" contains all sub-packages of 'foo', not just the sub-modules.
> 
> That was my original thought.
> 
> But that doesn't work.
> 

Wouldn't work? Why not?

>>
>> Since that lib is almost surely dependent on that packages.
> 
> In the general case, module a.b.c is dependent on module a.c, NOT the reverse.  Dependency within a tree usually goes up or across the tree, not down.  Across is simply interlibrary dependency, up is where our point of contention is.
> 

I'm uncertain of that. Ultimately it depends on how one organizes his code structure and modules, but I think an organization where modules are usually dependent on submodules/subpackages(and not parent ones) is more logical.
(In any case it doesn't affect my point about the lib file)

>>
>> Now see how they look sorted in a lib dir:
>>
>> lib.foo.1.so
>> lib.foo.2.so
>> lib.foo.bar.1.so
>> lib.foo.bar.2.so
>> lib.foo.gok.1.so
>> lib.foo.newgok.2.so
>> lib.foo.zap.2.so
> 
> Makes sense to me.
> 
>>
>> It's quite a mess.
>>
> 
> I see no mess.
> 
>  - Gregor Richards

Well then, we've hit a subjective point(opinion), so not much to argue then. (I like the files as clean and tidy as possible)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
1 2 3 4
Next ›   Last »