• Karl Bochert (11/11) Jul 03 2006 Is there some reason why the syntax is
• Chris Nicholson-Sauls (14/29) Jul 03 2006 Except that I haven't touched a makefile in ages. Check out the Build u...
• BCS (5/20) Jul 03 2006 actually the better solution is to run DMD with its current directory
• Mike Parker (21/25) Jul 03 2006 It's not a work-around. It's the way the system is intended to work.

Karl Bochert <Karl_member pathlink.com> writes:

Is there some reason why the syntax is 
import std.c.stdio
Rather than 
import std\c\stdio

The dot syntax prevents the use of relative paths to modules ( I'm guessing -- I
haven't actually tried 'import ......foo;' )

Are relative paths considered bad for imports?
Is this just an unfortunate side-effect of a syntax that has other advantages?

I guess the work-around is to use the -I compiler switch which seems like a
terrible approach to me, moving information that should be in the source to the
makefile.

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Karl Bochert wrote:
 Is there some reason why the syntax is 
 import std.c.stdio
 Rather than 
 import std\c\stdio
 
 The dot syntax prevents the use of relative paths to modules ( I'm guessing --
I
 haven't actually tried 'import ......foo;' )
 
 Are relative paths considered bad for imports?
 Is this just an unfortunate side-effect of a syntax that has other advantages?
 
 I guess the work-around is to use the -I compiler switch which seems like a
 terrible approach to me, moving information that should be in the source to the
 makefile.
 

Except that I haven't touched a makefile in ages.  Check out the Build utility:
http://www.dsource.org/projects/build

All I usually ever run anymore is one of 'build  debug', 'build  doc', or
'build  release'.

As to the use of the dot in imports, the reason is simple: you are /not/
importing a path, 
but rather a module which may or may not belong to a package.  For example, so
I have a 
module 'array' in package 'utils'.  Say that I have package 'utils' stored with
some other 
code in the subdirectory 'lib'.  My module 'array' has declared itself 'module 
utils.array;' ... so I can only import it as 'import utils.array;'.  The
location of that 
package in the filesystem is meaningless to my program, only the relative
location of the 
modules within their packages (if any) has any meaning.  However, the compiler
needs to 
know where to look for packages and modules, so I need to pass '-Ilib' on the
command 
line, or in my Build Response File.

-- Chris Nicholson-Sauls

BCS <BCS pathlink.com> writes:

Karl Bochert wrote:
 Is there some reason why the syntax is 
 import std.c.stdio
 Rather than 
 import std\c\stdio
 
 The dot syntax prevents the use of relative paths to modules ( I'm guessing --
I
 haven't actually tried 'import ......foo;' )
 
 Are relative paths considered bad for imports?
 Is this just an unfortunate side-effect of a syntax that has other advantages?
 
 I guess the work-around is to use the -I compiler switch which seems like a
 terrible approach to me, moving information that should be in the source to the
 makefile.
 

actually the better solution is to run DMD with its current directory 
set to the root. If that is more than one location, in all likelihood, 
all but one of the roots are librarys and thus should be pointed to by 
-I anyway

Mike Parker <aldacron71 yahoo.com> writes:

Karl Bochert wrote:
ges?
 
 I guess the work-around is to use the -I compiler switch which seems like a
 terrible approach to me, moving information that should be in the source to the
 makefile.

It's not a work-around. It's the way the system is intended to work. 
This is more flexible than hard coding relative paths in your code. You 
are telling the compiler to look for a module which resides in a 
'package' on the import path. Don't think of it as a directory tree.

mypackage.mymodule means that 'mymodule' belongs to a package named 
'mypackage'. The fact that the compiler looks for a directory named 
'mypackage' and a file named 'mymodule' are a consequence of the file 
system.

I have three common import locations on my system: the default location 
that DMD defines in sc.ini (it is where phobos resides); a common 
directory where I have all third-party packates that I use 
(C:\dev\D\import is what I've called it); in every project I start I 
keep all of the source in 'src' directory with subdirs matching package 
names. When compiling, I pass -IC:\dev\D\import and -Isrc to the 
compiler (these options are set in a Build response file since I use 
Build and not DMD directly).

I assume you come from a C or C++ background. You're in D land now. 
import statements are not the same as #include directives. Realizing 
that will help you to understand the difference.