Do the existing tests use a wildcard rule to gather all test sources? We would need to insure that the wildcard rule for the unit tests and the large tests are mutually exclusive. Also, will the unit tests be one executable or many? They will probably compile/run faster if there is a smaller number of executables. On Mon, Dec 29, 2008 at 1:43 PM, Misha Brukman <brukman at gmail.com> wrote:> 2008/12/29 Talin <viridia at gmail.com> > >> I'm working on an update to the patch. The only thing holding me up is >> trying to come to a final decision as to where all the various pieces should >> live. Specifically, the Google Test library, and the actual unit tests >> themselves. > > > I would recommend putting Google Test in llvm/test/googletest . The > unittests should probably go in llvm/test with other tests, in the same > directories, e.g., tests of the various analysis algorithms would live in > llvm/test/Analysis, 1 file per analysis, unless folks think they should go > further into the tree: llvm/test/Analysis/Andersens/, etc., but I think it > would be cleaner and easier if the files for a single library were in the > same directory, as we would be able to create a single unittest from all of > them, to speed up the build/link/test cycle. > > Thoughts? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081229/f9a6175e/attachment.html>
2008/12/29 Talin <viridia at gmail.com>> Do the existing tests use a wildcard rule to gather all test sources? We > would need to insure that the wildcard rule for the unit tests and the large > tests are mutually exclusive. >By "large tests", I assume you mean the .ll tests? Those are one-file-per-test. Also, if you use Chris' suggestion on directories, it will separate the unit tests from the large tests.> Also, will the unit tests be one executable or many? They will probably > compile/run faster if there is a smaller number of executables. >Yes, I agree, they'll link faster if we have fewer tests. I would not want a single massive test for all of LLVM -- how about 1 test binary per major directory in llvm/lib, unless it's really necessary to split them up, e.g. target-dependent unittests, but each .cpp file would ideally have its own _test.cpp file, so it's easier to keep the tests for different modules separate. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081229/7897fad6/attachment.html>
OK, sounds good. I'll start work on that. On Mon, Dec 29, 2008 at 1:57 PM, Misha Brukman <brukman at gmail.com> wrote:> 2008/12/29 Talin <viridia at gmail.com> > >> Do the existing tests use a wildcard rule to gather all test sources? We >> would need to insure that the wildcard rule for the unit tests and the large >> tests are mutually exclusive. >> > > By "large tests", I assume you mean the .ll tests? Those are > one-file-per-test. Also, if you use Chris' suggestion on directories, it > will separate the unit tests from the large tests. > > >> Also, will the unit tests be one executable or many? They will probably >> compile/run faster if there is a smaller number of executables. >> > > Yes, I agree, they'll link faster if we have fewer tests. I would not want > a single massive test for all of LLVM -- how about 1 test binary per major > directory in llvm/lib, unless it's really necessary to split them up, e.g. > target-dependent unittests, but each .cpp file would ideally have its own > _test.cpp file, so it's easier to keep the tests for different modules > separate. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081229/08045edc/attachment.html>
On Mon, Dec 29, 2008 at 1:57 PM, Misha Brukman <brukman at gmail.com> wrote:> 2008/12/29 Talin <viridia at gmail.com> > >> Do the existing tests use a wildcard rule to gather all test sources? We >> would need to insure that the wildcard rule for the unit tests and the large >> tests are mutually exclusive. >> > > By "large tests", I assume you mean the .ll tests? Those are > one-file-per-test. Also, if you use Chris' suggestion on directories, it > will separate the unit tests from the large tests. > > >> Also, will the unit tests be one executable or many? They will probably >> compile/run faster if there is a smaller number of executables. >> > > Yes, I agree, they'll link faster if we have fewer tests. I would not want > a single massive test for all of LLVM -- how about 1 test binary per major > directory in llvm/lib, unless it's really necessary to split them up, e.g. > target-dependent unittests, but each .cpp file would ideally have its own > _test.cpp file, so it's easier to keep the tests for different modules > separate. >One nice feature of gtest is automatic test collection. If the llvm tests all use the same main(), and the main() is not repeated in the individual unittest files, then it is trivial to have a) one massive binary that contains all the tests (fast to build & run all unittests pre-checkin) and separate binaries per .cpp (i.e. foo.cc, foo_test.cc, and foo_test binary) for fast iterating which would only be built and run when explicitly called from the makefile (i.e. they would not be run by the build-all-unittest make target). On the other hand, if separate binaries are built, then a make unittest target could parallelize trivially by adding -jX. I belive fork-level parallelism within a single test binary is in coming to gtest, but is not available yet. Keir .> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081229/ffa6efd8/attachment.html>