digitalmars.D.bugs - [Issue 1585] New: Imports should be searched relative to importing file
- d-bugmail puremagic.com (35/35) Oct 16 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1585
- d-bugmail puremagic.com (12/12) Oct 16 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1585
- d-bugmail puremagic.com (19/19) Oct 16 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1585
- d-bugmail puremagic.com (48/48) Oct 16 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1585
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. --
Oct 16 2007
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 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
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 | 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
http://d.puremagic.com/issues/show_bug.cgi?id=1585 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. --
Oct 16 2007