On 3/19/13 11:57 AM, jmaher wrote:
The consensus is the master manifest solution is not of interest, are there
proposals and plans to remove:
testing/xpcshell/xpcshell.ini
testing/crashtest/crashtests.list
layout/reftest/reftests.list
This thread seems as though it is focusing on one of the 3 master manifests.
As I am working towards adding a manifest solution for mochitests, I would
really like to know what is an agreed upon forward solution here.
We just had a long conversation in #automation and I the outcome was
something along the lines of:
* Master manifests checked into the tree are silly for reasons outlined
in this thread.
* moz.build files will at most be the "manifests" or at least link to
each manifest file.
* Master manifests can be derived by smaller, individual manifests at
build config time (output of moz.build traversal).
There is an open question of whether to use moz.build files to declare
test files, etc or whether to use something else. If something else, we
could use one of the existing manifest formats or use a moz.build Python
sandbox variation.
I personally don't care too much. The important property from a build
config perspective is that the build config can read data out of the
manifests and use it as part of building the tree. If moz.build files
don't contain the data themselves, then we need a Python API to parse
the manifests at build config time. If the build config can see all, it
can easily write out a master manifest, a JSON file, or something else
that can be read by the test runners.
If I had to weigh in, I think existing manifests like xpcshell.ini work
good enough and might be more readable and maintainable than managing
everything in moz.build files. But, I'm ignorant of a lot of things, so
maybe they aren't good enough.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
