www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Imports

reply Jiyan <jiyan jiyan.info> writes:
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?
Oct 04 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Oct 04 2017
parent reply Jiyan <jiyan jiyan.info> writes:
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;
Oct 05 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Oct 05 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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`.
Oct 05 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Oct 05 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Oct 05 2017
parent reply Jiyan <jiyan jiyan.info> writes:
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?
Oct 05 2017
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 05 2017