Hey,

as i see it the -Ipath command for dmd just imports the files within a directory but it doesnt work for sub directories, so i can write something like:

import subdirectoryFromPath.file;

Also with dub this doesnt seem possible (sourcePaths seems to work as the -I command).

Is there a way to do what i want? Or am i doing something wrong?
And by the way what is the difference from sourcePaths to importPaths?

On Wednesday, 4 October 2017 at 16:31:35 UTC, Jiyan wrote:
> Hey,
>
> as i see it the -Ipath command for dmd just imports the files within a directory but it doesnt work for sub directories, so i can write something like:
>
> import subdirectoryFromPath.file;
>
> Also with dub this doesnt seem possible (sourcePaths seems to work as the -I command).
>
> Is there a way to do what i want? Or am i doing something wrong?


If you have this directory tree:

- mylib
-- pack1
--- a.d
--- b.d
---- pack2
----- c.d

Then you would pass -Imylib to the compiler. In your code, you can write the following:

import pack1.a;
import pack1.pack2.c;

You don't import files or directories, just packages and modules. By default, package names correspond to directory names and module names correspond to file names, but they don't have to (it's best practice, though).

> And by the way what is the difference from sourcePaths to importPaths?

sourcePaths where DUB can find additional files, outside of the default source directory, to pass to the compiler for compilation. importPaths will all be passed to the compile as -I. It seems you think that importing a module causes its source file to be automatically compiled. That doesn't happen.

imports are strictly for the compiler to know which symbols are available for the current module to use. It does not attempt to compile imported modules. Imported modules might be part of your program or they might be part of a precompiled library. In the latter case, they don't need to be compiled because they already are. So the compiler leaves it up to you to decide which modules need to be compiled.

Dub, by default, will make sure all modules in your source directory are compiled. It will also guarantee the compiler knows where to find them for imports. Sometimes, you might also want to import files from a library that isn't available from code.dlang.org. You can use importPaths to tell dub additional paths to give the compiler. If those files are part of a precompiled library you can link the library and you're done. If they aren't, you can use sourcePaths to tell DUB that all the source modules in the additional paths also need to be passed to the compiler for compiling and linking into the final executable.

On Thursday, 5 October 2017 at 00:28:32 UTC, Mike Parker wrote:
> On Wednesday, 4 October 2017 at 16:31:35 UTC, Jiyan wrote:
>> [...]
>
>
> If you have this directory tree:
>
> - mylib
> -- pack1
> --- a.d
> --- b.d
> ---- pack2
> ----- c.d
>
> [...]

Thank you, i think i kinda got that :)

But as i see it with sourcePaths the directories are not influencing
the module names(in the directories except "source"), so "dir.sub"
will just have the name "sub" is there a way around that, except
naming every module like:

module dir.sub;

On Thursday, 5 October 2017 at 11:44:00 UTC, Jiyan wrote:
>>> [...]

> But as i see it with sourcePaths the directories are not influencing
> the module names(in the directories except "source"), so "dir.sub"
> will just have the name "sub" is there a way around that, except
> naming every module like:
>
> module dir.sub;

You have to pass the parent directory of dir rather than dir itself, e.g.:

- src
-- dir
--- sub.d

dmd -Isrc

Regardless, every module should have a module name at the top. There are situations where the inferred package & module names can't work.

On Thursday, 5 October 2017 at 12:17:23 UTC, Mike Parker wrote:
> On Thursday, 5 October 2017 at 11:44:00 UTC, Jiyan wrote:
>>>> [...]
>
>> But as i see it with sourcePaths the directories are not influencing
>> the module names(in the directories except "source"), so "dir.sub"
>> will just have the name "sub" is there a way around that, except
>> naming every module like:
>>
>> module dir.sub;
>
> You have to pass the parent directory of dir rather than dir itself, e.g.:
>
> - src
> -- dir
> --- sub.d
>
> dmd -Isrc
>
> Regardless, every module should have a module name at the top. There are situations where the inferred package & module names can't work.

Ugh. Sorry, I mean for sourcePaths you have to pass `src` and not `dir`.

On Thursday, 5 October 2017 at 12:18:57 UTC, Mike Parker wrote:

>> Regardless, every module should have a module name at the top. There are situations where the inferred package & module names can't work.
>
> Ugh. Sorry, I mean for sourcePaths you have to pass `src` and not `dir`.

And actually, now that I think about it, this is probably one of those situations where the defualt fails. So yes, you'll need a module name.

On Thursday, 5 October 2017 at 12:25:27 UTC, Mike Parker wrote:

>
> And actually, now that I think about it, this is probably one of those situations where the defualt fails. So yes, you'll need a module name.

Right. I had to go back and look at what I wrote in Learning D, which is the last (and only) time I played around with the default module behavior. I always use module statements (and you should too).

When you import dir.sub and the compiler finds it's missing in its imported module list, it will look in for the `dir/sub.d` from the current working directory. If it doesn't find it, you get an import error. If you do this:

dmd main.d ../dir/sub.d

Then sub.d can have any module statement you want -- you could do this:

module this.is.the.sub.module;

And it wouldn't matter, as long as main.d imported this.is.the.sub.module and not dir.sub. However, if sub.d has no module statement, the compiler isn't going to infer a package. It's going to be in the default package, so it's simply `sub` and not `dir.sub`. If you import dir.sub, the compiler will still look for a subdirectory named `dir`, but it won't find it.

This latter bit is your issue. dub is passing dir/sub.d to the compiler, but without a module statement the compiler treats it simply as `sub` and your `dir.sub` import fails.

On Thursday, 5 October 2017 at 12:35:26 UTC, Mike Parker wrote:
> On Thursday, 5 October 2017 at 12:25:27 UTC, Mike Parker wrote:
>
>> [...]
>
> Right. I had to go back and look at what I wrote in Learning D, which is the last (and only) time I played around with the default module behavior. I always use module statements (and you should too).
>
> [...]

Thank you :)

PS: is it spam to say thank you?

On 10/05/2017 03:34 PM, Jiyan wrote:

> PS: is it spam to say thank you?

Thank you for asking! :p

I used to have strong feelings about this in the past. I still think it's spam; I don't expect any thanks from anyone and I think gratitude should be  implied.

Some people have different opinions: They say it makes them happy to see an explicit gratitude.

I don't care anymore especially because it's not very common anyway.

Ali