Am 27.01.2014 04:33, schrieb Jakob Ovrum:
On Wednesday, 15 January 2014 at 14:12:47 UTC, Sönke Ludwig wrote:
A new and hopefully last beta version of DUB 0.9.21 has been released:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/826/

It contains some major new features, so extensive testing is needed to
get a solid release.

When using dub-test on one of my projects, I'm getting:

dub_test_root.d(15): Error: module deimos.ev from file libev\deimos\ev.d
must be imported as module 'deimos.ev'

dub_test_root appears to import it as `libev.deimos.ev`, which is wrong.
It looks like it should instead be looking at the module statement for
how to import.

The dub.json and project hierarchy can be found here[1].

[1] https://github.com/JakobOvrum/Dirk

I think there are two possibilities to solve this:

 - Like you already suggested, use the module statement of each file.
   This, however, will require to read and parse every source file -
   something which isn't required so far and I'd like to avoid that, if
   possible. Also, using the module statement will also not work in
   general, if not all files are compiled on the same compiler command
   line.

 - Use the closest matching import folder to infer the module name
   instead of the first match (i.e. "./libev" instead of "." in this
   case).

However, apart from this, this (quite popular) kind of file structure really is a pet peeve of mine. Anyone who uses the library can now do things like

import irc.client; // good
import deimos.ev; // bad - conflicts with any library that uses the
                  // libev DUB package
import libev.deimos.ev; // bad - conflicts with the module statement
import loader.windows; // bad - likely conflicts with other libraries

I understand that it is popular because a separate "source" or "src" folder can be avoided*. But it really is quite unclean considering how importing modules works in D.

* and it makes it harder for people to find the actual source code

Reply via email to