Re: Simple import question
On Wednesday, 15 October 2014 at 16:11:22 UTC, Steven Schveighoffer wrote: *snip* You might of missed Adam's response up there: But the best way is to explicitly pass all the file names to the compiler: dmd yourfile.d file2.d folder/file3.d and so on... Doing that will serve you best in the long run, it will work with any module name and will link better too. I also prefer explicitly telling the compiler what I want to be compiled instead of the start here and pull everything you can find approach.
Re: Simple import question
On Thursday, 16 October 2014 at 10:59:29 UTC, Rei Roldan wrote: On Wednesday, 15 October 2014 at 16:11:22 UTC, Steven Schveighoffer wrote: *snip* You might of missed Adam's response up there: But the best way is to explicitly pass all the file names to the compiler: dmd yourfile.d file2.d folder/file3.d and so on... Doing that will serve you best in the long run, it will work with any module name and will link better too. I also prefer explicitly telling the compiler what I want to be compiled instead of the start here and pull everything you can find approach. i think you are going in right way
Re: Simple import question
On 10/16/14 6:59 AM, Rei Roldan wrote: On Wednesday, 15 October 2014 at 16:11:22 UTC, Steven Schveighoffer wrote: *snip* You might of missed Adam's response up there: But the best way is to explicitly pass all the file names to the compiler: dmd yourfile.d file2.d folder/file3.d and so on... Doing that will serve you best in the long run, it will work with any module name and will link better too. No, I didn't miss it. As I said, you can do this with mismatched module and file names, but you will encounter issues if your files need to be imported elsewhere. Note, you can send all the files to the compiler, AND name your files/directories after your modules/packages. Matching the names actually gives you the most options. I also prefer explicitly telling the compiler what I want to be compiled instead of the start here and pull everything you can find approach. What I am specifically identifying as a problem is if you purposely do not name your files and directories after your module structure. Then you are REQUIRED to pass all the files to the compiler, and this doesn't work out well if you just want to import them (and not compile them), e.g. for a pre-compiled library. -Steve
Re: Simple import question
I don't see how passing all required files to the compiler could possible raise an issue with module discoverability. Unless I'm missing something? In regards to pains if folder|file names / package|module names don't match, imho, physical organization of files should never (ever) be of any concern to the compiler.
Re: Simple import question
On 10/15/14 4:59 AM, Rei Roldan wrote: I don't see how passing all required files to the compiler could possible raise an issue with module discoverability. Unless I'm missing something? In regards to pains if folder|file names / package|module names don't match, imho, physical organization of files should never (ever) be of any concern to the compiler. import a.b.c; If you didn't pass the file for a.b.c to the compiler, how does it know where to find it? The module system is inherently linked to the filesystem. The way around it is to pass all modules to the compiler that you will be importing so it knows where they are. But this can lead to problems if you don't actually want to compile them, just reference them. The simplest thing to do is to make your file organization match your package/module structure. The compiler understands that and works well with it, no matter what you are doing. -Steve
Re: Simple import question
On Wednesday, October 15, 2014 12:11:22 Steven Schveighoffer via Digitalmars-d- learn wrote: On 10/15/14 4:59 AM, Rei Roldan wrote: I don't see how passing all required files to the compiler could possible raise an issue with module discoverability. Unless I'm missing something? In regards to pains if folder|file names / package|module names don't match, imho, physical organization of files should never (ever) be of any concern to the compiler. import a.b.c; If you didn't pass the file for a.b.c to the compiler, how does it know where to find it? The module system is inherently linked to the filesystem. The way around it is to pass all modules to the compiler that you will be importing so it knows where they are. But this can lead to problems if you don't actually want to compile them, just reference them. The simplest thing to do is to make your file organization match your package/module structure. The compiler understands that and works well with it, no matter what you are doing. In general, if your folder/file layout and package/module layout don't match, you're asking for trouble. The compiler can be told to look in other places for modules to import (e.g. dmd.conf does that to tell the compiler where druntime and Phobos are), but it's generally a bad idea to do that with your projects. Leave that to libraries that you're compiling against. And you have to tell it the location of every file that your compiling anyway (unless you're using rdmd instead of dmd, but that just makes the folder/file layout that much more important, because then rdmd has to find the modules itself). It's just all around better to give into the fact that packages are supposed to correspond to folders and modules are supposed to correspond to files within those folders - with the exact same layout in both the filesystem and the package system. - Jonathan M Davis
Simple import question
Hope this question is not too simple minded but, In the TDPL it says: To import one module from another, specify the name of the module in an import declaration. The name must include the relative path computed from the directory where compilation takes place Ok, but how does one determine where compilation takes place? Is it: 1) The directory where main() resides. 2) The directory where the executable resides after it is built. 3) The directory of where the dmd compiler is at.
Re: Simple import question
It's the current working directory, i.e. the directory from where you run the compiler. IDEs usually use the root directory of the project as working directory.
Re: Simple import question
On Thursday, 9 October 2014 at 18:21:32 UTC, WhatMeWorry wrote: To import one module from another, specify the name of the module in an import declaration. The name must include the relative path computed from the directory where compilation takes place This is not true. It is a REALLY common misconception, but it is not true. The import name must match the name given in the module declaration of the file. So in the file you're importing, add module your.name; to the top. In the main file, import it as import your.name;. If those two don't match, it will complain cannot import module foo as foo.bar or something like that. It is recommended that the module name match the file name and folder name, but it is the module declaration at the top that matters, not the file/folder name. Ok, but how does one determine where compilation takes place? The directory from which you run the compiler. But the best way is to explicitly pass all the file names to the compiler: dmd yourfile.d file2.d folder/file3.d and so on... Doing that will serve you best in the long run, it will work with any module name and will link better too.
Re: Simple import question
On 10/9/14 3:30 PM, Adam D. Ruppe wrote: On Thursday, 9 October 2014 at 18:21:32 UTC, WhatMeWorry wrote: To import one module from another, specify the name of the module in an import declaration. The name must include the relative path computed from the directory where compilation takes place This is not true. It is a REALLY common misconception, but it is not true. The import name must match the name given in the module declaration of the file. So in the file you're importing, add module your.name; to the top. In the main file, import it as import your.name;. If those two don't match, it will complain cannot import module foo as foo.bar or something like that. Yes, but in order to read the file, it has to be passed to the compiler, or reside at the location dictated by that module name. This is something quite different from C/C++, because the location in the filesystem doesn't matter at all for the compiler, only the preprocessor. Here, the file location AND module declaration are important. It is recommended that the module name match the file name and folder name, but it is the module declaration at the top that matters, not the file/folder name. You will encounter great pains to not do this (match folder/file names with package/module names). -Steve
