It would be desirable to allow Gadgetron's cmake to detect newer
versions of armadillo installed in non system-standard locations, such
as /usr/local for instance.
Right now with Gadgetron 2.5, cmake only detects Armadillo if installed
in /usr and has a version greater than 3.8 something. In Ubuntu 12.04
(which ships with an outdated 2.x version), that means you need to
compile and install Armadillo from source. Since Armadillo has to be
located in /usr for Gadgetron to detect it, that means overwriting the
existing Ubuntu Armadillo with the user compiled one. This is not
recommended because of the potential for collision with the packaged
versions, and most guidelines advise to install user compiled libs in
locations such as /usr/local instead.
I have temporarily solved this by adding a HINTS parameter in the main
CmakeList for /usr/local. I am no cmake guru so this is probably not a
long term solution. However, for specific libraries where the
distributed ones are likely to be too outdated, such as Armadillo, it
would be a good idea to support other library locations, such as
/usr/local, /opt/local, etc...
Just wanted to trigger the discussion.
Ghislain
PS: I cannot post tickets to Gadgetron yet. Could you give me the right
privileges please ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I find HINTS to be more appropriate for this specific case as they do what they are supposed to do: provide non-standard locations which can potentially override the standard system path.
Environment variables are, I believe, better suited for dependencies such as CULA, where a custom compilation will definitely be required.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I find HINTS to be more appropriate for this specific case as they do what they are supposed to do: provide non-standard locations which can potentially override the standard system path.
Environment variables are, I believe, better suited for dependencies such as CULA, where a custom compilation will definitely be required.
Allow for non system-standard location of Armadillo
If you're installing Armadillo in a non-standard location and you want gadgetron to pick up that one, and not some other one, then you really better know what you're doing.
Are we talking about distributing a gadgetron specific FindArmadillo.cmake? The one shipped with cmake 2.8.12 on my brew install uses an environment variable like this:
# UNIX paths are standard, no need to write.
find_library(ARMADILLO_LIBRARY
NAMES armadillo
PATHS "$ENV{ProgramFiles}/Armadillo/lib" "$ENV{ProgramFiles}/Armadillo/lib64"
"$ENV{ProgramFiles}/Armadillo"
)
find_path(ARMADILLO_INCLUDE_DIR
NAMES armadillo
PATHS "$ENV{ProgramFiles}/Armadillo/include"
)
You could install your Armadillo here:
$ENV{ProgramFiles}/Armadillo and define ProgramFiles
or
you can pass ARMADILLO_LIBRARY and ARMADILLO_INCLUDE_DIR to the cmake command.
or
you can modify the FindArmadillo.cmake
If we want to change the behavior of CMake's FindArmadillo, then my preference would be that we figure what modifications need to be made and submit a patch to them, rather than distributing our own FindArmadillo.cmake.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you're installing Armadillo in a non-standard location and you want
gadgetron to pick up that one, and not some other one, then you really
better know what you're doing.
I cannot agree more. That's why I am asking you guys since my knowledge of
cmake is very limited.
Are we talking about distributing a gadgetron specific
FindArmadillo.cmake? The one shipped with cmake 2.8.12 on my brew install
uses an environment variable like this:
Well, the issue I tried to raise here is rather Linux specific I would
say. On OSX or Windows, you would need to install 3rd party dependencies
like Armadillo or CUDA yourself, since none of these ships with the OS
anyway. However, for Linux and particularly "long term support" distros
such as Ubuntu 12.04 or CentOS 6, Armadillo is available in the main
archive and is very outdated for use with Gadgetron. This requires to
compile and install from source in a non-standard location. I personally
install them straight in /usr/local (which is what it is meant for), others
may prefer /usr/local/{$LIBNAME}, which is the convention picked up by
ISMRMRD, Gadgetron or MATLAB.
I suggested that Gadgetron's cmake could be made aware of that, and look
for other conventional places such as /usr/local (popular in Linux) or
/opt/local (popular in OSX, used by Macports). Regarding how to implement
that properly, i.e. with HINTS or a modification of FindArmadillo.cmake, I
am probably too inexperienced to tell. I went for HINTS as a temporary fix
and it worked for me.
NOTE: Installation of Armadillo from source defaults to /usr not
/usr/local, so for anyone trying this, be careful to supply an adequate
prefix at config time when building Armadillo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have backported a more recent version of armadillo (built from the Saucy package) into the Gadgetron PPA, which potentially avoid manual compilation. Still, this only addresses this issue for stable Ubuntu flavours, not other distros such as CentOS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My understanding is that it is only the moco CPU gadget that requires Armadillo > 3.819.
The other things that use armadillo are fine with earlier versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which is enough to justify a backport to me. The concept of packaging is that you need to be able to compile everything and then dispatch the binaries into separate packages. So this dependency is required at least for package build time.
Then at install time, there could be no restriction on armadillo's version besides for the moco CPU, provided the latter can be split from the rest of the core libraries.
You seem to be insisting on this aspect, is that out of curiosity or are there any concerns you want to voice over ? If so, please do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've never done any packaging so I have no sense of how hard or easy any of it is. If it's not too much work for you to do the back port of armadillo then go for it. It's awesome that you can make it happen.
Sent with Good (www.good.com)
-----Original Message-----
From: Ghislain Vaillant [ghisvail@users.sf.netghisvail@users.sf.net]
Sent: Saturday, March 08, 2014 02:38 AM Eastern Standard Time
To: [gadgetron:discussion]
Subject: [gadgetron:discussion] Re: Allow for non system-standard location of Armadillo
Which is enough to justify a backport to me. The concept of packaging is that you need to be able to compile everything and then dispatch the binaries into separate packages. So this dependency is required at least for package build time.
Then at install time, there could be no restriction on armadillo's version besides for the moco CPU, provided the latter can be split from the rest of the core libraries.
You seem to be insisting on this aspect, is that out of curiosity or are there any concerns you want to voice over ? If so, please do.
It would be desirable to allow Gadgetron's cmake to detect newer
versions of armadillo installed in non system-standard locations, such
as /usr/local for instance.
Right now with Gadgetron 2.5, cmake only detects Armadillo if installed
in /usr and has a version greater than 3.8 something. In Ubuntu 12.04
(which ships with an outdated 2.x version), that means you need to
compile and install Armadillo from source. Since Armadillo has to be
located in /usr for Gadgetron to detect it, that means overwriting the
existing Ubuntu Armadillo with the user compiled one. This is not
recommended because of the potential for collision with the packaged
versions, and most guidelines advise to install user compiled libs in
locations such as /usr/local instead.
I have temporarily solved this by adding a HINTS parameter in the main
CmakeList for /usr/local. I am no cmake guru so this is probably not a
long term solution. However, for specific libraries where the
distributed ones are likely to be too outdated, such as Armadillo, it
would be a good idea to support other library locations, such as
/usr/local, /opt/local, etc...
Just wanted to trigger the discussion.
Ghislain
PS: I cannot post tickets to Gadgetron yet. Could you give me the right
privileges please ?
An environment variable would probably be a good choice, e.g. to look for ARMADILLO_HOME.
/ Thomas
Well both HINT and environment variable are good ideas.
On the tickets issue, we don't really use them. I can give you privileges
to make tickets, but nobody will pick them up.
On Wed, Mar 5, 2014 at 5:54 AM, "Thomas Sangild Sørensen" tsangild@users.sf.net wrote:
I find HINTS to be more appropriate for this specific case as they do what they are supposed to do: provide non-standard locations which can potentially override the standard system path.
Environment variables are, I believe, better suited for dependencies such as CULA, where a custom compilation will definitely be required.
We can have both, right? It is not that one is more appropriate than the other, is it?
Sent from a mobile device - please excuse brevity and/or typos.
If you're installing Armadillo in a non-standard location and you want gadgetron to pick up that one, and not some other one, then you really better know what you're doing.
Are we talking about distributing a gadgetron specific FindArmadillo.cmake? The one shipped with cmake 2.8.12 on my brew install uses an environment variable like this:
# UNIX paths are standard, no need to write.
find_library(ARMADILLO_LIBRARY
NAMES armadillo
PATHS "$ENV{ProgramFiles}/Armadillo/lib" "$ENV{ProgramFiles}/Armadillo/lib64"
"$ENV{ProgramFiles}/Armadillo"
)
find_path(ARMADILLO_INCLUDE_DIR
NAMES armadillo
PATHS "$ENV{ProgramFiles}/Armadillo/include"
)
You could install your Armadillo here:
$ENV{ProgramFiles}/Armadillo and define ProgramFiles
or
you can pass ARMADILLO_LIBRARY and ARMADILLO_INCLUDE_DIR to the cmake command.
or
you can modify the FindArmadillo.cmake
If we want to change the behavior of CMake's FindArmadillo, then my preference would be that we figure what modifications need to be made and submit a patch to them, rather than distributing our own FindArmadillo.cmake.
2014-03-05 15:23 GMT+00:00 Souheil Inati inatisj@users.sf.net:
I suggested that Gadgetron's cmake could be made aware of that, and look
for other conventional places such as /usr/local (popular in Linux) or
/opt/local (popular in OSX, used by Macports). Regarding how to implement
that properly, i.e. with HINTS or a modification of FindArmadillo.cmake, I
am probably too inexperienced to tell. I went for HINTS as a temporary fix
and it worked for me.
NOTE: Installation of Armadillo from source defaults to /usr not
/usr/local, so for anyone trying this, be careful to supply an adequate
prefix at config time when building Armadillo.
I have backported a more recent version of armadillo (built from the Saucy package) into the Gadgetron PPA, which potentially avoid manual compilation. Still, this only addresses this issue for stable Ubuntu flavours, not other distros such as CentOS.
Is a newer version of Armadillo necessary?
According to Thomas (we had that discussion a while back) it was. No idea
about the specific reason though.
Besides, Gadgetron's cmake currently detects Armadillo but rejects any
version below 3.8.something if I remember well.
2014-03-07 21:44 GMT+00:00 Souheil Inati inatisj@users.sf.net:
My understanding is that it is only the moco CPU gadget that requires Armadillo > 3.819.
The other things that use armadillo are fine with earlier versions.
Which is enough to justify a backport to me. The concept of packaging is that you need to be able to compile everything and then dispatch the binaries into separate packages. So this dependency is required at least for package build time.
Then at install time, there could be no restriction on armadillo's version besides for the moco CPU, provided the latter can be split from the rest of the core libraries.
You seem to be insisting on this aspect, is that out of curiosity or are there any concerns you want to voice over ? If so, please do.
I've never done any packaging so I have no sense of how hard or easy any of it is. If it's not too much work for you to do the back port of armadillo then go for it. It's awesome that you can make it happen.
Sent with Good (www.good.com)
-----Original Message-----
From: Ghislain Vaillant [ghisvail@users.sf.netghisvail@users.sf.net]
Sent: Saturday, March 08, 2014 02:38 AM Eastern Standard Time
To: [gadgetron:discussion]
Subject: [gadgetron:discussion] Re: Allow for non system-standard location of Armadillo
Which is enough to justify a backport to me. The concept of packaging is that you need to be able to compile everything and then dispatch the binaries into separate packages. So this dependency is required at least for package build time.
Then at install time, there could be no restriction on armadillo's version besides for the moco CPU, provided the latter can be split from the rest of the core libraries.
You seem to be insisting on this aspect, is that out of curiosity or are there any concerns you want to voice over ? If so, please do.
Allow for non system-standard location of Armadillohttps://sourceforge.net/p/gadgetron/discussion/general/thread/19c5f829/?limit=25#732b/8d4b/64d9/826e/2bc9
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gadgetron/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/