From: Amitha P. <pe...@cs...> - 2004-01-07 18:53:33
|
Hi all Our current build order in the CMakeLists.txt tries to build libraries before their dependencies are built. This makes it difficult to build just a single library. For example, running "make" in core/vil tries also to build core/vil/algo, core/vil/io, core/vil/examples, and core/vil/tests. Some of these will fail if other parts of the library haven't been built yet: tests depends on testlib, examples may depend on other things. I think a good solution would be to move all the SUBDIR commands to the core/CMakeLists.txt file. So, this file will have a format like # Level 1 libraries SUBDIRS( vpl ) SUBDIRS( vsl ) .. # Level 2 libraries SUBDIRS( vnl/io ) SUBDIRS( vnl/algo ) SUBDIRS( vgl/io ) SUBDIRS( vgl/algo ) .. # Test cases IF( BUILD_TESTING ) SUBDIRS( testlib/tests ) SUBDIRS( vnl/tests ) SUBDIRS( vil/tests ) ... SUBDIRS( tests ) ENDIF( BUILD_TESTING ) # Examples IF( BUILD_EXAMPLES ) SUBDIRS( vnl/examples ) SUBDIRS( vil/examples ) ... SUBDIRS( examples ) ENDIF( BUILD_EXAMPLES ) Comments? Amitha. |
From: Ian S. <ian...@st...> - 2004-01-07 19:16:02
|
> -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...]On Behalf > Of Amitha > Perera > Sent: Wednesday, January 07, 2004 6:53 PM > To: vxl...@li... > Subject: [Vxl-maintainers] Changing build order of libraries > > > Hi all > > Our current build order in the CMakeLists.txt tries to build libraries > before their dependencies are built. This makes it difficult to build > just a single library. For example, running "make" in core/vil tries > also to build core/vil/algo, core/vil/io, core/vil/examples, and > core/vil/tests. Some of these will fail if other parts of the library > haven't been built yet: tests depends on testlib, examples may depend > on other things. > > I think a good solution would be to move all the SUBDIR commands to > the core/CMakeLists.txt file. So, this file will have a format like > > # Level 1 libraries > SUBDIRS( vpl ) > SUBDIRS( vsl ) > .. > > # Level 2 libraries > SUBDIRS( vnl/io ) > SUBDIRS( vnl/algo ) > SUBDIRS( vgl/io ) > SUBDIRS( vgl/algo ) > .. > > # Test cases > IF( BUILD_TESTING ) > SUBDIRS( testlib/tests ) > SUBDIRS( vnl/tests ) > SUBDIRS( vil/tests ) > ... > SUBDIRS( tests ) > ENDIF( BUILD_TESTING ) > > # Examples > IF( BUILD_EXAMPLES ) > SUBDIRS( vnl/examples ) > SUBDIRS( vil/examples ) > ... > SUBDIRS( examples ) > ENDIF( BUILD_EXAMPLES ) > > Comments? I quite like going into core's sub directories, typing make, and having the tests and examples subdirectories build as soon as the library is finished. I'd agree that having to build vnl_algo before I can run vnl/tests is annoying. The solution there is to move all the vnl_algo tests into vnl/algo/tests. In general, I doubt there is an globally ideal build order. One possible solution would be to modify cmake so that it inserts tests into the Makefile, such that make noSUBDIR would have the desired effect. Until then, can I suggest Ctrl-C. Ian. > > Amitha. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <pe...@cs...> - 2004-01-07 19:55:59
|
Ian Scott wrote: > I quite like going into core's sub directories, typing make, and having the > tests and examples subdirectories build as soon as the library is > finished. Yes. And the reason this sounds good is that one normally expects that if the library builds successfully, then the tests and examples will build successfully. This is not currently true. As you suggest, > The solution there is to move all the vnl_algo tests into > vnl/algo/tests. is one solution. However, we still have a potential inconsistency between build order and dependency order. Ideally, the two should be consistent. > In general, I doubt there is an globally ideal build order. There may be no single best solution, but I think there are ones better than what we have now. As I wrote above, build order should be consistent with dependency order. > One possible solution would be to modify cmake [...] I've suggested previously to the CMake community that CMake has enough knowledge to ensure the build order in a Makefile matches the dependency order of the libraries. I believe they are considering it for CMake v 2. > Until then, can I suggest Ctrl-C. You may. However, that is a stop gap solution that makes no attempt at understanding or solving the underlying problem. Amitha. |
From: Peter V. <Pet...@es...> - 2004-01-07 22:29:53
|
> I think a good solution would be to move all the SUBDIR commands to > the core/CMakeLists.txt file. I agree with this. If someone still wants to build in all sudirectories, he can still do for d in `find . -type d` ; do ( cd $d ; make ) ; done -- Peter. |
From: Amitha P. <pe...@cs...> - 2004-01-08 17:52:50
|
Ian pointed out that it is good to have the tests build automatically when you change the library. I agree with him. I thus modify my proposal a little bit: - Divide the tests so that the tests for a given library are only dependent on that library. This implies the tests of vnl and vnl_algo are different, for example, and will exist in different places. - Building a library will also recurse to the tests and build those. The tests should, in general, only depend on the library being tested and on testlib. With this done, the core/CMakeLists.txt will look something like SUBDIRS( testlib ) SUBDIRS( vul ) # build libvul and vul/tests SUBDIRS( vnl ) # build libvnl and vnl/tests ... SUBDIRS( vnl/algo ) # build libvnl_algo and vnl/algo/tests ... SUBDIRS( vnl/examples ) ... Any objections to this idea? I can't promise a date by which I'll do this. If there are no objections, I will do it sometime. Anyone else should feel free to do it before me. Amitha. |