September 25, 2006 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Miles | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars Ivar Igesund | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 |
Copyright © 1999-2021 by the D Language Foundation