module tunah.a;
import tunah.b;

DMD will look for ./tunah/b.d, rather than ./b.d

Sam

"Sam McCall" <tunah.d@tunah.net> wrote in message news:ccbd38$1lla$1@digitaldaemon.com...
> module tunah.a;
> import tunah.b;
>
> DMD will look for ./tunah/b.d, rather than ./b.d

That's the way it's designed to work, imports always work off the current directory, unless you specify a different one with the -I switch.

Walter wrote:

> "Sam McCall" <tunah.d@tunah.net> wrote in message
> news:ccbd38$1lla$1@digitaldaemon.com...
> 
>> module tunah.a;
>> import tunah.b;
>>
>> DMD will look for ./tunah/b.d, rather than ./b.d
> 
> That's the way it's designed to work, imports always work off the current
> directory, unless you specify a different one with the -I switch.

Is there some hidden advantage to this?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/586

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <ccgeqh$428$1@digitaldaemon.com>, Stewart Gordon says...

>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/586

Gotcha. So if DMD encounters a line like:

#    module abc.def.ghi;

it should implicitly add -I../.. to the include path, on the assumption that that MUST be the module root or the module declaration couldn't possibly be correct.

Like it.

Of course, if DMD is working the way it's designed to work, this isn't a bug. What you're talking about here is a feature-request (and a good one, too). Maybe this should be talked about over on the main forum?

Arcane Jill

(inverted post for my convenience ;)
Arcane Jill wrote:
> Of course, if DMD is working the way it's designed to work, this isn't
> a bug. What you're talking about here is a feature-request (and a good
> one, too). Maybe this should be talked about over on the main forum?
Moved (hope i got the crosspost/followup-to right).
I posted it there when I was frustrated with various things, and annoyed that it didn't work in the obvious (to me) way.

> In article <ccgeqh$428$1@digitaldaemon.com>, Stewart Gordon says...
> 
> 
>>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/586
> 
> 
> Gotcha. So if DMD encounters a line like:
> 
> #    module abc.def.ghi;
> 
> it should implicitly add -I../.. to the include path, on the assumption that
> that MUST be the module root or the module declaration couldn't possibly be
> correct.
I'd prefer a slightly different behaviour: only traverse back up the tree as long as module names and directory names coincide.
For example, consider the file /path/tunah/package/foo.d
containing each of the following:

module foo;
import bar.baz; // look in /path/tunah/package/bar/baz.d,
		// then in phobos/src/bar/baz.d

module tunah.example.foo;
import tunah.bar.baz;
		// look in /path/tunah/bar/baz.d,
		// then in phobos/src/bar/baz.d

module contrib.tunah.example.foo;
import contrib.tunah.bar.baz;
		// look in /path/tunah/bar/baz.d,
		// then in phobos/src/bar/baz.d

Lastly, I think either
a) these behaviours should be independent of the current working directory you compile from; or
b) the current working directory should be searched in the same manner as phobos, before phobos but after module-specific imports.

(BTW when I say "phobos" I mean "all global imports", including those given by -I)

What are people's thoughts on this?
Walter, does this sound like something that'd be suitable if it was popular and someone wrote a non-intrusive, simple patch?
I'd be happy to try at some point, though someone else might be better.

Sam

"Sam McCall" <tunah.d@tunah.net> wrote in message news:ccivdo$ohq$1@digitaldaemon.com...
> Walter, does this sound like something that'd be suitable if it was popular and someone wrote a non-intrusive, simple patch?

I prefer the current, very simple, rule because it's easy to document and explain. Also, what one names the module with the module statement may have no relationship to its position in the directory tree, so I think it would be complicated and confusing to have the module statement change the behavior of the import statements.

you can use .def files to create a .lib that changes the name of the dll

for example:

http://svn.dsource.org/svn/projects/deliria/lib/opengl32.def

LIBRARY opengl32
DESCRIPTION "openGL"
EXETYPE NT
EXPORTS
_glAccum@8=glAccum
_glAlphaFunc@8=glAlphaFunc
_glBegin@4=glBegin
_glBitmap@28=glBitmap
_glBlendFunc@8=glBlendFunc
_glCallList@4=glCallList

in this way you could rename your intended function whatever you need it to be outside the scope of D

or write a C wrapper


Walter wrote:
> "Sam McCall" <tunah.d@tunah.net> wrote in message
> news:ccivdo$ohq$1@digitaldaemon.com...
> 
>>Walter, does this sound like something that'd be suitable if it was
>>popular and someone wrote a non-intrusive, simple patch?
> 
> 
> I prefer the current, very simple, rule because it's easy to document and
> explain. Also, what one names the module with the module statement may have
> no relationship to its position in the directory tree, so I think it would
> be complicated and confusing to have the module statement change the
> behavior of the import statements.
> 
> 

Walter wrote:
> "Sam McCall" <tunah.d@tunah.net> wrote in message news:ccivdo$ohq$1@digitaldaemon.com...
> 
>> Walter, does this sound like something that'd be suitable if it was popular and someone wrote a non-intrusive, simple patch?
> 
> I prefer the current, very simple, rule because it's easy to document and explain.

The rule we're suggesting looks perfectly simple and straightforward to me.

> Also, what one names the module with the module statement may have no relationship to its position in the directory tree,

What would be the point of doing that?  How would the compiler find the
module anyway if its name bears no resemblance to its address?

> so I think it would be complicated and confusing to have the module statement change the behavior of the import statements.

Maybe you've an illustration, but I can't see how it would be either complicated or confusing.

If one creates a file \code\qwert\yuiop\asdfg.d

module qwert.yuiop.asdfg;
import qwert.yuiop.hjkl;

I can't see it as likely that one created a module at \code\qwert\yuiop\qwert\yuiop\hjkl.d and wants to import that.  If that were so, this module would be just asdfg not qwert.yuiop.asdfg. Moreover, the compiler could easily discover that there is no such file, and hence discover that \code is the root of the hierarchy and \code\qwert\yuiop\hjkl.d is the file to be imported.

The syntactic salt of -I switches for this simple problem doesn't seem to be worth its weight.  Having the current module name speak for itself just seems the logical solution - why have this statement if you're just going to ignore it?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

In article <cdlecn$2h4m$1@digitaldaemon.com>, Stewart Gordon says...

>I can't see it as likely that one created a module at \code\qwert\yuiop\qwert\yuiop\hjkl.d and wants to import that.  If that were so, this module would be just asdfg not qwert.yuiop.asdfg. Moreover, the compiler could easily discover that there is no such file, and hence discover that \code is the root of the hierarchy and \code\qwert\yuiop\hjkl.d is the file to be imported.
>
>The syntactic salt of -I switches for this simple problem doesn't seem to be worth its weight.  Having the current module name speak for itself just seems the logical solution - why have this statement if you're just going to ignore it?

What you're suggesting makes perfect sense, and I'd tend to agree with you in principle - /but/ - I can see where Walter's coming from.

In a project which is large enough to need a directory /tree/ of modules, it is unlikely you'd be typing "DMD whatever" directly onto a command line. For a project of any appreciable size (and I'd define that as meaning "a project having more than one source file"), you're much /more/ likely to be using a build process. For most people, compiling a large project requires no syntactic salt at all - they just type "make". In my case (not being a great fan of make) I only have to click on a menu item in my text editor (TextPad). The only time I ever had to have direct experience of the DMD command line option "-I" when when I wrote my build script in the first place - but that was just a one-off job.

I'm not sure why anyone would want to use the DMD command-line syntax /manually/, except for single files (where module names are not an issue). If you are actually doing this for multi-file projects, you might consider automating the procedure with some sort of build script.

I'm not arguing against your idea. (Actually, I really like it, and I certainly wouldn't complain if it were implemented). It's just that, now that I /have/ automated the process, I'm unlikely ever to want to go back to doing things the hard way, so it's feature whose benefit I would never actually see.

Arcane Jill

Walter wrote:
> I prefer the current, very simple, rule because it's easy to document
> and explain.
That's certainly an advantage. I think a changed behaviour would provide a great enough benefit to offset this, in particular because it would still be fairly simple to document, and would need to be explained less often: the idea is it would do-what-you-mean.

> Also, what one names the module with the module statement
> may have no relationship to its position in the directory tree,
The proposed behaviour would only change the current behaviour when the module name _does_ match the directory tree.
/home/sam/foo.d == tunah.package.foo: same as current behaviour
/home/sam/package/foo.d == tunah.package.foo: tunah.bar.xyz imports look inside /home/sam/bar/xyz.

Arcane Jill wrote:
> In a project which is large enough to need a directory /tree/ of modules, it is
> unlikely you'd be typing "DMD whatever" directly onto a command line. For a
> project of any appreciable size (and I'd define that as meaning "a project
> having more than one source file"), you're much /more/ likely to be using a
> build process. For most people, compiling a large project requires no syntactic
> salt at all - they just type "make".
Yeah. But that's not a reason not to improve the way this works (I realise you realise this ;-).
I hate having to try to read the mess of includes in makefile-generated compile lines. 99% of the time you never have to - okay, maybe you *never* have to, I still like to know what's going on. And its one less thing that has to be set up right in the makefile.

> In my case (not being a great fan of make)
> I only have to click on a menu item in my text editor (TextPad). 
Do you use Java? If so, I'll bet you've noticed that the TextPad "compile" tool (executes "java $FileName" from $FileDir) works great... unless the source file is in a package. (Javac handles this similarly to D).
Build scripts are nice, not needing them is even nicer. I often keep my Java projects package-less while in development just for this reason.

> The only time I
> ever had to have direct experience of the DMD command line option "-I" when when
> I wrote my build script in the first place - but that was just a one-off job.
If it can be removed at low cost, then once (per project) is too many :)

But these are weak arguments about convenience, unlikely to convince Walter (and less likely to have any priority) so I'll leave it here.
Sam