-
Couldn't load subscription status.
- Fork 13
Adding cmake based build system (tested under Linux and Mac OSX) #3
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
Conversation
|
Hi @psteinb, can you please change it so that either CMAKE or NSIGHT works? |
|
I can do that. Basically nothing has changed with that regard, as the On 04/13/2015 11:19 PM, Stephan Preibisch wrote:
|
…w to build on OSX/Linux using cmake
|
Hi @StephanPreibisch, I updated the README.md accordingly. Please note that I'll do the same with |
* expanded standardCUDAfunctions.cu by a function that tries to find the GPU on the host with the highest compute capability, this function is used for the unit tests only (it assumes that this devices comes with the highest DRAM) * tests compile and run on Linux
…or GPU based convolution
…through, Linking against cuda.lib fails
…k there, need to make the tests work with dll though
…\n* include convolution3Dfft.h in standardCUDAfunctions.cu to make the definitions available to the library\n* link step fails due to wrong export/import of some symbols
|
@StephanPreibisch : as you can see I made some good advances on this front, I came up with a Win7 box and ran the multi-view deconvolution on Z1 data with the new reconstruction plugin. it picked up the dll that was produced with cmake alright! Tests on OSX are ongoing. Also, I added unit tests! I saw that other people (e.g. @nicost) also submitted PR(s) to build this library under windows. I would welcome more validation on this cmake based build setup if possible as I deem cmake the de facto standard. The current setup hence supports all 3 platforms out of the box!! @StephanPreibisch if you don't have time anymore to cope with this, I would offer to become a collaborator and manage the PRs etc on my own for this library (with git nothing is ever lost). we might also contemplate shipping prebuild libraries. The core of this library runs on the device anyhow, so there are no CPU based optimisations during compilation required to first order. |
|
@psteinb: Great effort! Indeed, it would be great to have a download site for binaries somewhere. I guess that there should be versions for each platform (inw64, win32, mac64, linux32, linux64) and for the different CUDA versions? I am not as big a fan of cmake as you are, and would prefer if the native build files can also be used directly without having to go through installing cmake. If I am not mistaken, cmake will create these, so it would be nice to have those available for download as well. |
|
@nicost : thank you for the flowers. I had to learn quite a lot to make the windows build work out. I am glad to hear that you would be interested in further updates to this branch. @StephanPreibisch I also welcome the request for having binaries shipped somehow (one might even think about including them in the https://github.com/bigdataviewer/SPIM_Registration jar). A problem I see is binary compatibility and mere combinatorics. For example, CUDA 7 does not support building/running 32-bit code on 64-bit Windows systems anymore. Building and running 32-bit apps on linux x86_64 is still supported however (haven't checked the situation for OSX). So given the list that you gave above, for cuda 7 that means we have 3 OSs aka a minimum of 3 binaries. Also, don't forget that CUDA7 has specific driver requirements. If we/I support CUDA 6.5 and CUDA 7, that list goes up to 5 OS and 32-bit,32-on-64-bit and 64-bit ABIs. That makes 8 binaries for CUDA-6.5 and 3 for CUDA-7. And the list goes on and on. Further, CUDA7 brings quite some good new features for FFT based convolutions. Are you actually using 32-bit systems in practice? And if so, why? I would suggest, that we pick 64bit systems and provide CUDA7 and CUDA6.5 binaries. That would be 6 packages. If people would like to have something else, we still have cmake. @StephanPreibisch as I have to justify my time outside of the HPC arena, we have to see if I can invest more time in this and who would support it. Regarding cmake: well, I don't love cmake as well, but it is the tool of choice for cross-platform builds. to be honest, installing it on Windows is as easy as "next->next->finish". feel free to give other build systems a try and submit a PR so I can be convinced. also, if you installed VS, CUDA and the nvidia driver, installing cmake is a piece of cake. I am not sure what you mean by "native build files". Are you referring to the generated MSVS solution files or the actual libraries? If the latter, see my comments above. I can provide the solutions as well, but they might be very specific to my system, so some tweaking might be required. |
|
@psteinb: Good plan to leave out 32-bit platforms (more of a habit for me to include these, since we always do. In this case, it 32-bit clearly does not make much practical sense). Having binaries available is critical, it does not matter much where (is it OK to add them to the github repository?) Regarding build files: yes, I mean the MSVS solution files. Even if they have to be modified, I personally would much prefer that over having to install cmake. However, I do remember that the cmake generated solutions are not easily modifiable by hand, so maybe simply add the solution files I build for those who do not want to use cmake? |
|
@psteinb I made you collaborator on this project ... so you can manage the pull requests yourself, please make sure it stays easy to compile under Ubuntu as well :) |
…g of boost check message
Adding cmake based build system (tested under Linux and Mac OSX), ready for release (tested under Win7 64, Linux and MacOSX 10.10)
No description provided.