http://d.puremagic.com/issues/show_bug.cgi?id=1585

           Summary: Imports should be searched relative to importing file
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: randleer@web.de


Imports should not be searched in ./ but relative to the importing file.
This way you dont have to change the current directory in order to compile, and
the imported files will always be found.


Example 1:

src/a.d
        module a;
        import b;

src/b.d
        module b;


Example 2:

src/foo/a.d
        module foo.a;
        import bar.b;

src/bar/b.d
        module bar.b;


The compiler will be able to find files like this:

(dir-of-current-file) (go as much directories up, as there are packages in
module name) (import name)

In example 2, this becomes:
src/foo/  ../  bar/b.d


If the file is not found in this way, then the file is searched in the include paths.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1585


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #1 from bugzilla@digitalmars.com  2007-10-16 12:13 -------
This is not a bug, it is working as designed. The reason it works this way is that if a module is in a package (i.e. directory) that package needs to be spelled out, not inferred.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1585


shro8822@vandals.uidaho.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shro8822@vandals.uidaho.edu
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Comment #2 from shro8822@vandals.uidaho.edu  2007-10-16 13:13 -------
I can't find the thread but a number of people have expressed interest in this being added. The simplest possible form would be of grate value.

if trying to resolve an import fails, check to see if the initial module has:

module package.mod;

if so check if package is the suffix of the module's path and if so retry ALL imports with that as the "current directory". For simplicity's sake, this could be disallowed outside the initial module.

It should be noted that this is not a language issue but a compiler issue.

I'm reopening this as an Enhancement because it seem people (my self included) thing that the way it is designed could be improved


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1585





------- Comment #3 from wbaxter@gmail.com  2007-10-16 13:55 -------
The thread in question is here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58894

Don Clugston wrote:
"""
There's a more conservative case which is really annoying:

foo/bar.d
    module foo.bar;
    import foo.baz;
foo/baz.d
    module foo.baz;

If compiling from inside foo, it complains that it can't find foo/baz.d, even though it knows that module foo.bar is found at ../foo/bar.d

But if you have
import baz;
it will work, even though it is probably a bug. (why are foo.bar and baz at the
same level??)

In practice -- this means that when developing a library, you cannot run your tests from inside the same directory. So you always have to use a nasty -I hack.

IMHO: If the module aaa.bbb.ccc; is in file ccc.d in the current directory,
then any other files in the aaa.bbb package should also be searched for in the
current directory. But I don't think it should ever look deeper than the
current directory; as Kirk points out, it can lead to ambiguity.
"""
and later:

"""
Really, the problem is that the compiler is not consistent in its association
of modules with files.

Module names correspond to directories and files in import statements, but they do not correspond to anything when used in module statements. That's the issue. """

Jakob wrote:
"""
Well, i'm writing a tool which creates makefiles.

And if the compiler would analyze the module name to get the module root, it
would be much simpler for me :P
"""

It sounds like your needs would be served if you just had some tool that took a .d file as input and gave you a "-I../.." string as output.

That shouldn't be too hard to write as a standalone program if you don't mind letting some pathological cases slip through the cracks.

Or it could be added as another debug output of the -v compiler switch, to go with the list of imports printed out.    If it would spit out a line like "module foo.bar.baz" then that would be trivial to grep for and analyze with an external tool.


--