Output is
rdmd.d(197): Error: function std.path.rel2abs!().rel2abs is deprecated
/usr/include/d/std/algorithm.d(4226): Error: template std.algorithm.endsWith does not match any function template declaration
/usr/include/d/std/algorithm.d(4226): Error: template std.algorithm.endsWith cannot deduce template function from argument types !("a == b")(string,string,string,string,string)
/usr/include/d/std/algorithm.d(4226): Error: template instance endsWith!("a == b") errors instantiating template
/usr/include/d/std/algorithm.d(4226): Error: template std.algorithm.endsWith does not match any function template declaration
/usr/include/d/std/algorithm.d(4226): Error: template std.algorithm.endsWith cannot deduce template function from argument types !("a == b")(string,string,string,string,string)
Comment #1 by bugzilla — 2012-04-13T21:52:53Z
I use -d to compile it.
Comment #2 by thelastmammoth — 2012-05-31T02:09:44Z
(In reply to comment #1)
> I use -d to compile it.
Alternatively someone needs to change the rdmd.d source file in the git as follows. It worked for me.
// exe = buildPath(myOwnTmpDir, rel2abs(root)[1 .. $])
// ~ '.' ~ hash(root, compilerFlags) ~ binExt;
exe = buildPath(myOwnTmpDir, absolutePath(root)[1 .. $])
~ '.' ~ hash(root, compilerFlags) ~ binExt;
Also, wouldn't it be simpler if the build process could be automated with say a single makefile? right now the user needs to go in each of dmd,druntime,pbobos, and in tools there's only a windows makefile.
Here I changed win32.mak to a Makefile that works on osx (and probably linux), but it should also be completed to build rdmd, ddemangle.d etc, which are nice tools to have.
Other annoyances: the update.sh has some weird behavior with git (and doesn't do all that), the packaging installs the version from dlang website instead of the version in git, and MODEL should be 64 by default on OSX instead of 32 for each of the dmd,druntime,pbobos.
********** Makefile (does same as win32.mak but for osx, and maybe linux)
DMD=dmd
DOC=../d-programming-language.org/web/
TARGETS=dman findtags
TAGS= expression.tag \
statement.tag
targets : $(TARGETS)
expression.tag : findtags $(DOC)/expression.html
./findtags $(DOC)/expression.html >expression.tag
statement.tag : findtags $(DOC)/statement.html
./findtags $(DOC)/statement.html >statement.tag
findtags : findtags.d
$(DMD) findtags.d
dman : dman.d $(TAGS)
$(DMD) dman.d -J.
clean :
rm $(TARGETS) $(TAGS)
Comment #3 by thelastmammoth — 2012-06-02T02:23:01Z
Actually there seems to be a bug in the tools/update.sh provided which is supposed to download and build all:
From git://github.com/D-Programming-Language/tools
* branch master -> FETCH_HEAD
fatal: 'upstream' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
I checked the error logs, the cause is the call to :
git pull upstream master inside tools/update.sh
For the other directories, it works fine.
This stops the build. So I had to modify the update.sh script.
************
While I'm at it it seems that rdmd hard-wires dmd.conf to /usr/bin/dmd.conf as opposed to what says in the docs (dmd.conf should be able to be in a number of locations )
Comment #4 by dlang-bugzilla — 2013-03-10T01:12:37Z
The specific compilation issue reported here has since been resolved.
(In reply to comment #3)
> Actually there seems to be a bug in the tools/update.sh provided which is
> supposed to download and build all:
>
> From git://github.com/D-Programming-Language/tools
> * branch master -> FETCH_HEAD
> fatal: 'upstream' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
>
> I checked the error logs, the cause is the call to :
> git pull upstream master inside tools/update.sh
> For the other directories, it works fine.
Have you tried running the script from a directory with an existing git clone? The remote name needs to be called "upstream", which is what the script uses when setting up the repositories.
The script works for me.
> While I'm at it it seems that rdmd hard-wires dmd.conf to /usr/bin/dmd.conf as
> opposed to what says in the docs (dmd.conf should be able to be in a number of
> locations )
Not sure if this is specific to old rdmd versions, but rdmd does not consult any specific location for dmd.conf. It uses the output of dmd -v ("config" line) to find the location of the compiler configuration, solely to consider it as a rebuild dependency.