On Thursday, 18 July 2013 at 07:16:35 UTC, Jonathan M Davis wrote:
> On Thursday, July 18, 2013 08:45:25 JS wrote:
>> On Wednesday, 17 July 2013 at 17:51:15 UTC, Jonathan M Davis
>> 
>> wrote:
>> > On Wednesday, July 17, 2013 11:34:56 JS wrote:
>> >> Is is possible to import all modules using something import
>> >> a.b.*;?
>> >> 
>> >> I'd like to partition some modules up into smaller pieces to
>> >> simplify modification(reduce scrolling) but, of course, this
>> >> increases the number of imports drastically.
>> > 
>> > This has been implemented in git master:
>> > 
>> > http://wiki.dlang.org/DIP37
>> > 
>> > - Jonathan M Davis
>> 
>> Thanks, I've updated the compiler to 2.063.2 and made my
>> hierarchy like
>> 
>> lib/package.d
>> lib/mod.d
>> lib/dir1/package.d
>> lib/dir1/a.d
>> lib/dir1/b.d
>> lib/dir2/package.d
>> lib/dir2/c.d
>> 
>> each package.d file publically imports all sub packages(by
>> chaining package imports and importing same directory modules):
>> 
>> lib/package.d:
>> module Package;
>> public import mod.d;
>> public import dir1.Package;
>> public import dir2.Package;
>> 
>> lib/dir1/package.d;
>> module dir1.Package;
>> public import dir1.a;
>> public import dir2.b;
>> 
>> 
>> etc....
>> 
>> This should allow me to import any resolution I need. e.g., if I
>> want the whole library I just import lib/package.d.
>> 
>> 
>> When I do this dmd can't find my module files.
>> 
>> I have only included the root dir(lib) in sc.ini, hopefully I do
>> not need to include every single subdirectory in lib for it to
>> work ;/ ? (this would be better to be auto generated)
>
> Normally, nothing like that has any business in sc.ini. sc.ini is supposed to
> be for the standard stuff, not your personal stuff. You should be passing it to
> the compiler using the appropriate compiler flags (-I in this case IIRC). Now,
> you obviously _can_ stick it all in your sc.ini file you want to, but I believe
> that that would generally be considered bad practice.
>

> As for your actual files, you're making several mistakes.
>
> 1. It's not module Package. Not only is it generally considered bad practice
> to use any uppercase letters in a module or package name, but the module name
> for a package.d file does not include package. So, for instance, if
> std.datetime were a package with std/datetime/package.d in it, then that
> package.d file would have module std.datetime; at the top.
>

I intentionally chose uppercase because it is more informative. I am not worried about cross-compilation issues at this point. iPackage.d looks nicer than ipackage.d.

I did add Package to the end of module names and did uppercase package.d, possibly that is part of thep roblem.

> 2. Maybe it's just a typo, but you have some imports which end with .d, which
> isn't legal.

yes

> 3. A top-level package.d won't work. There's no name to give it to import and
> no name to give its module declaration. Also, I don't believe that the top
> level is considered a package in the first place. I believe that the only
> reason the package modifer works on the top level is the fact that package is
> outright broken right now ( http://d.puremagic.com/issues/show_bug.cgi?id=143
> ) and is pretty much treated as public. Once that's been fixed, any attempt at
> using package at the top level will fail.
>
> I might be missing something else, but I think that your main problem is how
> you name the module declarations in your package.d files.
>
> - Jonathan M Davis

I'll probably have to setup visual d to insert the includes dirs on the command line. I had the same issue before when trying to include modules and edited sc.ini to get it to work. As far as I can tell, there is no way to set global includes in visual d which is why I used sc.ini. (I don't want to setup the includes directory for each project I create)

In any case, the real question I have is: Does dmd require each directory for each module to be included by -I? Or is the base directory good enough and package resolution will get at the sub directories?

One of the reasons I used Package.d was so I can get around an issue like https://github.com/D-Programming-Language/dmd/pull/2152 which I think I was running into.

Instead I think by renaming Package.d to All.d and import dir.All; seems to work ok. Obviously adding .All to everything is annoying but it won't be hard to write a parser to fix that once package gets working.

On Thursday, July 18, 2013 09:25:46 JS wrote:
> In any case, the real question I have is: Does dmd require each directory for each module to be included by -I? Or is the base directory good enough and package resolution will get at the sub directories?

The base directory of each package hierarchy must be passed to dmd with -I. So, if you have the module abc.foo.bar, then dmd must have been passed the directory that abc is in. A module's fully qualified name is its directory hierarchy, and dmd is always looking for the base of the hierarchy, so you give it each directory which is the root of a package hierarchy. If you have abc.foo.bar, and you passed it the abc or abc/foo, it would then effectively be looking for abc/abc/foo/bar.d or abc/foo/abc/foo/bar.d.

- Jonathan M Davis

On Thursday, 18 July 2013 at 07:43:33 UTC, Jonathan M Davis wrote:
> On Thursday, July 18, 2013 09:25:46 JS wrote:
>> In any case, the real question I have is: Does dmd require each
>> directory for each module to be included by -I? Or is the base
>> directory good enough and package resolution will get at the sub
>> directories?
>
> The base directory of each package hierarchy must be passed to dmd with -I.
> So, if you have the module abc.foo.bar, then dmd must have been passed the
> directory that abc is in. A module's fully qualified name is its directory
> hierarchy, and dmd is always looking for the base of the hierarchy, so you
> give it each directory which is the root of a package hierarchy. If you have
> abc.foo.bar, and you passed it the abc or abc/foo, it would then effectively be
> looking for abc/abc/foo/bar.d or abc/foo/abc/foo/bar.d.
>
> - Jonathan M Davis


using All instead of package as the name worked really well, I can easily chain imports and each module can import the root to import the whole library.

e.g.,
lib/All.d
lib/modules*.d
lib/dir?/.../dir?/modules*.d

each module only has to import All to get access to the whole library. Only the final directories need to import each module. Each internal directory just has to import the All.d's of each subdirectory and any modules in the same directory.

Seems to work really well and very simple to update and include various parts of the library.

e.g.,
/all.d
/a.d
/dir/all.d
/dir/b.d

all.d:
module all;
public import a;
public import dir.b;

/dir/all.d
module dir.all;
public import dir.b;

(I do have my lib partitions for different libraries I have something like import mylib.all)

essentially all acts like *. e.g., import dir.*; is the same as import dir.all; (except * would automatically import everything for you making life easier).

On Thursday, July 18, 2013 10:10:13 JS wrote:
> using All instead of package as the name worked really well, I can easily chain imports and each module can import the root to import the whole library.

Yes. You can do that, though again I'd point out that using uppercase letters in module and package names is generally frowned upon. That's just how public import works, and plenty of folks have had all.d files in their projects for years now. None of that requires a new version of dmd. The key thing about the DIP (which _does_ require_ the git version of dmd) is that it allows you to import the package as if it were a module. This will allow us to do things like split up std.datetime or std.algorithm in place without breaking anyone's code, as import std.datetime or import std.algorithm would continue to work as they had as long as their package.d files publicly imported everything that had been in those modules before.

I would expect that in the long term, package.d will supplant all.d completely, but you're obviously free to use it all.d if you want to.

- Jonathan M Davis

On Thursday, 18 July 2013 at 08:50:34 UTC, Jonathan M Davis wrote:
> On Thursday, July 18, 2013 10:10:13 JS wrote:
>> using All instead of package as the name worked really well, I
>> can easily chain imports and each module can import the root to
>> import the whole library.
>
> Yes. You can do that, though again I'd point out that using uppercase letters
> in module and package names is generally frowned upon. That's just how public
> import works, and plenty of folks have had all.d files in their projects for
> years now. None of that requires a new version of dmd. The key thing about the
> DIP (which _does_ require_ the git version of dmd) is that it allows you to
> import the package as if it were a module. This will allow us to do things
> like split up std.datetime or std.algorithm in place without breaking anyone's
> code, as import std.datetime or import std.algorithm would continue to work as
> they had as long as their package.d files publicly imported everything that had
> been in those modules before.
>
> I would expect that in the long term, package.d will supplant all.d
> completely, but you're obviously free to use it all.d if you want to.
>
Yes, but it's obviously not useable at this point and when it does it will be easy to switch over to.

AFAIK, the only issue with uppercase is case sensitivity, and as long as d does not modify case then I'm not worried about it. Just because something is frowned apon doesn't mean squat to me unless there is a good reason. I'll prefer readability over common useage.

Essentially all emulates the package.d, and I like it because it's descriptive and easily maintainable... thats all I was after in the first place. Too bad package doesn't work properly ;/

On Thursday, July 18, 2013 11:38:41 JS wrote:
> Essentially all emulates the package.d, and I like it because it's descriptive and easily maintainable... thats all I was after in the first place. Too bad package doesn't work properly ;/

Do you mean the package attribute or package.d? package.d should work just fine. I'm not aware of any outstanding bugs with it. The attribute is still broken though, I believe.

- Jonathan M Davis

On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis wrote:
> On Thursday, July 18, 2013 11:38:41 JS wrote:
>> Essentially all emulates the package.d, and I like it because
>> it's descriptive and easily maintainable... thats all I was after
>> in the first place. Too bad package doesn't work properly ;/
>
> Do you mean the package attribute or package.d? package.d should work just
> fine. I'm not aware of any outstanding bugs with it. The attribute is still
> broken though, I believe.
>
> - Jonathan M Davis

When I used package.d things didn't work out like they do using all. It may be due to bugs on my end(I had a few typos). Maybe I will try it again though(simple rename and remove .all).

On Thursday, July 18, 2013 23:53:53 JS wrote:
> On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis wrote:
> > On Thursday, July 18, 2013 11:38:41 JS wrote:
> >> Essentially all emulates the package.d, and I like it because
> >> it's descriptive and easily maintainable... thats all I was
> >> after
> >> in the first place. Too bad package doesn't work properly ;/
> > 
> > Do you mean the package attribute or package.d? package.d
> > should work just
> > fine. I'm not aware of any outstanding bugs with it. The
> > attribute is still
> > broken though, I believe.
> > 
> > - Jonathan M Davis
> 
> When I used package.d things didn't work out like they do using
> all. It may be due to bugs on my end(I had a few typos). Maybe I
> will try it again though(simple rename and remove .all).

Well, what you were posting was wrong, and I believe that I pointed out why. A package.d file's module declaration needs to have the same name as the package. So, if you have

abc/foo/package.d

then package.d needs

module abc.foo;

for its module declaration. Then you import the package as if it were a module, so you get any public imports which were in it. But as I said before, this won't work for the top level, because the top level isn't a package. You need a sub-folder to have a package.

- Jonathan m Davis

On Thursday, 18 July 2013 at 23:14:39 UTC, Jonathan M Davis wrote:
> On Thursday, July 18, 2013 23:53:53 JS wrote:
>> On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis wrote:
>> > On Thursday, July 18, 2013 11:38:41 JS wrote:
>> >> Essentially all emulates the package.d, and I like it because
>> >> it's descriptive and easily maintainable... thats all I was
>> >> after
>> >> in the first place. Too bad package doesn't work properly ;/
>> > 
>> > Do you mean the package attribute or package.d? package.d
>> > should work just
>> > fine. I'm not aware of any outstanding bugs with it. The
>> > attribute is still
>> > broken though, I believe.
>> > 
>> > - Jonathan M Davis
>> 
>> When I used package.d things didn't work out like they do using
>> all. It may be due to bugs on my end(I had a few typos). Maybe I
>> will try it again though(simple rename and remove .all).
>
> Well, what you were posting was wrong, and I believe that I pointed out why. A
> package.d file's module declaration needs to have the same name as the package.
> So, if you have
>
> abc/foo/package.d
>
> then package.d needs
>
> module abc.foo;
>
> for its module declaration. Then you import the package as if it were a
> module, so you get any public imports which were in it. But as I said before,
> this won't work for the top level, because the top level isn't a package. You
> need a sub-folder to have a package.
>

Yes, that is one of the things I tried.. and I'm not working from the top level since that is the library container folder which contains all the actual libraries which then contain the packages.

When I rename the all.d files to package and import the package I get two errors:

Error	1	Error: can only import from a module, not from package JS
Error	2	Error: module JS is in file 'JS.d' which cannot be read		


My hierarchy is

/lib/JS/package.d
module JS;
public import ....

and I import JS by using import JS;

vs using all.d

/lib/JS/All.d
module JS.All;
public import ....

and I import JS by using import JS.All;

otherwise everything is identical. .All works without issue.

Note I reverted to 2.062 because 2.063.2 was causing weird errors in Visual D... so this might be the problem but I remember getting the same errors when I was trying 2.063.2(but possibly not)...

In any case, I'll just stick with All for now, I think I like how explicit it is.