View mode: basic / threaded / horizontal-split · Log in · Help
September 25, 2006
Re: Proposal for a standard for D library naming
> 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
Re: Proposal for a standard for D library naming
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
Re: Proposal for a standard for D library naming
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
Re: Proposal for a standard for D library naming
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
Re: Proposal for a standard for D library naming
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
Re: Proposal for a standard for D library naming
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
Re: Proposal for a standard for D library naming
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
Re: Proposal for a standard for D library naming
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
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home