[Neurodebian-devel] RE : Packaging of anatomist (was: Latest and greatest in visualization of MRI data?)

Thu Feb 3 17:30:23 UTC 2011

Or maybe a simpler option is to use bv_maker (which basically does the two-
stage build), using a custom config file, that you can specify using the -c 
option, for instance:

bv_maker -c /tmp/bv_maker.cfg configure build

with /tmp/bv_maker.cfg looking like the following:

[ build $TMP/bvm/bv_build ]
  build_type = Release
  make_options = -j6
  aims trunk /volatile/riviere/neurosvn
  anatomist trunk /volatile/riviere/neurosvn
  brainvisa-share trunk /volatile/riviere/neurosvn
  soma trunk /volatile/riviere/neurosvn
  -soma-database
  -soma-io
  -soma-pipeline
  -soma-workflow

(I think these are the projects useful for anatomist/pyanatomist)
Note that you can use environment variables in the paths, ie using $BV_SOURCES 
instead of /volatile/riviere/neurosvn is OK if you have setup the envar before 
running bv_maker.
Oh and I realize that I have possibly forgotten the brainvisa-share project in 
the sources tarballs script. If not completely mandatory, it includes shared 
data that may be useful to anatomist (and also data not used by anatomist but 
by brainvisa or other of our tools).

Denis

Le jeudi 3 février 2011, Denis RIVIERE a écrit :
> Le jeudi 3 février 2011, Michael Hanke a écrit :
> > On Thu, Feb 03, 2011 at 09:01:00AM +0100, RIVIERE Denis wrote:
> > > Hi Michael,
> > > 
> > > - bv_maker and its $HOME config can be avoided: in such a case you
> > > need to perform a 2 stage compilation: 1. cmake/make/make install the
> > > brainvisa-cmake project then make your PATH point to its installation
> > > 2. cmake the other projects (aims, anatomist, soma...), which will be
> > > using brainvisa-cmake. The entry point CMakeLists.txt is (as far as I
> > > remember) in the brainvisa-cmake project,
> > > brainvisa-cmake/trunk/CMakeLists.txt, you can pass it directly to
> > > cmake or ccmake from an empty build directory.  There used to be a
> > > wiki page on this, but I guess Yann has removed it since he did the
> > > bv_maker tool.
> > 
> > Good to know. However, it is still not really clear to me how that can
> > be achieved. A pointer to this wiki page would probably help me gain
> > clarity on this issue. Thanks!
> 
> Actually I don't find the wiki page, maybe it has been removed and replaced
> by bv_maker. I will Yann answer on this, he might know better than I do...
> But we'll find a solution, for sure.
> 
> > > - We cannot avoid this layer on top of cmake, because we have a whole
> > > set of projects that we want to compile together, and be able to
> > > choose which projects we want to compile (ie just aims, or
> > > aims+anatomist, or aims+anatomist+brainvisa, etc), handle optional
> > > components, etc.
> > 
> > Fair enough. As long as it is still possible to craft a Debian packaging
> > I don't care much.
> > 
> > > - There are some Find* modules, yes, we use them to find system
> > > libraries when installed at non-standard locations on systems that do
> > > not provide them, and to solve the cross-platform issues. However they
> > > do not harm, they do work on Ubuntu, and if ther is any issue on
> > > Debian, we can probably fix them. Normally I think most of them use
> > > the underlying system FindPackage, and if the library is not found,
> > > they do something else. Maybe also a few of them were not part of
> > > earlier cmake releases and are not needed any longer (?).
> > 
> > The point is that many issues with those in Debian have been dealt with
> > already. _If_ there are problems we have to rediscover them all again.
> > However, I will not worry about this now.
> 
> To be verified, but I think our functions call the standard system ones, so
> they should not break.
> 
> > > - The embedded libraries (mainly nifti, gifti, rply) have been
> > > embedded to avoid the pain of an external installation / findPacklage
> > > (especially on Windows and MacOS) when they are small enough. We have
> > > checked in every case that their licensing allows it. What's the
> > > problem with them ? We did not make a system to allow bypassing them,
> > > it would require a bit more infrastructure.
> > 
> > It is not about licensing it is about code duplication and the
> > impossibility to fix bugs efficiently. In Debian all NIfTI-aware
> > programs use exactly one library version. Any problem in this library
> > can be fixed with a single upload.
> > 
> > For example. your copy of the NIfTI lib is outdated by 2.5 years. It
> > doesn't have fixes for critical issues with large gzipped files and
> > byte swapping. If a Debian user would load a file that is created by
> > Caret your copy would vomit, because it doesn't know the Caret extension
> > code, ....
> > 
> > It would be a huge time sink if I would have to manually track down all
> > the problems in all the different version that projects include as
> > 'convenience' copies - very inconvenient for developers and users.
> > For this reason, Debian has a strict policy that prevent this type of
> > code duplication.
> > 
> > I understand that it looks like just more work at first sight, but 5
> > years of maintaining various neuroimaging software for Debian tell me
> > that it really pays off in the long run.
> 
> Well, I quite agree with the code duplication issue, but our choice here
> was a trade-off between code duplication, simplicity of maintenance and of
> use for developers. From the pure debian world, OK it is clearly simpler
> to rely on the officially released debian packages, but debian is (sadly)
> not the whole world: we also have to build on fedora, centos, mandriva
> distribs, which do not ship nipy, and even stranger, on macos and windows,
> where installing such thirdparty libs might sometimes be really painful.
> So we chose to avoid this installation pain, both to us and to developers
> who would like to build on such platforms. I also have experience of what
> I'm saying, 15 years of maintainance on various platforms (as strange as
> windows, solaris, and irix by a time...)
> Well, one option would be to find an automatic way to sync / untar the
> "official" sources of such libraries to overwrite our embeded copies. It
> would probably be simpler than setting up a dependency system on the
> external lib in cases it is possible (which might be done but a bit
> later).
> 
> Well, we keep you in touch and tell you when we fix the build
> instructions... Denis
> 
> > > - the warning about packaging external components is not a problem: it
> > > is about something used when making "global" packages that include
> > > system libraries to make a self-contained binary package, allowing to
> > > run on different linux distribution, or on windows/mac. Here this is
> > > not what you want to do.
> > 
> > Right, thanks for the clarification.
> > 
> > > - the error, though, is a problem. But if you didn't take the right
> > > CmakeList from the beginning, maybe it explains.
> > 
> > Probably -- will see if it persists and report back.
> > 
> > Michael
> 
> _______________________________________________
> Neurodebian-devel mailing list
> Neurodebian-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/neurodebian-devel