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

[Yann Cointepas]

On Thu, Feb 3, 2011 at 2:54 PM, Michael Hanke <michael.hanke at gmail.com>wrote:

> 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!
>
> bv_maker was designed for people who have to regularily sync/mdoify/compile
sources taken from BrainVISA project. I modified it to take into account the
one shot compilation use case. I also made some changes on our subversion
repository to make it possible to create the attached script. This script
can be used to create three directories: sources, build and install. I
succesfully used it from a brain new account on Ubuntu (with all required
dependencies installed).

There is probably a problem that still have to be solved. We are using an
environment variable BRAINVISA_SHARE to find the location of the
install/share directory. This is probably not appropriate for a Debian
package and could be avoided by setting the appropriate default value in the
code using this variable.


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

We are just starting to use the Debian world, we just did not know that
there was some  Find* specific for this system. However, we are still
compiling for other systems and the Find* we put in our sources are here for
that and we need them. The problem is that they hide the Debian ones with
the same name. The only solution I see is to identify the common files and
to put them in a directory that would not be included on Debian. I think
this can be a nightmare to maintain and it is not worth the effort as long
as everything compiles on Debian systems.


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

We could solve this by trying using the appropriate find_package for these
libs and only use our embedded copies if it fails (on some systems such as
windows it will fail).

      Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/neurodebian-devel/attachments/20110206/6784a058/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bv_standalone_compilation
Type: application/octet-stream
Size: 1071 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/neurodebian-devel/attachments/20110206/6784a058/attachment.obj>