Cmake support for build managment

[lasch]

I'll review the changes and merge. Few comments that I have already:

• the changes in make.conf_dev and some Makefiles look as if they will break parts of the build for me. I suggest, we focus on getting the cmake working and then abandon the makefile based process.
• I'm seeing what looks like cmake settings files specific to John (CMake/jb.txt) is this the way it's usually done with cmake so that we will fill the CMake directory with various user and platform specific config files? Or was the intention to provide an initial example?

[biddisco]

Lars, also cc’d stefan so he can join in

• the changes in make.conf_dev and some Makefiles look as if they will break parts of the build for me. I suggest, we focus on getting the cmake working and then abandon the makefile based process. I haven’t touched (knowingly) these files, so perhaps stefan did something with them as he started getting the build going using your makefile. I never even tried using them!
• I'm seeing what looks like cmake settings files specific to John (CMake/jb.txt) is this the way it's usually done with cmake so that we will fill the CMake directory with various user and platform specific config files? Or was the intention to provide an initial example?

No, I committed that file as a way of keeping a memory of what setting I’m using to initialize my builds. Due to previous experiences with the system where I tried a million different combinations of compiler/flags/library versions (boost/hwloc/etc) I thought I’d make a note of my current working build setup (not just for skv, but in general), so that when I next break everything I can refer back to it.

Your comment on getting the cmake build to work first is great. Please feel free to change any of my stuff, I just eyeballed the makefiles and took what I though was necessary, yesterday I played with adding an option for the SKV_FOR_NONBGQ to see if that was causing the it_api segfault, but didn’t have success getting past the failure.

If you are able to build and run tests using the cmake setup, then that’d be a great step for us as we use cmake for everything and have many projects depending on each other and using the same build system etc,.

JB

— Reply to this email directly or view it on GitHubhttps://github.com/Scalable-Key-Value/code/pull/1#issuecomment-52752567.

[biddisco]

also

is this the way it's usually done with cmake so that we will fill the CMake directory with various user and platform specific config files? Or was the intention to provide an initial example? <

since we’re using a small number of systems, it is reasonable to put config files specific to the platform. You see the BGAS-MVAPICH file I put in there. Ideally the cmake stuff should be generalized, but during the initial phases, you can put in platform/machine specific stuff and gradually move them into custom config. To answer directly. Yes, It is reasonably common to keep platform/user specifi settings in cmake config files and then the user can run a build and include on the command line they’re own setting file. usualy something like BGAS-CSCS or BGAS-IBM-Zurich, or something can be included as these files will not change too often. As upgrades take place and locations of files change, they need to be generalized/maintained, but it is fine to have them

JB

From: Biddiscombe, John A. Sent: 20 August 2014 11:29 To: 'Scalable-Key-Value/code'; Scalable-Key-Value/code Cc: Stefan Eilemann Subject: RE: [code] Cmake support for build managment (#1)

Lars, also cc’d stefan so he can join in

• the changes in make.conf_dev and some Makefiles look as if they will break parts of the build for me. I suggest, we focus on getting the cmake working and then abandon the makefile based process. I haven’t touched (knowingly) these files, so perhaps stefan did something with them as he started getting the build going using your makefile. I never even tried using them!
• I'm seeing what looks like cmake settings files specific to John (CMake/jb.txt) is this the way it's usually done with cmake so that we will fill the CMake directory with various user and platform specific config files? Or was the intention to provide an initial example?

No, I committed that file as a way of keeping a memory of what setting I’m using to initialize my builds. Due to previous experiences with the system where I tried a million different combinations of compiler/flags/library versions (boost/hwloc/etc) I thought I’d make a note of my current working build setup (not just for skv, but in general), so that when I next break everything I can refer back to it.

Your comment on getting the cmake build to work first is great. Please feel free to change any of my stuff, I just eyeballed the makefiles and took what I though was necessary, yesterday I played with adding an option for the SKV_FOR_NONBGQ to see if that was causing the it_api segfault, but didn’t have success getting past the failure.

If you are able to build and run tests using the cmake setup, then that’d be a great step for us as we use cmake for everything and have many projects depending on each other and using the same build system etc,.

JB

— Reply to this email directly or view it on GitHubhttps://github.com/Scalable-Key-Value/code/pull/1#issuecomment-52752567.

[eile]

focus on getting the cmake working and then abandon the makefile based process.

Agreed, I'll revert the make changes.

[eile]

John, please pick 445a9d1 from my fork into this PR.

[biddisco]

Should be there now

From: Stefan Eilemann [mailto:notifications@github.com] Sent: 20 August 2014 13:48 To: Scalable-Key-Value/code Cc: Biddiscombe, John A. Subject: Re: [code] Cmake support for build managment (#1)

John, please pick 445a9d1https://github.com/Scalable-Key-Value/code/commit/445a9d108a6d85e302b4acaa689d17d9a8ac1ab4 from my fork into this PR.

— Reply to this email directly or view it on GitHubhttps://github.com/Scalable-Key-Value/code/pull/1#issuecomment-52764713.

[lasch]

Thanks Stefan and John. Working on the merge, I found the minimum cmake version is set to 2.8. Unfortunately, our default env (RHEL 6.5) provides only cmake 2.6. Do you suggest to require (RHEL-)users to install their own newer version or do you see a way to relax the minimum requirement? Any special features included from 2.8?

[biddisco]

I don’t remember if we are using anything 2.8 or newer (probably in the Cmake/common subdir that Stefan pulled i).

However, building your own cmake is so easy, that I always use my own. Just download the tarball, configure and make and then off you go with that one.

Do you anticipate (at the moment) many other users than ourselves?

JB

From: Lars Schneidenbach [mailto:notifications@github.com] Sent: 20 August 2014 15:13 To: Scalable-Key-Value/code Cc: Biddiscombe, John A. Subject: Re: [code] Cmake support for build managment (#1)

Thanks Stefan and John. Working on the merge, I found the minimum cmake version is set to 2.8. Unfortunately, our default env (RHEL 6.5) provides only cmake 2.6. Do you suggest to require (RHEL-)users to install their own newer version or do you see a way to relax the minimum requirement? Any special features included from 2.8?

— Reply to this email directly or view it on GitHubhttps://github.com/Scalable-Key-Value/code/pull/1#issuecomment-52775539.

[lasch]

I'm less worried about additional users or my env - as you say, it's really easy to build and install a newer version of cmake. I'm more concerned about our automated build/test environment which requires a newer version of cmake too. It would also impact the BGAS installation scripts. I'll check the options for that. Should be doable.