http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #10 from andrei@metalanguage.com  2008-06-23 10:10 -------
(In reply to comment #9)
> PS: Reason for that change is: If you use dmd, it will call the system dmd, not the new one. This can cause issues or confusion.
> 

I don't understand why there have to be two dmd programs. What is "the new dmd"?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #11 from lindevel@gmx.net  2008-06-23 10:55 -------
If you have dmd installed on your system, you have one dmd executable in your
system path.
If you compile dmd, you have a second dmd executable in the sourcecode
directory.
To fetch the correct one you need to specify the path to one of them.
Since you want to compile and install a new version of dmd, you probably want
the executable in the sourcecode directory. Thus you need to set DMD to the
path to that one, and not to the system binary.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #12 from andrei@metalanguage.com  2008-06-23 11:19 -------
(In reply to comment #11)
> If you have dmd installed on your system, you have one dmd executable in your
> system path.
> If you compile dmd, you have a second dmd executable in the sourcecode
> directory.
> To fetch the correct one you need to specify the path to one of them.
> Since you want to compile and install a new version of dmd, you probably want
> the executable in the sourcecode directory. Thus you need to set DMD to the
> path to that one, and not to the system binary.
> 

I see. But these makefiles do not build dmd. They build phobos. So I'd suggest we opt for using "dmd" by default and a user-specified dmd in the command line.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #13 from lindevel@gmx.net  2008-06-23 11:55 -------
True.

The issue I had was just that dmd 2.014 creates broken headers, which made the resulting package unusable. dmd 2.015 creates not so broken headers, which is why I prefer to use the bundled dmd instead of the system dmd.

If you would ship libphobos seperately from dmd, replacing the system dmd first, and then building libphobos with that one would have been my idea, too.

I do not know what your policy to adding features and backwards compatibility is, but I would assume that it might be possible that the old system dmd does not understand the syntax or keywords used for the new to-be-compiled libphobos.

I guess this is a matter of what to make the sane default.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #14 from andrei@metalanguage.com  2008-06-23 12:18 -------
(In reply to comment #13)
> True.
> 
> The issue I had was just that dmd 2.014 creates broken headers, which made the resulting package unusable. dmd 2.015 creates not so broken headers, which is why I prefer to use the bundled dmd instead of the system dmd.
> 
> If you would ship libphobos seperately

Gaaaa! (I have a hysteria fit whenever I see "seperate" and its derivees.)

> from dmd, replacing the system dmd
> first, and then building libphobos with that one would have been my idea, too.
> 
> I do not know what your policy to adding features and backwards compatibility is, but I would assume that it might be possible that the old system dmd does not understand the syntax or keywords used for the new to-be-compiled libphobos.
> 
> I guess this is a matter of what to make the sane default.

I think it's fair to use whatever is in your PATH by default and allow you to specify DMD=/path/to/dmd in make's command line. I'll operate these changes and will commit for next release.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #15 from lindevel@gmx.net  2008-06-23 12:27 -------
Thanks!

When you are at it, you could also take a look at http://d.puremagic.com/issues/show_bug.cgi?id=2164

How did you solve the x86_64 issue now? Via the CC="gcc -m32" hack?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940


andrei@metalanguage.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com




------- Comment #16 from andrei@metalanguage.com  2008-06-23 12:33 -------
(In reply to comment #15)
> Thanks!
> 
> When you are at it, you could also take a look at http://d.puremagic.com/issues/show_bug.cgi?id=2164

I'm not clear on a few things about that, which I'll ask about there.

> How did you solve the x86_64 issue now? Via the CC="gcc -m32" hack?

I think it's better to put -m32 in CFLAGS, so I took that route.

Thanks for the fix!


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #17 from lindevel@gmx.net  2008-06-23 13:04 -------
So you pass through the CFLAGS from the env of dmd to the env of CC? Just asking because I tried to set CFLAGS before, without getting the desired effect.

(Or am I just wrong when I think that dmd calls CC internaly?)


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #18 from andrei@metalanguage.com  2008-06-23 13:33 -------
(In reply to comment #17)
> So you pass through the CFLAGS from the env of dmd to the env of CC? Just asking because I tried to set CFLAGS before, without getting the desired effect.
> 
> (Or am I just wrong when I think that dmd calls CC internaly?)

First off, there are C modules in phobos, and for those of course CC and CFLAGS will apply. Then CC is also invoked for linking. That's about it.

For linking I have added the conventional LDFLAGS variable, which right now is the concatenation of the homonym environment variable and "-m32" (is that needed?) I also fixed CFLAGS to pick up the environment variable. (The trick is to use ":=" when concatenating, not "=".)


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #19 from lindevel@gmx.net  2008-06-23 13:56 -------
Thanks! :)

-m32 for linking is needed, yes.
Though i.e. autotools and other buildsystems pass CFLAGS to CC during linking
as well. So you will have to (and should) call CC with both CFLAGS and LDFLAGS
anyway.
So you should rather prepend -m32 just to CFLAGS.
Prepend instead of append, because CrazyUser might want to override that (maybe
while trying to add x86_64 support to dmd or whatever).


--