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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

On 10/02/2011 03:52 PM, Robert Clipsham wrote:
> How about:
>
> --
> pure static this()
> {
>   // Code
> }
> --
>

pragma(depends, module1, modle2) static this() {
}

That would imply that whatever is imported, this one only depends on the listed modules.

> That is, pure at module level (doesn't depend on any other modules). Ordering can be done as before, we just need to add a clause in the docs to define pure module constructors as being run first given a "cyclic dependancy".
>
> On 2 October 2011 23:42, Jonathan M Davis <jmdavisProg at gmx.com <mailto:jmdavisProg at gmx.com>> wrote:
>
>     On Sunday, October 02, 2011 14:49:26 Walter Bright wrote:
>     > On 10/1/2011 9:07 PM, Jonathan M Davis wrote:
>     > > 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).
>     >
>     > If such a feature were added, it would not be allowed in @safe code.
>
>     Well, it does kind of scream @trusted, since you're telling the
>     compiler that
>     what you're doing is safe instead of the compiler figuring it out
>     on its own.
>
>     - Jonathan M Davis
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> -- 
> Robert
> http://octarineparrot.com/
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20111004/2fdf2e34/attachment.html>