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

[Michael Hanke]

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!

> - 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.

> - 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.

> - 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

-- 
Michael Hanke
http://mih.voxindeserto.de