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?
