-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reduce number of things we build #12
Comments
For v0.9 we don't need Python gadgets or the Gadgetron MATLAB support. However, one of SIRFs strengths may turn out to be that it becomes an easy way to install Gadgetron and it is of particular appeal to users who like to use Python or MATLAB interfaces, hence, providing this 'service' could increase the appeal of SIRF.
I don't remember ever having to worry about single or double precision for fftw in the past when building ISMRMRD or Gadgetron, so I am not sure why that has become a problem.
On 23 Apr 2017, at 10:54, Kris Thielemans <notifications@github.com<mailto:notifications@github.com>> wrote:
I think we should save ourselves some time by disabling some options (like we did for STIR)
HDF5:
* HDF5_BUILD_EXAMPLES=OFF
* HDF5_BUILD_HL_LIB=OFF (to be tested)
* HDF5_BUILD_TOOLS=OFF (or are these useful?)
Gadgetron:
* Do we need Python gadgets? If not, we don’t need boost_python.
* Do we need Gadgetron’s MATLAB support?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#12>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AF2bn5hbzgswv_OGFZCnnGqokklcUV9cks5ry7p0gaJpZM4NFiL2>.
|
boost-python is currently required after all #15 |
As mentioned in #15, we currently switch Gadgetron's Python and Matlab support off. That saves us compilation/compatibility headaches. If we want to enable this later, then we'd have to introduce CMake variable like |
- use CMAKE_ARGS as opposed to explicit configure command. This means that any variables marked as superbuild will be passed through. In particular, it means that the "original" CMAKE_GENERATOR and CMAKE_GENERATOR_PLATFORM, which are essential on Windows, are now used to build HDF5. - make output of source and build consistent with other projects - no longer build examples and tools (see #12)
#64 reduced HDF5 build as suggested above. Need to introduce CMake options to enable them. |
@paskino, this seems a trivial thing to do, but it isn't really necessary. Therefore feel free to re-assign to v2.1 |
let's just create 2 new options and modify https://github.com/CCPPETMR/SIRF-SuperBuild/blob/7870f68b7d11c934d908516ff088527659f1cbc4/SuperBuild/External_HDF5.cmake#L83-L84 |
I think this is the only thing that was pending here, but as nobody ever asked for it, I will close this issue |
I think we should save ourselves some time by disabling some options (like we did for STIR)
HDF5:
Gadgetron:
The text was updated successfully, but these errors were encountered: