The unit tests on Linux maintain the module hierarchy when they're compiled. For example, on 64-bit Linux, std.net.isemail's unit test object file and binary go in generated/linux/debug/64/unittest/std/net/. However, on Windows, they all go in the unittest folder.

That doesn't support having both debug and release builds. It doesn't support architecture (though we don't have to deal with anything other than 32-bit on Windows just yet). And most importantly for what I'm dealing with at the moment, it doesn't support having multiple sub-modules with the same name.

In my case, I'm working on splitting std.datetime into sub-modules in std.dtime, and it makes some sense to have a windows.d with some of the windows-specific functions in it. However, there is already a std/c/windows/windows.d. So, on Windows, they would both be trying to compile to the same place in spite of the fact that they're in completely different packages.

Would someone who's knowledgable enough about makefiles (and the Windows makefile in particular) be able and willing to fix win32.mak so that the unit tests get compiled within a hierarchy (possibly even in the exact same way that Linux does - e.g. generate/windows/debug/32/unittest/std/net)?

- Jonathan M Davis

On 20 Jan, 2012,at 07:49 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> The unit tests on Linux maintain the module hierarchy when they're compiled. For example, on 64-bit Linux, std.net.isemail's unit test object file and binary go in generated/linux/debug/64/unittest/std/net/. However, on Windows, they all go in the unittest folder.
>
> That doesn't support having both debug and release builds. It doesn't support architecture (though we don't have to deal with anything other than 32-bit on Windows just yet). And most importantly for what I'm dealing with at the moment, it doesn't support having multiple sub-modules with the same name.
>
> In my case, I'm working on splitting std.datetime into sub-modules in std.dtime, and it makes some sense to have a windows.d with some of the windows-specific functions in it. However, there is already a std/c/windows/windows.d. So, on Windows, they would both be trying to compile to the same place in spite of the fact that they're in completely different packages.
>
> Would someone who's knowledgable enough about makefiles (and the Windows makefile in particular) be able and willing to fix win32.mak so that the unit tests get compiled within a hierarchy (possibly even in the exact same way that Linux does - e.g. generate/windows/debug/32/unittest/std/net)?
>
> - Jonathan M Davis

This would also solve the problem:

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

This would output the object files with fully? qualified names, i.e.

std.net.isemail.o

--
/Jacob Carlborg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20120120/b2f0a953/attachment-0001.html>

On Friday, January 20, 2012 07:32:30 Jacob Carlborg wrote:
> This would also solve the problem:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=3541
> 
> This would output the object files with fully? qualified names, i.e.
> 
> std.net.isemail.o

True. And that may very well be an improvement, but it wouldn't make it so that the release and debug versions (or 32-bit or 64-bit when the time comes) end up in separate directories where they won't stomp on each other. So, while the pull request associated with that enhancement request may solve my immediate problem (which would be fine with me for the short term), I think that the makefile should still be adjusted in the long run.

- Jonathan M Davis

The windows build does not do a separate file for each unittest, it does them all at once. So there should be no conflict.

On 1/19/2012 10:49 PM, Jonathan M Davis wrote:
> The unit tests on Linux maintain the module hierarchy when they're compiled. For example, on 64-bit Linux, std.net.isemail's unit test object file and binary go in generated/linux/debug/64/unittest/std/net/. However, on Windows, they all go in the unittest folder.
>

On 20.01.2012 07:49, Jonathan M Davis wrote:
> The unit tests on Linux maintain the module hierarchy when they're compiled. For example, on 64-bit Linux, std.net.isemail's unit test object file and binary go in generated/linux/debug/64/unittest/std/net/. However, on Windows, they all go in the unittest folder.
>
> That doesn't support having both debug and release builds. It doesn't support architecture (though we don't have to deal with anything other than 32-bit on Windows just yet). And most importantly for what I'm dealing with at the moment, it doesn't support having multiple sub-modules with the same name.
>
> In my case, I'm working on splitting std.datetime into sub-modules in std.dtime, and it makes some sense to have a windows.d with some of the windows-specific functions in it. However, there is already a std/c/windows/windows.d. So, on Windows, they would both be trying to compile to the same place in spite of the fact that they're in completely different packages.
>
> Would someone who's knowledgable enough about makefiles (and the Windows makefile in particular) be able and willing to fix win32.mak so that the unit tests get compiled within a hierarchy (possibly even in the exact same way that Linux does - e.g. generate/windows/debug/32/unittest/std/net)?
>
> - Jonathan M Davis


Some time ago, I have completely given up on the druntime/phobos makefiles for windows because of similar issues. I'm using the posix makefiles (with minor patches) on windows with the help of these ancient unix-tools that come with a low installation cost: http://unxutils.sourceforge.net/

If there is interest, I could try to create a pull request.

Rainer

On Friday, January 20, 2012 01:15:38 Walter Bright wrote:
> The windows build does not do a separate file for each unittest, it does them all at once. So there should be no conflict.

But the object files would still conflict. One would probably overwrite the other.

Not to mention, if I look in the unittest directory, I see an exe file for every obj file, which would seem to indicate that an exe file is being generated for every module, even if there's a single exe which is generated to run the tests.

- Jonathan M Davis

On 1/20/2012 1:27 AM, Jonathan M Davis wrote:
> On Friday, January 20, 2012 01:15:38 Walter Bright wrote:
>> The windows build does not do a separate file for each unittest, it does them all at once. So there should be no conflict.
> But the object files would still conflict. One would probably overwrite the other.

Multiple object files are not created. It builds one giant object file.

> Not to mention, if I look in the unittest directory, I see an exe file for every obj file, which would seem to indicate that an exe file is being generated for every module, even if there's a single exe which is generated to run the tests.
>
>

I don't see a unittest directory when I run it.

On Friday, January 20, 2012 02:15:08 Walter Bright wrote:
> On 1/20/2012 1:27 AM, Jonathan M Davis wrote:
> > On Friday, January 20, 2012 01:15:38 Walter Bright wrote:
> >> The windows build does not do a separate file for each unittest, it
> >> does
> >> them all at once. So there should be no conflict.
> > 
> > But the object files would still conflict. One would probably overwrite the other.
> 
> Multiple object files are not created. It builds one giant object file.
> 
> > Not to mention, if I look in the unittest directory, I see an exe file for every obj file, which would seem to indicate that an exe file is being generated for every module, even if there's a single exe which is generated to run the tests.
> 
> I don't see a unittest directory when I run it.

Hmmm. I don't know what's going on then. I have one at the top level. Maybe I messed around with Kenji's pull request for splitting up the unit tests at some point (though I don't remember doing that). I'll have to look into it tomorrow evening.

- Jonathan M Davis

On Friday, January 20, 2012 02:26:01 Jonathan M Davis wrote:
> On Friday, January 20, 2012 02:15:08 Walter Bright wrote:
> > I don't see a unittest directory when I run it.
> 
> Hmmm. I don't know what's going on then. I have one at the top level. Maybe I messed around with Kenji's pull request for splitting up the unit tests at some point (though I don't remember doing that). I'll have to look into it tomorrow evening.

Yeah. I must have tried out Kenji's changes for splitting out the unit tests at some point. I blew away everything in the repository, checked it all out again, and built it, and I don't end up with a unittest directory. So, I guess that it isn't an issue. Sorry for the noise.

- Jonathan M Davis