[CMake] Building a library with a complex hierarchy
Hello, I'm going to begin with the usual "I'm not sure this is the right place to post this, but hopefully it is", so with that done I can get on to my real question. I'm trying to build a game engine, or rather what is currently there, I'm currently developing. The output of the build is supposed to be a library, a shared one is preferable, and a few functional tests I will worry about later. The problem is that I'm not quite sure on how to structure the build, as the directory hierarchy is a little more complex than I'm used to. The directories of the project root (just to show what my situation is): core i18n math subsystem util With core/ being the most interesting part at the moment. core: eventsystem log time worldobject kernel memorymanager datamanager script threadmanager My first thought was to compile all the different parts into their own libraries and then link them all into a common shared one. This, apperently, wasn't possible and maybe not a very clever way to do it. Simply having a ADD_LIBRARY with all the source files would look very ugly, and be error prone. Another way to do it could be by defining lots of varibles, but that doesn't sound very good to me either. So if anyone could give me a hint on how to do this, or a good documentation on writing builds for these kind of more complicated projects (doesn't have to be cmake), it'd be very happy. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a library with a complex hierarchy
At 09:00 PM 7/24/2006, Tilo Wiklund wrote: >Hello, >I'm going to begin with the usual "I'm not sure this is the right >place to post this, but hopefully it is", so with that done I can get >on to my real question. >I'm trying to build a game engine, or rather what is currently there, >I'm currently developing. >The output of the build is supposed to be a library, a shared one is >preferable, and a few functional tests I will worry about later. >The problem is that I'm not quite sure on how to structure the build, >as the directory hierarchy is a little more complex than I'm used to. >The directories of the project root (just to show what my situation is): >core i18n math subsystem util >With core/ being the most interesting part at the moment. >core: >eventsystem log time worldobject kernel memorymanager datamanager >script threadmanager >My first thought was to compile all the different parts into their own >libraries and then link them all into a common shared one. This, >apperently, wasn't possible and maybe not a very clever way to do it. >Simply having a ADD_LIBRARY with all the source files would look very >ugly, and be error prone. Another way to do it could be by defining >lots of varibles, but that doesn't sound very good to me either. >So if anyone could give me a hint on how to do this, or a good >documentation on writing builds for these kind of more complicated >projects (doesn't have to be cmake), it'd be very happy. >___ How is this project currently built? That might be a good place to start. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a library with a complex hierarchy
On 2006-07-25 03:00+0200 Tilo Wiklund wrote: My first thought was to compile all the different parts into their own libraries and then link them all into a common shared one. This, apperently, wasn't possible and maybe not a very clever way to do it. Simply having a ADD_LIBRARY with all the source files would look very ugly, and be error prone. I would go for a multiple libraries approach, and have them link to each other. However, with this approach you have to be careful of the direction of dependencies so that you avoid cross-dependencies or circular dependencies between libraries. So for example, if liba depends on libb (i.e., libb resolves symbols in liba), and libb depends on libc, then you cannot have libc depending back on libb or liba, and libb cannot depend on liba. Also, you should consider whether certain parts of your project would best by dynamically loaded using plug-ins (i.e., the library or executable optionally loads the plug-in at run-time at user request rather than the run-time loader always loading all components of the project software). The PLplot project went through this sort of assessment several years ago. It was a lot of work, but well worth it in the end. The result is a lean/mean shared core library which does nothing but core plotting functions, a number of languages interfaces which are implemented as shared libraries which link to the core library, and a lot of different plotting device plug-ins. Each plug-in is dynamically loaded by the core library only if the user requests that particular device. And, yes, we historically implemented all of this with autotools, but my project to also do the same with cmake is nearly finished, and I quite like the results (especially the speed!) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
