search

eggplantbren / DNest3

Diffusive Nested Sampling
GNU General Public License v3.0
20 stars 6 forks source link

Reworked CMake build #11

Closed jdswinbank closed 10 years ago

jdswinbank commented 10 years ago

I built DNest3 on OSX 10.9 using CMake & following the instructions in README.md, which seemed to work. However, I then tried to build the examples:

$ make
g++ -O2 -Wall -Wextra -ansi -pedantic -DNDEBUG -I../../include -o main.o -c main.cpp
g++ -O2 -Wall -Wextra -ansi -pedantic -DNDEBUG -I../../include -o FitSine.o -c FitSine.cpp
g++ -O2 -Wall -Wextra -ansi -pedantic -DNDEBUG -I../../include -o Data.o -c Data.cpp
g++ -o main main.o FitSine.o Data.o -ldnest3 -lgsl -lgslcblas -lboost_thread -lboost_system -L../../lib
ld: warning: directory not found for option '-L../../lib'
ld: library not found for -ldnest3

There are actually four separate problems here:

I fixed this by extending the CMake build system to correctly build the examples (and also, if requested, the PDF manual). It was only after doing that that I realised there's a top-level Makefile which builds both the library and the examples in a consistent way, but still breaks on my system because it doesn't find Boost and GSL. Hohum.

eggplantbren commented 10 years ago

Hi John,

Thanks for your work. I am certainly no expert on this aspect of software development and it has prevented people using this software in the past. I will test it out and then likely merge your changes.

On Sat, Apr 19, 2014 at 12:25 PM, John Swinbank notifications@github.comwrote:

I built DNest3 on OSX 10.9 using CMake & following the instructions in README.md, which seemed to work. However, I then tried to build the examples:

$ make g++ -O2 -Wall -Wextra -ansi -pedantic -DNDEBUG -I../../include -o main.o -c main.cpp g++ -O2 -Wall -Wextra -ansi -pedantic -DNDEBUG -I../../include -o FitSine.o -c FitSine.cpp g++ -O2 -Wall -Wextra -ansi -pedantic -DNDEBUG -I../../include -o Data.o -c Data.cpp g++ -o main main.o FitSine.o Data.o -ldnest3 -lgsl -lgslcblas -lboost_thread -lboost_system -L../../lib ld: warning: directory not found for option '-L../../lib' ld: library not found for -ldnest3

There are actually four separate problems here:

  • libdnest3 is in ../../build, not ../../lib;
  • I need -L/opt/local/lib to find libgsl;
  • The Boost libraries on my system have an -mt suffix: -lboost_thread-mt and -lboost_system-mt;
  • CMake chose to use /usr/bin/c++ to build libdnest3, whereas the examples are build with /opt/local/bin/g++. This use different standard libraries (libc++ vs libstdc++): all sorts of fun chaos ensues.

I fixed this by extending the CMake build system to correctly build the examples (and also, if requested, the PDF manual). It was only after doing that that I realised there's a top-level Makefile which builds both the library and the examples in a consistent way, but still breaks on my system

because it doesn't find Boost and GSL. Hohum.

You can merge this Pull Request by running

git pull https://github.com/jdswinbank/DNest3 cmake

Or view, comment on, or merge it at:

https://github.com/eggplantbren/DNest3/pull/11 Commit Summary

  • Reworked CMake build system
  • Update build instructions
  • CMake build manual

File Changes

  • M CMakeLists.txthttps://github.com/eggplantbren/DNest3/pull/11/files#diff-0(142)
  • A Examples/CMakeLists.txthttps://github.com/eggplantbren/DNest3/pull/11/files#diff-1(3)
  • A Examples/FitSine/CMakeLists.txthttps://github.com/eggplantbren/DNest3/pull/11/files#diff-2(4)
  • A Examples/HarlemShake/CMakeLists.txthttps://github.com/eggplantbren/DNest3/pull/11/files#diff-3(3)
  • A Examples/SpikeSlab/CMakeLists.txthttps://github.com/eggplantbren/DNest3/pull/11/files#diff-4(3)
  • M README.mdhttps://github.com/eggplantbren/DNest3/pull/11/files#diff-5(70)
  • A cmake/FindGSL.cmakehttps://github.com/eggplantbren/DNest3/pull/11/files#diff-6(24)
  • A doc/CMakeLists.txthttps://github.com/eggplantbren/DNest3/pull/11/files#diff-7(15)

Patch Links:

— Reply to this email directly or view it on GitHubhttps://github.com/eggplantbren/DNest3/pull/11 .

Dr Brendon J. Brewer Department of Statistics, The University of Auckland, New Zealand Ph: +64 27 500 1336 Web: http://www.stat.auckland.ac.nz/~brewer/

eggplantbren commented 10 years ago

Thanks for doing this John. I have merged this into my repository and added an acknowledgement.

eggplantbren commented 10 years ago

Hi John,

A quick request. I noticed that your build process puts the Examples executables in the build directory. Is it possible to have them placed in the regular Examples directory, and be named 'main'? That would make it consistent with the alternative make-based build process (that only works on my computers ;-)) and also the PDF manual that I'm working on.

Cheers, Brendon

jdswinbank commented 10 years ago

Hi Brendon --

It looks like you've already got the examples going to the directories you want them in as of bf739150d1. The other thing you asked about was making them be named main. You should be able to do that by setting the OUTPUT_NAME property on the executables. For example, in Examples/HarlemShake/CMakeLists.txt:

set(EXECUTABLE_OUTPUT_PATH "${PROJECT_SOURCE_DIR}/Examples/HarlemShake")
add_executable (HarlemShake HarlemShake.cpp main.cpp)
set_target_properties (HarlemShake PROPERTIES OUTPUT_NAME main)
target_link_libraries (HarlemShake dnest3 ${DNEST_DEPS})

That said, one of the nice things about CMake is that it makes it easy to do an out of source build. I think this is particularly great because it means the build leaves your source tree pristine, and you can trivially recover from any errors by doing an rm -rf build and starting again. Once you start mixing products into your source, that becomes a lot harder. Of course, in this case it's only a matter of three executables so it's hardly a big deal, but it still gives me the shivers. :-)

Finally, maybe worth adding that, if you don't set EXECUTABLE_OUTPUT_PATH, then the executables will be placed relative to where you start the build, and there's no reason other than convention/convenience that that has to be in the directory build. Indeed, you can run it in the root of your tree:

$ cd DNest3
$ cmake .
$ make

That would arguably give the best of both worlds: executables end up where you have documented them, but it's still possible for those who prefer to build out-of-source. The downside is that now you have artefacts of the build process scattered across your whole tree.

Hope that helps -- feel free to ping me if I can be of any further use.

John

eggplantbren commented 10 years ago

Thanks again!

I can see the advantages of the out of source build. However if I leave my old Makefiles in here then a simple make clean will remove all the build stuff. Do you think that's safe enough?

On Sun, Jun 29, 2014 at 12:12 AM, John Swinbank notifications@github.com wrote:

Hi Brendon --

It looks like you've already got the examples going to the directories you want them in as of bf73915 https://github.com/eggplantbren/DNest3/commit/bf739150d1. The other thing you asked about was making them be named main. You should be able to do that by setting the OUTPUT_NAME property on the executables. For example, in Examples/FitSine/CMakeLists.txt:

set(EXECUTABLE_OUTPUT_PATH "${PROJECT_SOURCE_DIR}/Examples/HarlemShake")add_executable (HarlemShake HarlemShake.cpp main.cpp)set_target_properties (HarlemShake PROPERTIES OUTPUT_NAME main)target_link_libraries (HarlemShake dnest3 ${DNEST_DEPS})

That said, one of the nice things about CMake is that it makes it easy to do an out of source build http://cmake.org/Wiki/CMake_FAQ#What_is_an_.22out-of-source.22_build.3F. I think this is particularly great because it means the build leaves your source tree pristine, and you can trivially recover from any errors by doing an rm -rf build and starting again. Once you start mixing products into your source, that becomes a lot harder. Of course, in this it's only a matter of three executables, so it's hardly a big deal, but it still gives me the shivers. :-)

Finally, maybe worth adding that, if you don't set EXECUTABLE_OUTPUT_PATH, then the executables will be placed relative to where you start the build, and there's no reason other than convention/convenience that that has to be in the directory build. Indeed, you can run it in the root of your tree:

$ cd DNest3 $ cmake . $ make

That would arguably give the best of both worlds: executables end up where you have documented them, but it's still possible for those who prefer to build out-of-source. The downside is that now you have artefacts of the build process scattered across your whole tree.

Hope that helps -- feel free to ping me if I can be of any further use.

John

— Reply to this email directly or view it on GitHub https://github.com/eggplantbren/DNest3/pull/11#issuecomment-47425880.

Dr Brendon J. Brewer Department of Statistics, The University of Auckland, New Zealand Ph: +64 27 500 1336 Web: http://www.stat.auckland.ac.nz/~brewer/

jdswinbank commented 10 years ago

Sounds fine to me. I don't think it would be my preference aesthetically, but beyond that I see no reason to argue!