I never have. Typical results:

$ gnumake -I c:/sandbox/druntime/import
Building d_do_test tool
object.d: Error: module object is in file 'object.d' which cannot be read
Specify path to file 'object.d' with -I switch
gnumake: *** [test_results/d_do_test] Error 1

 On my system, the command to compile foo.d with dmd, is "dmd foo.d".
It really takes creativity to get a failure like the one above.
Why on earth does the makefile have hard coded paths all through it?
It seems to assume a hardcoded relationship between all of the source
directories.
Any use of ".." is suspect.
This is the ONE AND ONLY D program that I have never been able to compile.
I suspect Walter has never been able to get it to work, either.

On 3/5/2011 12:52 AM, Don Clugston wrote:
> I never have. Typical results:
> 
> $ gnumake -I c:/sandbox/druntime/import
> Building d_do_test tool
> object.d: Error: module object is in file 'object.d' which cannot be read
> Specify path to file 'object.d' with -I switch
> gnumake: *** [test_results/d_do_test] Error 1
> 
>  On my system, the command to compile foo.d with dmd, is "dmd foo.d".
> It really takes creativity to get a failure like the one above.
> Why on earth does the makefile have hard coded paths all through it?
> It seems to assume a hardcoded relationship between all of the source
> directories.
> Any use of ".." is suspect.
> This is the ONE AND ONLY D program that I have never been able to compile.
> I suspect Walter has never been able to get it to work, either.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

I don't understand your objection to having the test dir assume that the built dmd is in ../src/dmd, as, well, that's exactly where the produced binary from the build process lives.

I suspect the primary issue is that I always have either an sc.ini or dmd.conf file in .../dmd/src/ that 'just works'.
$ more src/sc.ini
[Version]
version=7.51 Build 020

[Environment] LIB="%@P%\..\..\phobos";c:\home\braddr\sandbox\d\dmc\dm\lib DFLAGS="-I%@P%\..\..\phobos" "-I%@P%\..\..\druntime\import" LINKCMD=c:\cygwin\home\braddr\sandbox\d\dmc\dm\bin\link.exe

Obviously the two dmc related paths are specific to my system, but having ..'s in paths for dmd setups is par for the course.. always has been.

For more on how I use dmd on windows, you can look at the auto-tester scripts:

  https://github.com/braddr/d-tester/client/src

Also, -I as an arg to make doesn't get passed to any sub apps, specifically not dmd.  It only tells make where to look for included make files.. which isn't used by any of our make files, definitely not the dmd/test/Makefile.

I hope that helps.

Later,
Brad

On 5 March 2011 10:12, Brad Roberts <braddr at puremagic.com> wrote:
> On 3/5/2011 12:52 AM, Don Clugston wrote:
>> I never have. Typical results:
>>
>> $ gnumake -I c:/sandbox/druntime/import
>> Building d_do_test tool
>> object.d: Error: module object is in file 'object.d' which cannot be read
>> Specify path to file 'object.d' with -I switch
>> gnumake: *** [test_results/d_do_test] Error 1
>>
>> ?On my system, the command to compile foo.d with dmd, is "dmd foo.d".
>> It really takes creativity to get a failure like the one above.
>> Why on earth does the makefile have hard coded paths all through it?
>> It seems to assume a hardcoded relationship between all of the source
>> directories.
>> Any use of ".." is suspect.
>> This is the ONE AND ONLY D program that I have never been able to compile.
>> I suspect Walter has never been able to get it to work, either.
>> _______________________________________________
>
> I don't understand your objection to having the test dir assume that the built dmd is in ../src/dmd, as, well, that's exactly where the produced binary from the build process lives.

I have viewed that only as a build directory. DMD is one component of
a multi-component build.
I always copy it to its correct location in dmd/windows/bin after a
successful build. Dead simple.

> I suspect the primary issue is that I always have either an sc.ini or dmd.conf file in .../dmd/src/ that 'just works'.

I think that is impossible. I suspect you're not doing much building of D1.

On 3/5/2011 8:17 AM, Don Clugston wrote:
> On 5 March 2011 10:12, Brad Roberts <braddr at puremagic.com> wrote:
>> On 3/5/2011 12:52 AM, Don Clugston wrote:
>>> I never have. Typical results:
>>>
>>> $ gnumake -I c:/sandbox/druntime/import
>>> Building d_do_test tool
>>> object.d: Error: module object is in file 'object.d' which cannot be read
>>> Specify path to file 'object.d' with -I switch
>>> gnumake: *** [test_results/d_do_test] Error 1
>>>
>>>  On my system, the command to compile foo.d with dmd, is "dmd foo.d".
>>> It really takes creativity to get a failure like the one above.
>>> Why on earth does the makefile have hard coded paths all through it?
>>> It seems to assume a hardcoded relationship between all of the source
>>> directories.
>>> Any use of ".." is suspect.
>>> This is the ONE AND ONLY D program that I have never been able to compile.
>>> I suspect Walter has never been able to get it to work, either.
>>> _______________________________________________
>>
>> I don't understand your objection to having the test dir assume that the built dmd is in ../src/dmd, as, well, that's exactly where the produced binary from the build process lives.
> 
> I have viewed that only as a build directory. DMD is one component of
> a multi-component build.
> I always copy it to its correct location in dmd/windows/bin after a
> successful build. Dead simple.
> 
>> I suspect the primary issue is that I always have either an sc.ini or dmd.conf file in .../dmd/src/ that 'just works'.
> 
> I think that is impossible. I suspect you're not doing much building of D1.

I hardly ever touch d1 (though I've been considering adding it to the auto-tester), but I strongly suspect that it wouldn't be a big problem either.  Regardless, for D2, the only version that has the public test suite, it _does_ just work.  Nothing even remotely impossible about it.

Anyway, if you'd like to suggest some specific changes (preferably via patches), I'm certainly willing to discuss changes.  But the bottom line is that it really does work, and quite well, on all platforms.  The problems I had on windows weren't path related, they were path separator related.  Those were resolved a long time ago.  I'm really eager for it to work well for others, so please help me improve it so that you're happy with it too.

Later,
Brad