www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1585] New: Imports should be searched relative to importing file

reply d-bugmail puremagic.com writes:

           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:

        module a;
        import b;

        module b;

Example 2:

        module foo.a;
        import bar.b;

        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

Oct 16 2007
next sibling parent d-bugmail puremagic.com writes:

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.

Oct 16 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:

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

Oct 16 2007
prev sibling parent d-bugmail puremagic.com writes:

------- Comment #3 from wbaxter gmail.com  2007-10-16 13:55 -------
The thread in question is here:

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

    module foo.bar;
    import foo.baz;
    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

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.

Oct 16 2007