Bruno Medeiros wrote:
I was a bit confused at first about what sourcePaths did (I though it was the
same as a source folder in Eclipse, in a sense), but now I get it. However, I
can't say I like the design of it. When someone defines a sourcePath in a DUB
package, in the vast majority of times, they will want that to be in the
import path as well (so it has to be defined in importPaths as well). You see,
if you pass a D source file to DMD, but that source file is not part of the
import path (or it is, but the (full) module name doesn't match the directory
structure up to the import root), then that source file is not importable
anywhere in D code. This has to be a very, very niche use case then (I'd
like to see examples otherwise). And partially covered by "sourceFiles"
already. I would estimate that 99% of sourcePaths will be importPaths as well.
And yet for that use case (a sourcePath folder is also an importPath folder)
there is no way to do that with just one attribute in the .json. It would be
better if we had such a mechanism.I guess not that many people have been annoyed by this yet, only due to the
implicitly defined source/import folders (that is, if you are using the
"source" or "src" folders). In this way both sourcePath and importPaths will
be the same automatically, because they match to the same folders, and nothing
was explicitly defined.
Are you kidding? :)
How about a project that has the same source tree, but produces, say three
executables, and two libraries? :D Furthermore, these two libraries may be in
completely independent packages, one is com.vendorX.productX, and second is
so.ddn.sql.driver.vendorX ... In this case you have one sourcePath, and at least
two import paths. Not to mention your project's dependencies...
Unfortunately, D still has no project (that I know of) that is of such
complexity. Wait until D gets more adopted by big companies, and gets used in
large projects...
Dejan Lekic
dejan.lekic (a) gmail.com
http://dejan.lekic.org