On Thu, Feb 3, 2011 at 2:54 PM, Michael Hanke <span dir="ltr"><<a href="mailto:michael.hanke@gmail.com" target="_blank">michael.hanke@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Thu, Feb 03, 2011 at 09:01:00AM +0100, RIVIERE Denis wrote:<br>
><br>
> Hi Michael,<br>
><br>
> - bv_maker and its $HOME config can be avoided: in such a case you<br>
> need to perform a 2 stage compilation: 1. cmake/make/make install the<br>
> brainvisa-cmake project then make your PATH point to its installation<br>
> 2. cmake the other projects (aims, anatomist, soma...), which will be<br>
> using brainvisa-cmake. The entry point CMakeLists.txt is (as far as I<br>
> remember) in the brainvisa-cmake project,<br>
> brainvisa-cmake/trunk/CMakeLists.txt, you can pass it directly to<br>
> cmake or ccmake from an empty build directory. There used to be a<br>
> wiki page on this, but I guess Yann has removed it since he did the<br>
> bv_maker tool.<br>
<br>
</div>Good to know. However, it is still not really clear to me how that can<br>
be achieved. A pointer to this wiki page would probably help me gain clarity<br>
on this issue. Thanks!<br>
<div><br></div></blockquote><div>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).<br>
<br>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.<br>
<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>
> - There are some Find* modules, yes, we use them to find system<br>
> libraries when installed at non-standard locations on systems that do<br>
> not provide them, and to solve the cross-platform issues. However they<br>
> do not harm, they do work on Ubuntu, and if ther is any issue on<br>
> Debian, we can probably fix them. Normally I think most of them use<br>
> the underlying system FindPackage, and if the library is not found,<br>
> they do something else. Maybe also a few of them were not part of<br>
> earlier cmake releases and are not needed any longer (?).<br>
<br>
</div>The point is that many issues with those in Debian have been dealt with<br>
already. _If_ there are problems we have to rediscover them all again.<br>
However, I will not worry about this now.<br></blockquote><div><br>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. <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> - The embedded libraries (mainly nifti, gifti, rply) have been<br>
> embedded to avoid the pain of an external installation / findPacklage<br>
> (especially on Windows and MacOS) when they are small enough. We have<br>
> checked in every case that their licensing allows it. What's the<br>
> problem with them ? We did not make a system to allow bypassing them,<br>
> it would require a bit more infrastructure.<br>
<br>
</div>It is not about licensing it is about code duplication and the<br>
impossibility to fix bugs efficiently. In Debian all NIfTI-aware<br>
programs use exactly one library version. Any problem in this library<br>
can be fixed with a single upload.<br>
<br>
For example. your copy of the NIfTI lib is outdated by 2.5 years. It<br>
doesn't have fixes for critical issues with large gzipped files and<br>
byte swapping. If a Debian user would load a file that is created by Caret<br>
your copy would vomit, because it doesn't know the Caret extension code,<br>
....<br>
<br>
It would be a huge time sink if I would have to manually track down all<br>
the problems in all the different version that projects include as<br>
'convenience' copies - very inconvenient for developers and users.<br>
For this reason, Debian has a strict policy that prevent this type of<br>
code duplication.<br>
<br>
I understand that it looks like just more work at first sight, but 5<br>
years of maintaining various neuroimaging software for Debian tell me<br>
that it really pays off in the long run.<br></blockquote><div><br>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).<br>
<br> Yann<br><br>
</div></div>