www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - RDMD on Windows

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Is anyone having success using RDMD on Windows? I keep getting back this kind
of nonsense:

.\widget.d(2): Error: module io from file acme\goodies\io.d conflicts with
another module io from file .\acme\goodies\io.d

The files are:

C:\test\main.d
C:\test\widget.d
C:\test\acme\goodies\io.d

main.d:
import widget;

void main()
{
}

widget.d:
public import acme.goodies.io;

void fun(int x)
{
}

io.d:
void fun(long n)
{
}

It almost looks like it's trying to parse the file twice for some reason. The
source is available, which is cool, so I might take a look. Is anyone else
having this kind of error?
Aug 21 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:i4p4tn$2sd9$1 digitalmars.com...
 Is anyone having success using RDMD on Windows? I keep getting back this 
 kind of nonsense:

 .\widget.d(2): Error: module io from file acme\goodies\io.d conflicts with 
 another module io from file .\acme\goodies\io.d

 The files are:

 C:\test\main.d
 C:\test\widget.d
 C:\test\acme\goodies\io.d

 main.d:
 import widget;

 void main()
 {
 }

 widget.d:
 public import acme.goodies.io;

 void fun(int x)
 {
 }

 io.d:
 void fun(long n)
 {
 }

 It almost looks like it's trying to parse the file twice for some reason. 
 The source is available, which is cool, so I might take a look. Is anyone 
 else having this kind of error?

I've recently been using rdmd a lot of Windows. I didn't have that particular issue, but I have had other issues: One is already fixed in trunk, and others I've made patches for (I'll get to that further below). First of all, which version of RDMD are you using? The one that comes pre-packaged with DMD, (ie, rdmd 20090902)? Or one of the versions in Phobos trunk (r1315, or r1400)? Secondly, what is the *exact* command are you using to try to build with RDMD? If you're not building from the exact directory that has the file with main(), then the RDMD currently packaged with DMD won't work, you'll need to use the latest one from trunk: http://www.dsource.org/projects/phobos/browser/trunk/tools/rdmd.d?rev=1400 Download that, and either: A. Compile it with "dmd rdmd.d" and copy the exe to dmd/windows/bin, or B. Just use "rdmd rdmd.d {your app}" instead of "rdmd {your app}". If that doesn't work, then try the "rdmdAlt.d" that I've attached. It's just like r1400, but with these patches applied: http://d.puremagic.com/issues/show_bug.cgi?id=4674 http://d.puremagic.com/issues/show_bug.cgi?id=4683 http://d.puremagic.com/issues/show_bug.cgi?id=4684 http://d.puremagic.com/issues/show_bug.cgi?id=4688 (It also adds a "-o+" option I was playing with, but that's kinda useless since rdmd doesn't do incremental compilation, so just ignore that option.) If that rdmdAlt.d still doesn't work, let me know the exact command-line command you're using, and what version of DMD you're using. (BTW, RDMD does parse the files twice: It calls DMD once to find out all the dependencies, and then again to actually compile all of the files.)
Aug 21 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Thanks for all the help, Nick. But I don't see your attachment. I can't see it
with the web-news reader, and on gmane there's garbled text at the end,
something like "begin 666 rdmdAlt.d M+R\ 5W)I='1E;B!I;B!T:&41"!.."

Do you have a link to the file instead? That would be great.

And yes, I was already using the latest svn version which I've built (but it's
dated 8 months ago, it's not very fresh?). The command was "rdmd main.d". And I
was building from the same directory as the main.d file.

Nick Sabalausky Wrote:

 snip

Aug 21 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:i4pgdp$1ba3$1 digitalmars.com...
 Thanks for all the help, Nick. But I don't see your attachment. I can't 
 see it with the web-news reader, and on gmane there's garbled text at the 
 end, something like "begin 666 rdmdAlt.d M+R\ 5W)I='1E;B!I;B!T:&41"!.."

 Do you have a link to the file instead? That would be great.

 And yes, I was already using the latest svn version which I've built (but 
 it's dated 8 months ago, it's not very fresh?). The command was "rdmd 
 main.d". And I was building from the same directory as the main.d file.

Weird, maybe it's my NG client. You can get it here: http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d However, I don't think it's an rdmd issue at all, because this gives me almost the exact same error (DMD 2.048 here):
 dmd main.d widget.d acme\goodies\io.d

another module io from file acme\goodies\io.d ...I know I've come cross that somewhere before, either in my own code, or on bugzilla, or the NG, or something...can't remember though...
Aug 21 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Man, I have no idea what's going on. I was trying out building with xfbuild,
and I keep getting different results on each attempted build:

Attempt 1:
C:\next>xfbuild myproject.d myfolder\another.d +full +o=main
Build failed: myfolder/another.obj: The system cannot find the file specified.

Attempt 2:
C:\next>xfbuild myproject.d myfolder\another.d +full +o=main
Error: Error writing file 'myfolder\another.obj'

2010-08-22 00:29:36,025 Info [root] - Build failed: 'dmd  xfbuild.a27c00.rsp'
returned 1
.

abnormal program termination

Attempt 3:
C:\next>xfbuild myproject.d myfolder\another.d +full +o=main
2010-08-22 00:29:37,240 Info [root] - Build failed: myfolder/another.obj: The
process ca
nnot access the file because it is being used by another process.

abnormal program termination

Attempt 4:
C:\next>xfbuild myproject.d myfolder\another.d +full +o=main
Error: Error writing file 'myfolder\another.obj'

2010-08-22 00:29:38,214 Info [root] - Build failed: 'dmd  xfbuild.a27a00.rsp'
returned 1
.

abnormal program termination

Attempt 5, *now* it works:
C:\next>xfbuild myproject.d myfolder\another.d +full +o=main

Attempt 6:
C:\next>xfbuild myproject.d myfolder\another.d +full +o=main
OPTLINK (R) for Win32  Release 8.00.2
Copyright (C) Digital Mars 1989-2009  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
.objs\another.obj
 Error 2: File Not Found .objs\another.obj
--- errorlevel 1
xfbuild.Process.ProcessExecutionException: 'dmd  xfbuild.a00e00.rsp' returned 1.
----------------
[  42fab0]       0+0   tango.core.tools.WinStackTrace.winAddrBacktrace         
                         0+127388 :0
[  42902c]       0+0   tango.core.tools.StackTrace.defaultAddrBacktrace        
                         0+100120 :0
[  42909d]       0+0   tango.core.tools.StackTrace.basicTracer                 
                         0+100233 :0
[  4097ce]       0+0   xfbuild.Process.ProcessExecutionException._ctor         
                         0+11 Process.d:32
[  409ade]       0+0   xfbuild.Process.executeAndCheckFail                     
                         0+52 Process.d:138
[  409d65]       0+0   xfbuild.Process.executeCompilerViaResponseFile          
                         0+62 Process.d:180
[  40e925]       0+0   xfbuild.Linker.link                                     
                         0+5 Linker.d:70
[  409fec]       0+0   xfbuild.BuildTask.BuildTask.link                        
                         0+13 BuildTask.d:80
[  409f94]       0+0   xfbuild.BuildTask.BuildTask.execute                     
                         0+13 BuildTask.d:60
[  402d56]       0+0   __Dmain                                                 
                         0+8 Main.d:326
[  4149ad]       0+0   rt.compiler.dmd.rt.dmain2.main.runMain                  
                         0+16537 :0
[  414903]       0+0   rt.compiler.dmd.rt.dmain2.main.tryExec                  
                         0+16367 :0
[  4149eb]       0+0   rt.compiler.dmd.rt.dmain2.main.runAll                   
                         0+16599 :0
[  414903]       0+0   rt.compiler.dmd.rt.dmain2.main.tryExec                  
                         0+16367 :0
[  4148bb]       0+0   _main                                                   
                         0+16295 :0
[  43294c]       0+0   _mainCRTStartup                                         
                         0+139320 :0
[7c817074]       0+0   ???                                                     
                            0+2084595552 :0


Geeeeeeeeeeeeeeez.. What am I supposed to use to compile the files? DSSS
doesn't work, xfbuild seems broken most of the time, and I can't even use DMD
with a simple directory structure like this:

root\myproject.d
root\myfolder\another.d

myproject.d:
module myproject;

import myfolder.another;

void main()
{
}


another.d:
module another;

void fun(long n)
{
}

C:\test>dmd -ofmain.exe myproject.d myfolder\another.d
myproject.d(3): Error: module another from file myfolder\another.d conflicts
with another module another from file myfolder\another.d

I'll do a reinstall of DMD, maybe my system is broken or something.

Nick Sabalausky Wrote:

 

Aug 21 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:i4pkg0$2a5h$1 digitalmars.com...
 Man, I have no idea what's going on. I was trying out building with 
 xfbuild, and I keep getting different results on each attempted build:

 Geeeeeeeeeeeeeeez.. What am I supposed to use to compile the files? DSSS 
 doesn't work, xfbuild seems broken most of the time,

If passing the files directly to DMD doesn't work, then none of the front-ends to DMD are going to work either. Regarding xfbuild, yea, I've also noticed occasional "works differently on different runs" issues to. Kind of annoying, but anytime that happens, I clean out all the "obj"s and all of xfbuild's temp files, and do a fresh "xfbuild". Whatever happens on that run I consider "xfbuild's 'normal' behavior", and then anything that happens differently on the next run I just assume is an xfbuild bug.
 and I can't even use DMD with a simple directory structure like this:

 root\myproject.d
 root\myfolder\another.d

 myproject.d:
 module myproject;

 import myfolder.another;

 void main()
 {
 }


 another.d:
 module another;

 void fun(long n)
 {
 }

 C:\test>dmd -ofmain.exe myproject.d myfolder\another.d
 myproject.d(3): Error: module another from file myfolder\another.d 
 conflicts with another module another from file myfolder\another.d

I get the same result, but that's because that code is wrong: Your "myproject.d" is trying to import a module named "myfolder.another", but you're setting "another.d"'s module to be "another". They both need to match (D packages/modules are absolute, not relative). So either change them both to "myfolder.another" (or change them both to just "another", but that's less recomended since you'd be splitting a package across different directories). Then it'll work. Come to think of it...that might be your original problem... In your "acme\goodies\io.d", you're not setting the module name. I'd bet that DMD is assuming it to be just simply "io". And in main.d you're trying to import a "acme.goodies.io", so they don't match. It's a good idea to always include a "module" statement in every file for any multi-module project. Try adding "module acme.goodies.io;" to your "io.d". That should fix the problem. Doing that works for me on both dmd and rdmd. Or, if "io.d" is from some third party library, and you don't want to go changing it's internals, then do this: 1. In "main.d", change "import acme.goodies.io;" to "import io;" 2. Add "-Iacme\goodies" to the command-line. This tells DMD to consider "acme\goodies" to be one of the places (along with "." and "{path to phobos}") it sees as the "root" of the package hierarchy. Note that "-I" doesn't work with the RDMD currently in trunk, but it's fixed in my rdmdAlt.d: http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d
Aug 21 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Doh! I swear I've read somewhere that a module declaration needs to have the
same name as the *file name*. I didn't know I had to add the path as well. That
makes the modules work now.

In fact, I probably just read this one line in the docs:

"The ModuleDeclaration sets the name of the module and what package it belongs
to. *If absent, the module name is taken to be the same name (stripped of path
and extension) of the source file name.*"

But I didn't pay attention to the package stuff.

Thanks Nick for the help, I was going slightly mad there for a second. :p


Nick Sabalausky Wrote:

 snip

Aug 21 2010
parent reply Rory Mcguire <rjmcguire gm_no_ail.com> writes:
Andrej Mitrovic wrote:

 Doh! I swear I've read somewhere that a module declaration needs to have
 the same name as the *file name*. I didn't know I had to add the path as
 well. That makes the modules work now.
 
 In fact, I probably just read this one line in the docs:
 
 "The ModuleDeclaration sets the name of the module and what package it
 belongs to. *If absent, the module name is taken to be the same name
 (stripped of path and extension) of the source file name.*"
 
 But I didn't pay attention to the package stuff.
 
 Thanks Nick for the help, I was going slightly mad there for a second. :p
 
 
 Nick Sabalausky Wrote:
 
 snip


In Java yes. I D you can use the module declaration to "move" a module. e.g. filename: socket.d; module: alt.socket; to import you'd do "import alt.socket;" even if the file is in the same directory as the module using the file.
Aug 22 2010
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
That's very interesting. 

But wouldn't that cause problems if you're using package labels in some of
those modules? AFAIK package gives access to all files in the current
directory, so even if you "move" a module by changing the module declaration,
the files in the current directory will still have access to it, right?

If that's true, I'm thinking this could potentially cause problems (if you're
moving modules by changing their declaration instead of physically moving them).

Rory Mcguire Wrote:

  I D you can use the module declaration to "move" a module.
 e.g.
 filename: socket.d;
 module: alt.socket;
 
 to import you'd do "import alt.socket;" even if the file is in the same
 directory as the module using the file.

Aug 22 2010
parent Mafi <mafi example.org> writes:
Am 22.08.2010 16:39, schrieb Andrej Mitrovic:
 That's very interesting.

 But wouldn't that cause problems if you're using package labels in some of
those modules? AFAIK package gives access to all files in the current
directory, so even if you "move" a module by changing the module declaration,
the files in the current directory will still have access to it, right?

 If that's true, I'm thinking this could potentially cause problems (if you're
moving modules by changing their declaration instead of physically moving them).

be in the same package, ie module declarations are eqivalent before the *last* dot. If it's not like that, then package should be called 'directory'.
Aug 22 2010
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well then I think I've found some new bugs in RDMD & xfbuild:

Files:
root/main.d
root/socket.d

main.d:
module main;

import alt.socket;

void main()
{
    foo();
}

socket.d:
module alt.socket;

import std.stdio : writeln;

void foo()
{
    writeln("test");
}

$ RDMD main.d

main.d(2): Error: module socket is in file 'alt\socket.d' which cannot be read
import path[0] = .
import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
import path[2] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import


$ xfbuild +o=main.exe main.d socket.d

main.d(4): Error: module socket is in file 'alt\socket.d' which cannot be read
import path[0] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import
Build failed: 'dmd  xfbuild.a00e00.rsp' returned 1.

DSSS fails as well.

But DMD works:

$ dmd main.d socket.d
$ main.exe
 test

Rory Mcguire Wrote:
 In Java yes. I D you can use the module declaration to "move" a module.
 e.g.
 filename: socket.d;
 module: alt.socket;
 
 to import you'd do "import alt.socket;" even if the file is in the same
 directory as the module using the file.

Aug 22 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:i4rnl4$2396$1 digitalmars.com...
 Well then I think I've found some new bugs in RDMD & xfbuild:

 Files:
 root/main.d
 root/socket.d

 main.d:
 module main;

 import alt.socket;

 void main()
 {
    foo();
 }

 socket.d:
 module alt.socket;

 import std.stdio : writeln;

 void foo()
 {
    writeln("test");
 }

 $ RDMD main.d

 main.d(2): Error: module socket is in file 'alt\socket.d' which cannot be 
 read
 import path[0] = .
 import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
 import path[2] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import


 $ xfbuild +o=main.exe main.d socket.d

 main.d(4): Error: module socket is in file 'alt\socket.d' which cannot be 
 read
 import path[0] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
 import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import
 Build failed: 'dmd  xfbuild.a00e00.rsp' returned 1.

 DSSS fails as well.

 But DMD works:

 $ dmd main.d socket.d
 $ main.exe
 test


Hmm, yea that's not going to work with those tools. The whole point of those tools is that you can give them the file with main(), and then they'll figure out all the files that need to be passed to DMD. The only way they can realistically do that is by assuming package names are directory names and module names are file names. Since your "socket.d" is in a package named "alt", but *not* in a directory called "alt", those tools have absolutely no way to find "socket.d". If you just run DMD directly, then there's no need to programmatically find "socket.d", since you've already said where to find it. There's only two ways for those tools to find a file if it's in a directory named *differently* than the package name (or to find a file with a different name from the module name) without venturing into fuzzy guesswork-territory: 1. Search the whole filesystem (obviously ain't gonna happen, and really, this is fuzzy guesswork-territory anyway). 2. Have an option so you can tell it "assume that directory '{someDir}' is a possible location for package '{some.package}' " (Ie, kinda like "-I", but for packages other than just "package root"). This could be done, but frankly I see little, if any, use for that kind of flexibility other than obfuscation, so this is not likely to happen either. What you *can* do, is put "socket.d" in a directory named "alt", and then put directoy "alt" **anywhere** in the filesystem you want, and then pass in "-I{directoryThatContaininsAlt}". *That* should work (Although that *is* currently broken in RDMD, which gave me some trouble the other day, but I filed a patch for it here: http://d.puremagic.com/issues/show_bug.cgi?id=4672 )
Aug 22 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I see.

Well, honestly, I would never use this flexibility to begin with. I'm not
seeing much benefits in having modules named in one way while keeping them
disorganized and in completely different folders. That just causes confusion,
for both the programmer and the build tools.

Personally, I'll try to keep it simple here and name the modules and packages
exactly like the directories they're in. 

Nick Sabalausky Wrote:

 

Aug 22 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Well, honestly, I would never use this flexibility to begin with. I'm not
seeing much benefits in having modules named in one way while keeping them
disorganized and in completely different folders. That just causes confusion,
for both the programmer and the build tools.
 
 Personally, I'll try to keep it simple here and name the modules and packages
exactly like the directories they're in. 

You may vote this: http://d.puremagic.com/issues/show_bug.cgi?id=3972 But Walter wants that flexibility. And everyone has to pay a cost for that flexibility. Bye, bearophile
Aug 22 2010