On Thursday, November 1, 2012 6:33:39 PM UTC-7, therealbr...@gmail.com wrote: > On Thursday, November 1, 2012 5:47:57 PM UTC-7, Dave Mandelin wrote: > > > At the last Tuesday meeting I foolishly agreed :-) to take charge of > > following up on this discussion and seeing if we can come to a decision. > > So, here goes: > > ... > > > I would prefer something like this: > > > |-- tests/ > > |-- browser-chrome/ > > |-- topic1 (omit this level if there would be only one) > > |-- topic2 > > |-- [...] > > |-- chrome/ > > |-- crashtests/ > > |-- marionette/ > > |-- mochitests/ > > |-- reftests/ > > |-- xpcshell > > |-- [..]/ > > ... > > > This is approximately what SpiderMonkey uses, and it seems to be > > approximately what Chromium and WebKit use. > > How about js/src/tests and other *tests subdirectories? Do they get > moved out to a remote top-level, where SpiderMonkey-only embedders > will miss them? > > The tyranny of hierarchy never ends. Either we have subsidiarity for > js and other modules, or not. If "Gecko" is one big module -- ok, I > get it. But you need a principle for giving js its own tests while > hoisting all others.
It looks like V8 keeps JS tests in a separate directory, but JSC has them in common with WebKit, presumably since V8 promotes itself as an embeddable component while JSC I believe does not. I don't think it would affect SpiderMonkey development much to move the tests to a new home. They are designed to be independent of the source code and the path to the program being tested. So I wouldn't mind. Even for independent distribution purposes, it makes more sense to me to collect files into new places to prepare a distro than to do so as part of the per-compile testing process. > This seems small potatoes either way, BTW. I've been through both > approaches. Neither is obviously winning. Sure, it's not some grand thing. I just like things to be nicely organized. And I really did find mochitest paths a hassle and a (small) tax on development effort. Dave _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
