• WhatMeWorry (11/11) Oct 09 2014 Hope this question is not too simple minded but,
• "Daniele =?UTF-8?B?Qm9uZMOsIg==?= <daniele.bondi.dev gmail.com> (4/4) Oct 09 2014 It's the current working directory, i.e. the directory from where
• Adam D. Ruppe (16/21) Oct 09 2014 This is not true. It is a REALLY common misconception, but it is
• Steven Schveighoffer (9/23) Oct 09 2014 Yes, but in order to read the file, it has to be passed to the compiler,...
• Rei Roldan (5/5) Oct 15 2014 I don't see how passing all required files to the compiler could
• Steven Schveighoffer (12/17) Oct 15 2014 import a.b.c;
• Jonathan M Davis via Digitalmars-d-learn (15/31) Oct 15 2014 In general, if your folder/file layout and package/module layout don't m...
• Rei Roldan (11/12) Oct 16 2014 You might of missed Adam's response up there:
• Sag Academy (2/15) Oct 16 2014 i think you are going in right way
• Steven Schveighoffer (13/23) Oct 16 2014 No, I didn't miss it. As I said, you can do this with mismatched module

"WhatMeWorry" <kheaser gmail.com> writes:

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.

"Daniele =?UTF-8?B?Qm9uZMOsIg==?= <daniele.bondi.dev gmail.com> writes:

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.

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

"Rei Roldan" <raroldan gmail.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Jonathan M Davis via Digitalmars-d-learn writes:

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

"Rei Roldan" <raroldan gmail.com> writes:

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.

"Sag Academy" <sagacademyjaipur gmail.com> writes:

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

Steven Schveighoffer <schveiguy yahoo.com> writes:

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