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

[Denis RIVIERE]

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