Hi, again, Thomas has already provided a lot of insight :-)
Please see my comments below. On 04/28/2011 04:22 PM, Thomas Wolf wrote: > On 28.04.2011 15:44, Matt Clarkson wrote: >> Thanks Thomas. >> >> Just a few more questions, if you or anyone else have the time. >> >> So, do you >> >> a) compile MITK, (along with your choice of ITK, VTK etc. versions), and >> store this somewhere on your network and never touch it. Then in your own >> project, just set the INCLUDE_DIRECTORIES, and library paths, and build >> against it, which means adding CMake code to pull in all the right dynamic >> libraries when you assemble and pack your executable. You could certainly do this, but you would either have to build MITK for all possible compilers/OSs/etc. the people in your lab are using, or have full control over their development environment ;-) >> b) Include MITK in your source tree, setting all the right CMake flags, so >> that effectively MITK is compiled as libraries as part of your own project. >> This would mean that each developer has their own copy of MITK within their >> development environment. >> >> It sounds like you do option b. So, do you regularly update your version of >> MITK? or do you pull the latest MITK version using svn/git as part of your >> build process? >> >> Many thanks, >> >> Matt > Hi Matt, > > your're welcome. > > Yes, you are right, we do option b). One reason not to connect it > automatically to another repository is to have own, stable revsions > versioned in our repository. From time to time, we update and adjust our > project code and go along again for some while. (Merging with some kind > of rsync tool) > > Option a) is an alternative which I consider as an enhancement. The big > plus is speed up of compilation time, because some of the stuff is > untouched by the actual project and prebuilt. So maybe I split the > makefiles up into building 3rdparty stuff and building the project by > referencing the externals. Thomas and I had the same discussion recently, so I will suggest my preferred solution (but which one is the best for you depends on your requirements, of course) :-) You could add a "ExternalProject" call (this is a CMake module shipped with CMake itself) in your projects CMake files which would clone the MITK repository (probably a specific version/hash), configure a build tree and build it. Then your build system would configure your actual project by providing the MITK_DIR variable which will be used by a find_package(MITK) call. Note that projects built with "ExternalProject" will not be rebuild every time, so after the initial build process, you will only have re-compile your own (changed) sources. The more "traditional" solution we used in the past was to provide pre-built packages (which would be your option a) ) and additionally build instructions for our external dependencies (ITK, VTK, etc). So people could either copy the dependencies to their local machine (network shares proved to be way too slow during compiles) or build everything themselves and then provide the *_DIR variable in the MITK configure step. Hope this helps, Sascha ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
