I vote for having unit tests in their own modules. I'm having the same issue with my serialization library I'm trying to get into Phobos.
On 3 okt 2011, at 20:46, Sean Kelly wrote: > On Oct 1, 2011, at 9:07 PM, Jonathan M Davis wrote: > >> On Saturday, October 01, 2011 20:34:45 Jonathan M Davis wrote: >>> On Friday, September 30, 2011 20:16:33 Walter Bright wrote: >>>> Both have static constructors. This wasn't detected before because of a >>>> bug in dmd (now fixed). >>> >>> std.process doesn't even import std.datetime, so I don't know why a circular >>> dependency would even exist in this case. As usual, trying to figure out >>> what's really going on with a circular dependency isn't going to be fun. >> >> Ah. It looks like it's happening because std.exception uses std.datetime in >> its unit tests. Well, hopefully the same trick that std.file and std.stdio >> use >> should work with std.process as well. It would be really nice though to be >> able to just somehow mark one or both of the static constructors or modules >> to >> indicate that the initialization order doesn't matter (or to tell it which >> order to use if that's a better solution). I'll have a pull request with an >> attempted solution up shortly, but someone with a Mac is going to have to >> test >> it. > > Seems like yet another reason to put complex unit tests in their own module. > And this was all for an alias of getpid that maps to functions in both Posix > and Win32? Is that even a good idea to begin with? And why move the alias > to core.thread? It's not like threads have anything to do with processes or > process IDs. Was this meant to be a quick fix so we could run again or a > permanent fix? > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos -- /Jacob Carlborg _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
