OK, it has something to do with the fact that a module is compiled with -lib, and with putting the shared constructor in a class.
I'll file a bug report on it. Note, there still is a cycle, but because of the bug, the compiler isn't correctly identifying dependencies. So we still need to fix std.encoding/std.random. -Steve ----- Original Message ---- > From: Steve Schveighoffer <[email protected]> > To: Discuss the phobos library for D <[email protected]> > Sent: Fri, November 5, 2010 12:02:59 PM > Subject: Re: [phobos] improved module cycle detection algorithm finds > existing >cycle in phobos, what to do? > > Well, I don't think my algorithm's broken, I think the compiler is doing > something strange. > > When building the unit test for std.encoding, the module std.encoding is >listed > > as having shared ctors/dtors, and is not marked as standalone. > > When building the unit test for std.random, the module std.encoding is > listed >as > > *not* having shared ctors/dtors. However, there are 6 modules named like: > > encoding.64 > encoding.65 > encoding.66 > encoding.67 > encoding.68 > encoding.69 > > Which are all marked as having shared ctors/dtors, *but* also marked as > standalone. > > Why is the compiler doing something different if you are compiling unit > tests > for a given module? And to me, it looks like the module should have > non-standalone ctors/dtors (it has 6 classes which have a shared static this). > > Any clues? > > -Steve > > > > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos > _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
