Hi Sascha and Thomas, thanks for the help. I will give it a go.
Matt ----- "Sascha Zelzer" <[email protected]> wrote: > 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
