From: Amitha P. <pe...@cs...> - 2002-04-06 19:55:51
|
Hi all Triggered Bill Hoffman's suggesting of using the CMake test driver wrapping code, I created a single test driver for vcl that still separately compiles each test. I did not use the automated CMake command. The question: should we use it, or should we avoid it so enable maximum portability to other build environments? Amitha. |
From: Peter V. <Pet...@es...> - 2002-04-07 06:43:30
|
> The question: should we use it, or should we avoid it so > enable maximum portability to other build environments? I believe we should start using it. Other build environments should be able to support this as well. After all, it's just linking several object files into a single executable (and adding a "main" program). Peter. |
From: Peter V. <Pet...@es...> - 2002-04-07 08:20:00
|
> May I request your help in tracking this down? There isn't much > information available on the dashboard pages. That must have been caused by an old .ii file left over from a previous build. I expect this will work correctly on the next build. Peter. |
From: Peter V. <Pet...@es...> - 2002-04-07 08:35:59
|
There is one other disadvantage with this approach: - the test output will be in a single file instead of 1 .out file per test. - consequently there will be only 1 Dart entry saying "failed test" and the dartboard will not give an indication of what test(s) failed. Peter. |
From: Amitha P. <pe...@cs...> - 2002-04-07 15:20:05
|
On Sun, Apr 07, 2002 at 10:35:49AM +0200, Peter Vanroose wrote: > There is one other disadvantage with this approach: > > - the test output will be in a single file instead of 1 .out file per test. > - consequently there will be only 1 Dart entry saying "failed test" > and the dartboard will not give an indication of what test(s) failed. Actually, no, since we could run the driver multiple times: ADD_EXECUTABLE( testDriver test1.cxx test2.cxx test3.cxx ) ADD_TEST( test1 testDriver test1 ) ADD_TEST( test2 testDriver test2 ) ADD_TEST( test3 testDriver test3 ) I believe this is what the CMake-generated driver expects. Amitha. |
From: Peter V. <Pet...@es...> - 2002-04-07 19:57:55
|
> Actually, no, since we could run the driver multiple times: > ADD_EXECUTABLE( testDriver test1.cxx test2.cxx test3.cxx ) > > ADD_TEST( test1 testDriver test1 ) > ADD_TEST( test2 testDriver test2 ) > ADD_TEST( test3 testDriver test3 ) > > I believe this is what the CMake-generated driver expects. Of course, you're right. Sorry. In that case, would we provide an explicit test driver program to make it easier for other build systems to run the tests? Peter. |
From: Amitha P. <pe...@cs...> - 2002-04-07 22:43:39
|
> In that case, would we provide an explicit test driver program > to make it easier for other build systems to run the tests? That is the key question. If we use the CMake command, the test driver code is automatically generated, but users of other make systems will have to write some appropriate driver generation code, which would imply that they need to parse CMakeLists.txt and figure out which tests to include and so on. Has anyone tried compiling in a non-CMake build environment recently? Amitha. |
From: Amitha P. <pe...@cs...> - 2002-04-08 05:52:37
|
I wrote: > That is the key question. If we use the CMake command, the test driver > code is automatically generated, Looking at the CMake sources, I found that the test driver creation code in only in the development release. Since we are keeping some kind of policy that vxl can be compiled with the latest public release, we either have to wait for the next CMake release, or else roll our own. On a related topic: could we not allow all the test directories to depend on a single test library, instead of having vnl_test.h, vgl_test.h, etc, all with essentially the same functionality? I know we want to keep the library dependencies low, but does that extend to the test cases too? Especially if we make the test library very simple, and dependent only on vcl. (I guess this goes back to the old TJr ways.) If we opt to write a driver program, I'd rather the core of the driver get written once and linked into all the tests. Amitha. |
From: Peter V. <Pet...@es...> - 2002-04-08 06:17:19
|
> Looking at the CMake sources, I found that the test driver creation > code in only in the development release. I would also prefer not to rely on test driver (= source file) creation of a *build* system. It's better to keep all source code under direct vxl control. Peter. |
From: Amitha P. <pe...@cs...> - 2002-04-25 06:37:16
|
Taking silence as assent, I've created "testlib" and converted the tests in vil to use that library. I'll now pause just in case silence wasn't assent... Amitha. |
From: Peter V. <Pet...@es...> - 2002-04-08 06:15:54
|
> Has anyone tried compiling in a non-CMake build environment recently? Yes; I'm doing my nightly builds with the (old) makefiles from branch build-makefiles. Peter. |
From: Ian S. <ian...@st...> - 2002-04-08 08:11:45
|
> That is the key question. If we use the CMake command, the test driver > code is automatically generated, I have a question about this proposal - Why? What do we gain? We lose in terms of added complexity. There is already a ctest program, and Tim's perl script (scripts\diagnostics\vxl_run_tests.pl) as ways of running multiple tests. These both have the advantage of running over multiple directories. Why bother with all the added complexity - especially from a beginner's point of view. In fact I would suggest separating many of the existing test programs from the TEST_MAIN stuff. > On a related topic: could we not allow all the test directories to > depend on a single test library, instead of having vnl_test.h, The lack of strict dependency already happens to some extent with some tests using vul and vpl to manage files. This was true even before I dismembered test_allvxl. Judging by AWF's reasons for low-dependency in the VXL book, the rule needn't apply to tests. From 1. > Common complaints have been > To use even one small routine, a large portion of the environment must be > included in the user's program, increasing program size, compile time, and > startup time. Sometimes the increase is such that debuggers and other tools fail to work. From 1.3.3 > This restriction is central to the design of vxl{}, because it > intrinsically limits the size of the core libraries Ian. > -----Original Message----- > From: Amitha Perera [mailto:pe...@cs...] > Sent: Saturday, April 06, 2002 8:57 PM > To: vxl...@li... > Subject: [Vxl-maintainers] Test driver programs > > > Hi all > > Triggered Bill Hoffman's suggesting of using the CMake test driver > wrapping code, I created a single test driver for vcl that still > separately compiles each test. I did not use the automated CMake > command. The question: should we use it, or should we avoid it so > enable maximum portability to other build environments? > > Amitha. > > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: William A. H. <bil...@ny...> - 2002-04-08 12:41:30
|
At 09:13 AM 4/8/2002 +0100, Ian Scott wrote: >> That is the key question. If we use the CMake command, the test driver >> code is automatically generated, > >I have a question about this proposal - Why? What do we gain? We lose in >terms of added complexity. The big thing you gain, is the reduction in the number of projects in your workspaces. MSDev runs much better with fewer projects. ITK project load times were decreased from over a minute to less than 10 seconds. New users are also less overwhelmed by the smaller workspaces. -Bill |
From: Andrew F. <aw...@ro...> - 2002-04-08 15:05:53
|
> -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...] On > Behalf Of William A. Hoffman > Sent: 08 April 2002 14:41 > To: ian...@st...; Vxl-maintainers (E-mail) > Subject: RE: [Vxl-maintainers] Test driver programs > > > At 09:13 AM 4/8/2002 +0100, Ian Scott wrote: > >> That is the key question. If we use the CMake command, the > test driver > >> code is automatically generated, > > > >I have a question about this proposal - Why? What do we > gain? We lose in > >terms of added complexity. > The big thing you gain, is the reduction in the number of projects > in your workspaces. MSDev runs much better with fewer projects. > ITK project load times were decreased from over a minute to less > than 10 seconds. New users are also less overwhelmed by the > smaller workspaces. That is certainly a good thing. I often find myself making small separate workspaces with just the projects I use -- it would be nice if there were for each executable, e.g. oxl/xcv, a DSW called xcv.dsw. Is this easy? Can someone shout out what file in cmake I should change to make it happen? A. |
From: William A. H. <bil...@ny...> - 2002-04-08 15:16:37
|
I think you can load the dsp files directly and msdev will create a dsw for you. However, the dependency stuff will not be working very well. Msdev will only know about the immediate project. At 04:05 PM 4/8/2002 +0100, Andrew Fitzgibbon wrote: >That is certainly a good thing. I often find myself making small >separate workspaces with just the projects I use -- it would be nice >if there were for each executable, e.g. oxl/xcv, a DSW called xcv.dsw. >Is this easy? Can someone shout out what file in cmake I should change >to make it happen? > >A. > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |