cmake

cmake

[Sage Weil]

We are switching from autotools to cmake on the master branch. Any 
builds done post-jewel will be cmake and not autotools based.  Jewel and 
older releases will still be built with autotools the old way.

The README.md in the master branch has been updated with new developer 
build instructions.  Please take a look:

	https://github.com/ceph/ceph/blob/master/README.md

If you are doing development, please switch to using cmake (i.e., 
run do_cmake.sh) now.  Running vstart.sh is a little different and it 
takes some getting used to.

If there is anything that doesn't work that is part of your developer 
workflow, we need to fix it now, before the autotools support is removed 
and you're unable to work!  This is hopefully a week or two away.

Current status:

 - gitbuilders mostly using make-dist instead of 'make dist' 
   (autotools) to generate release tarballs
 - wip-cmake-debian building debs with cmake
 - rpm coming shortly
 - release build tool update last, followed by a 11.0.0 release.

Thank you!
sage

Re: cmake

[Willem Jan Withagen]

On 27-6-2016 19:50, Sage Weil wrote:
> We are switching from autotools to cmake on the master branch. Any 
> builds done post-jewel will be cmake and not autotools based.  Jewel and 
> older releases will still be built with autotools the old way.
> 
> The README.md in the master branch has been updated with new developer 
> build instructions.  Please take a look:
> 
> 	https://github.com/ceph/ceph/blob/master/README.md
> 
> If you are doing development, please switch to using cmake (i.e., 
> run do_cmake.sh) now.  Running vstart.sh is a little different and it 
> takes some getting used to.
> 
> If there is anything that doesn't work that is part of your developer 
> workflow, we need to fix it now, before the autotools support is removed 
> and you're unable to work!  This is hopefully a week or two away.

Hi Sage,

Although i appreciate and understand the desire to move to cmake.
Really ripping out the automake stuff would put me in the situation
where I have no more building environment until all the cmake tweaks for
FreeBSD are in place.

An while I'll start working on it, time is rather scarce atm.
So please disable but please keep it around for a bit longer...

Thanx,
--WjW

Re: cmake

[Willem Jan Withagen]

On 28-6-2016 09:35, Willem Jan Withagen wrote:
> On 27-6-2016 19:50, Sage Weil wrote:
>> We are switching from autotools to cmake on the master branch. Any 
>> builds done post-jewel will be cmake and not autotools based.  Jewel and 
>> older releases will still be built with autotools the old way.
>>
>> The README.md in the master branch has been updated with new developer 
>> build instructions.  Please take a look:
>>
>> 	https://github.com/ceph/ceph/blob/master/README.md
>>
>> If you are doing development, please switch to using cmake (i.e., 
>> run do_cmake.sh) now.  Running vstart.sh is a little different and it 
>> takes some getting used to.
>>
>> If there is anything that doesn't work that is part of your developer 
>> workflow, we need to fix it now, before the autotools support is removed 
>> and you're unable to work!  This is hopefully a week or two away.
> 
> Hi Sage,
> 
> Although i appreciate and understand the desire to move to cmake.
> Really ripping out the automake stuff would put me in the situation
> where I have no more building environment until all the cmake tweaks for
> FreeBSD are in place.
> 
> An while I'll start working on it, time is rather scarce atm.
> So please disable but please keep it around for a bit longer...
> 
> Thanx,
> --WjW

Started a separte wip to see how far it would go.
Needed to repair some things, like
 - Things not on FreeBSD: eg. blkid
 - Thing not working compatible: udev, AIO
 - cc tripping over warnings that Clang does not know
 - curl include path
 - uname -m returning amd64

But this one really has me:
====
CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
FUSE_LIBRARIES (ADVANCED)
    linked by target "rbd-fuse" in directory
	/usr/srcs/Ceph/work.cmake/ceph/src
====

in configure I'd say --without-fuse, but that does not really work here.
Same for RBD....

Any suggestions as to proceed? Preferably withotu fuse and RBD for the
moment? So my cmake env is more or less equal to the new cmake env.

Thanx,
--WjW

Re: cmake

[Willem Jan Withagen]

On 28-6-2016 10:41, Willem Jan Withagen wrote:
> But this one really has me:
> ====
> CMake Error: The following variables are used in this project, but they
> are set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the
> CMake files:
> FUSE_LIBRARIES (ADVANCED)
>     linked by target "rbd-fuse" in directory
> 	/usr/srcs/Ceph/work.cmake/ceph/src
> ====
> 
> in configure I'd say --without-fuse, but that does not really work here.
> Same for RBD....
> 
> Any suggestions as to proceed? Preferably withotu fuse and RBD for the
> moment? So my cmake env is more or less equal to the new cmake env.

Impolite to answer ones own questions:
-D WITH_<item>=OFF

However "" give:
CMake Error at src/test/bench/CMakeLists.txt:76 (install):
  install TARGETS given target "ceph_smalliobenchrbd" which does not
exist in
  this directory.

So got to tweek that.

--WjW

Re: cmake

[Sage Weil]

On Tue, 28 Jun 2016, Willem Jan Withagen wrote:
> On 27-6-2016 19:50, Sage Weil wrote:
> > We are switching from autotools to cmake on the master branch. Any 
> > builds done post-jewel will be cmake and not autotools based.  Jewel and 
> > older releases will still be built with autotools the old way.
> > 
> > The README.md in the master branch has been updated with new developer 
> > build instructions.  Please take a look:
> > 
> > 	https://github.com/ceph/ceph/blob/master/README.md
> > 
> > If you are doing development, please switch to using cmake (i.e., 
> > run do_cmake.sh) now.  Running vstart.sh is a little different and it 
> > takes some getting used to.
> > 
> > If there is anything that doesn't work that is part of your developer 
> > workflow, we need to fix it now, before the autotools support is removed 
> > and you're unable to work!  This is hopefully a week or two away.
> 
> Hi Sage,
> 
> Although i appreciate and understand the desire to move to cmake.
> Really ripping out the automake stuff would put me in the situation
> where I have no more building environment until all the cmake tweaks for
> FreeBSD are in place.
> 
> An while I'll start working on it, time is rather scarce atm.
> So please disable but please keep it around for a bit longer...

There is no particular need to remove any of the autotools stuff while 
anyone still relies on it, so don't worry.  I'm just making sure 
everyone starts using it now so that we can identify any gaps and 
avoid surprises and fragmentation of efforts later.

Thanks for taking a look!
sage

Re: cmake

[Willem Jan Withagen]

On 28-6-2016 15:42, Sage Weil wrote:
> On Tue, 28 Jun 2016, Willem Jan Withagen wrote:
>> On 27-6-2016 19:50, Sage Weil wrote:
>>> We are switching from autotools to cmake on the master branch. Any 
>>> builds done post-jewel will be cmake and not autotools based.  Jewel and 
>>> older releases will still be built with autotools the old way.
>>>
>>> The README.md in the master branch has been updated with new developer 
>>> build instructions.  Please take a look:
>>>
>>> 	https://github.com/ceph/ceph/blob/master/README.md
>>>
>>> If you are doing development, please switch to using cmake (i.e., 
>>> run do_cmake.sh) now.  Running vstart.sh is a little different and it 
>>> takes some getting used to.
>>>
>>> If there is anything that doesn't work that is part of your developer 
>>> workflow, we need to fix it now, before the autotools support is removed 
>>> and you're unable to work!  This is hopefully a week or two away.
>>
>> Hi Sage,
>>
>> Although i appreciate and understand the desire to move to cmake.
>> Really ripping out the automake stuff would put me in the situation
>> where I have no more building environment until all the cmake tweaks for
>> FreeBSD are in place.
>>
>> An while I'll start working on it, time is rather scarce atm.
>> So please disable but please keep it around for a bit longer...
> 
> There is no particular need to remove any of the autotools stuff while 
> anyone still relies on it, so don't worry.  I'm just making sure 
> everyone starts using it now so that we can identify any gaps and 
> avoid surprises and fragmentation of efforts later.
> 
> Thanks for taking a look!

Sort of feel like starting all over again, and hacking all FreeBSD
specials into the Make process.
But I've done that, so it does have steady progress.

--WjW

Re: cmake

[Willem Jan Withagen]

On 28-6-2016 18:05, Willem Jan Withagen wrote:
> On 28-6-2016 15:42, Sage Weil wrote:
>> On Tue, 28 Jun 2016, Willem Jan Withagen wrote:
>>> On 27-6-2016 19:50, Sage Weil wrote:
>>>> We are switching from autotools to cmake on the master branch. Any 
>>>> builds done post-jewel will be cmake and not autotools based.  Jewel and 
>>>> older releases will still be built with autotools the old way.
>>>>
>>>> The README.md in the master branch has been updated with new developer 
>>>> build instructions.  Please take a look:
>>>>
>>>> 	https://github.com/ceph/ceph/blob/master/README.md
>>>>
>>>> If you are doing development, please switch to using cmake (i.e., 
>>>> run do_cmake.sh) now.  Running vstart.sh is a little different and it 
>>>> takes some getting used to.
>>>>
>>>> If there is anything that doesn't work that is part of your developer 
>>>> workflow, we need to fix it now, before the autotools support is removed 
>>>> and you're unable to work!  This is hopefully a week or two away.
>>>
>>> Hi Sage,
>>>
>>> Although i appreciate and understand the desire to move to cmake.
>>> Really ripping out the automake stuff would put me in the situation
>>> where I have no more building environment until all the cmake tweaks for
>>> FreeBSD are in place.
>>>
>>> An while I'll start working on it, time is rather scarce atm.
>>> So please disable but please keep it around for a bit longer...
>>
>> There is no particular need to remove any of the autotools stuff while 
>> anyone still relies on it, so don't worry.  I'm just making sure 
>> everyone starts using it now so that we can identify any gaps and 
>> avoid surprises and fragmentation of efforts later.
>>
>> Thanks for taking a look!
> 
> Sort of feel like starting all over again, and hacking all FreeBSD
> specials into the Make process.
> But I've done that, so it does have steady progress.

First shot to be found in #10024

It does not compile all the way to the end. But I have a feeling that is
because of new/extra code that has little to do with Cmake.

Gladly change any parts for better.

And yes, it is way much less hackish that automake stuff.
I did not say easier, but the result should be a lot better to maintain.

--WjW

Re: cmake

[Willem Jan Withagen]

On 29-6-2016 18:51, Willem Jan Withagen wrote:
> On 28-6-2016 18:05, Willem Jan Withagen wrote:
>> On 28-6-2016 15:42, Sage Weil wrote:
>>> On Tue, 28 Jun 2016, Willem Jan Withagen wrote:
>>>> On 27-6-2016 19:50, Sage Weil wrote:
>>>>> We are switching from autotools to cmake on the master branch. Any 
>>>>> builds done post-jewel will be cmake and not autotools based.  Jewel and 
>>>>> older releases will still be built with autotools the old way.
>>>>>
>>>>> The README.md in the master branch has been updated with new developer 
>>>>> build instructions.  Please take a look:
>>>>>
>>>>> 	https://github.com/ceph/ceph/blob/master/README.md
>>>>>
>>>>> If you are doing development, please switch to using cmake (i.e., 
>>>>> run do_cmake.sh) now.  Running vstart.sh is a little different and it 
>>>>> takes some getting used to.
>>>>>
>>>>> If there is anything that doesn't work that is part of your developer 
>>>>> workflow, we need to fix it now, before the autotools support is removed 
>>>>> and you're unable to work!  This is hopefully a week or two away.
>>>>
>>>> Hi Sage,
>>>>
>>>> Although i appreciate and understand the desire to move to cmake.
>>>> Really ripping out the automake stuff would put me in the situation
>>>> where I have no more building environment until all the cmake tweaks for
>>>> FreeBSD are in place.
>>>>
>>>> An while I'll start working on it, time is rather scarce atm.
>>>> So please disable but please keep it around for a bit longer...
>>>
>>> There is no particular need to remove any of the autotools stuff while 
>>> anyone still relies on it, so don't worry.  I'm just making sure 
>>> everyone starts using it now so that we can identify any gaps and 
>>> avoid surprises and fragmentation of efforts later.
>>>
>>> Thanks for taking a look!
>>
>> Sort of feel like starting all over again, and hacking all FreeBSD
>> specials into the Make process.
>> But I've done that, so it does have steady progress.
> 
> First shot to be found in #10024
> 
> It does not compile all the way to the end. But I have a feeling that is
> because of new/extra code that has little to do with Cmake.
> 
> Gladly change any parts for better.
> 
> And yes, it is way much less hackish that automake stuff.
> I did not say easier, but the result should be a lot better to maintain.

Looks like I made building all the way to the end.
===
[100%] Building CXX object
src/test/system/CMakeFiles/ceph_test_rados_list_parallel.dir/rados_list_parallel.cc.o
[100%] Linking CXX executable ../../../bin/ceph_test_rados_list_parallel
c++: warning: argument unused during compilation:
'-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=2'
[100%] Built target ceph_test_rados_list_parallel
210.372u 32.331s 4:03.17 99.8%  45172+574k 18431+324012io 4169pf+0w
[/usr/srcs/Ceph/work.cmake/ceph] wjw@freetest.digiware.nl>
===

Time to evaluate the amount of damage there is in the CmakeList.txt
files. 8D

--WjW

Re: cmake

[Willem Jan Withagen]

On 28-6-2016 15:42, Sage Weil wrote:
> On Tue, 28 Jun 2016, Willem Jan Withagen wrote:
>> On 27-6-2016 19:50, Sage Weil wrote:
>>> We are switching from autotools to cmake on the master branch. Any 
>>> builds done post-jewel will be cmake and not autotools based.  Jewel and 
>>> older releases will still be built with autotools the old way.
>>>
>>> The README.md in the master branch has been updated with new developer 
>>> build instructions.  Please take a look:
>>>
>>> 	https://github.com/ceph/ceph/blob/master/README.md
>>>
>>> If you are doing development, please switch to using cmake (i.e., 
>>> run do_cmake.sh) now.  Running vstart.sh is a little different and it 
>>> takes some getting used to.
>>>
>>> If there is anything that doesn't work that is part of your developer 
>>> workflow, we need to fix it now, before the autotools support is removed 
>>> and you're unable to work!  This is hopefully a week or two away.
>>
>> Hi Sage,
>>
>> Although i appreciate and understand the desire to move to cmake.
>> Really ripping out the automake stuff would put me in the situation
>> where I have no more building environment until all the cmake tweaks for
>> FreeBSD are in place.
>>
>> An while I'll start working on it, time is rather scarce atm.
>> So please disable but please keep it around for a bit longer...
> 
> There is no particular need to remove any of the autotools stuff while 
> anyone still relies on it, so don't worry.  I'm just making sure 
> everyone starts using it now so that we can identify any gaps and 
> avoid surprises and fragmentation of efforts later.
> 
> Thanks for taking a look!

I'm at 8 fails of 132 tests.

Which is more or less what I have in my FreeBSD work. And I did not take
all FreeBSD-wip stuff to my cmake tree.

So I'm going to clean up, and then hopelully we can get tings in the tree.

--WjW

Re: cmake

[Casey Bodley]

On 06/27/2016 01:50 PM, Sage Weil wrote:
> We are switching from autotools to cmake on the master branch. Any
> builds done post-jewel will be cmake and not autotools based.  Jewel and
> older releases will still be built with autotools the old way.
>
> The README.md in the master branch has been updated with new developer
> build instructions.  Please take a look:
>
> 	https://github.com/ceph/ceph/blob/master/README.md
>
> If you are doing development, please switch to using cmake (i.e.,
> run do_cmake.sh) now.  Running vstart.sh is a little different and it
> takes some getting used to.
>
> If there is anything that doesn't work that is part of your developer
> workflow, we need to fix it now, before the autotools support is removed
> and you're unable to work!  This is hopefully a week or two away.
>
> Current status:
>
>   - gitbuilders mostly using make-dist instead of 'make dist'
>     (autotools) to generate release tarballs
>   - wip-cmake-debian building debs with cmake
>   - rpm coming shortly
>   - release build tool update last, followed by a 11.0.0 release.
>
> Thank you!
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

To those trying CMake, please note that autoconf generates a 
ceph/src/acconfig.h. You'll want to remove that header, or cmake builds 
will pull it in and get confused.

Build failures in rocksdb are also common for those switching. This 
seems to fix those issues: cd ceph/src/rocksdb; make clean

Casey

Re: cmake

[Mark Nelson]

On 06/28/2016 03:28 PM, Casey Bodley wrote:
>
> On 06/27/2016 01:50 PM, Sage Weil wrote:
>> We are switching from autotools to cmake on the master branch. Any
>> builds done post-jewel will be cmake and not autotools based.  Jewel and
>> older releases will still be built with autotools the old way.
>>
>> The README.md in the master branch has been updated with new developer
>> build instructions.  Please take a look:
>>
>>     https://github.com/ceph/ceph/blob/master/README.md
>>
>> If you are doing development, please switch to using cmake (i.e.,
>> run do_cmake.sh) now.  Running vstart.sh is a little different and it
>> takes some getting used to.
>>
>> If there is anything that doesn't work that is part of your developer
>> workflow, we need to fix it now, before the autotools support is removed
>> and you're unable to work!  This is hopefully a week or two away.
>>
>> Current status:
>>
>>   - gitbuilders mostly using make-dist instead of 'make dist'
>>     (autotools) to generate release tarballs
>>   - wip-cmake-debian building debs with cmake
>>   - rpm coming shortly
>>   - release build tool update last, followed by a 11.0.0 release.
>>
>> Thank you!
>> sage
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> To those trying CMake, please note that autoconf generates a
> ceph/src/acconfig.h. You'll want to remove that header, or cmake builds
> will pull it in and get confused.
>
> Build failures in rocksdb are also common for those switching. This
> seems to fix those issues: cd ceph/src/rocksdb; make clean

FWIW, this is a gotcha that folks using automake run into when the 
rocksdb submodule updates.  make clean; make top level doesn't fix it, 
you have to explicitly run make clean in the rocksdb directory.

>
> Casey
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[Willem Jan Withagen]

On 27-6-2016 19:50, Sage Weil wrote:
> We are switching from autotools to cmake on the master branch. Any 
> builds done post-jewel will be cmake and not autotools based.  Jewel and 
> older releases will still be built with autotools the old way.

Hi Sage,

Question about Cmake versions....

On FreeBSD cmake is version 3.5.2
My Centos box has 2.8.11

If there any "minimum" requirements here??

--WjW

Re: cmake

[Brad Hubbard]

On Mon, Jul 4, 2016 at 7:05 PM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> On 27-6-2016 19:50, Sage Weil wrote:
>> We are switching from autotools to cmake on the master branch. Any
>> builds done post-jewel will be cmake and not autotools based.  Jewel and
>> older releases will still be built with autotools the old way.
>
> Hi Sage,
>
> Question about Cmake versions....
>
> On FreeBSD cmake is version 3.5.2
> My Centos box has 2.8.11
>
> If there any "minimum" requirements here??

You should be fine.

[ceph] (master %)$ head -1 CMakeLists.txt
cmake_minimum_required(VERSION 2.8.11)

HTH,
Brad

>
> --WjW
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Cheers,
Brad

cmake

[Sage Weil]

The work to transition to cmake has stalled somewhat.  I've tried to use 
it a few times but keep running into issues that make it unusable for me.  
Not having make check is a big one, but I think the hackery required to 
get that going points to the underlying problem(s).

I seems like the main problem is that automake puts all build targets in 
src/ and cmake spreads them all over build/*.  This makes that you can't 
just add ./ to anything that would normally be in your path (or, 
PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh).  
There's a bunch of kludges in vstart.sh to make it work that I think 
mostly point to this issue (and the .libs things).  Is there simply an 
option we can give cmake to make it put built binaries directly in build/?

Stepping back a bit, it seems like the goals should be

1. Be able to completely replace autotools.  I don't fancy maintaining 
both in parallel.

2. Be able to run vstart etc from the build dir.

3. Be able to run ./ceph[-anything] from the build dir, or put the build 
dir in the path.  (I suppose we could rely in a make install step, but 
that seems like more hassle... hopefully it's not neceesary?)

4. make check has to work

5. Use make-dist.sh to generate a release tarball (not make dist)

6. gitbuilders use make-dist.sh and cmake to build packages

7. release process uses make-dist.sh and cmake to build a relelase

I'm probably missing something?

Should we set a target of doing the 10.0.2 or .3 with cmake?

sage

Re: cmake

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

Hi,

On 16/12/2015 18:33, Sage Weil wrote:
> The work to transition to cmake has stalled somewhat.  I've tried to use 
> it a few times but keep running into issues that make it unusable for me.  
> Not having make check is a big one, but I think the hackery required to 
> get that going points to the underlying problem(s).
> 
> I seems like the main problem is that automake puts all build targets in 
> src/ and cmake spreads them all over build/*.  This makes that you can't 
> just add ./ to anything that would normally be in your path (or, 
> PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh).  
> There's a bunch of kludges in vstart.sh to make it work that I think 
> mostly point to this issue (and the .libs things).  Is there simply an 
> option we can give cmake to make it put built binaries directly in build/?
> 
> Stepping back a bit, it seems like the goals should be
> 
> 1. Be able to completely replace autotools.  I don't fancy maintaining 
> both in parallel.
> 
> 2. Be able to run vstart etc from the build dir.
> 
> 3. Be able to run ./ceph[-anything] from the build dir, or put the build 
> dir in the path.  (I suppose we could rely in a make install step, but 
> that seems like more hassle... hopefully it's not neceesary?)
> 
> 4. make check has to work
> 
> 5. Use make-dist.sh to generate a release tarball (not make dist)
> 
> 6. gitbuilders use make-dist.sh and cmake to build packages
> 
> 7. release process uses make-dist.sh and cmake to build a relelase
> 
> I'm probably missing something?
> 
> Should we set a target of doing the 10.0.2 or .3 with cmake?

An intermediate step could be to switch from using make check to using make distcheck. Once this works, all issues related to out-of-tree build and make check will be resolved. And deprecating autotools in favor of cmake will be just about that.

My 2cts

> 
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: cmake

[John Spray]

On Wed, Dec 16, 2015 at 5:33 PM, Sage Weil <sweil@redhat.com> wrote:
> The work to transition to cmake has stalled somewhat.  I've tried to use
> it a few times but keep running into issues that make it unusable for me.
> Not having make check is a big one, but I think the hackery required to
> get that going points to the underlying problem(s).
>
> I seems like the main problem is that automake puts all build targets in
> src/ and cmake spreads them all over build/*.  This makes that you can't
> just add ./ to anything that would normally be in your path (or,
> PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh).
> There's a bunch of kludges in vstart.sh to make it work that I think
> mostly point to this issue (and the .libs things).  Is there simply an
> option we can give cmake to make it put built binaries directly in build/?
>
> Stepping back a bit, it seems like the goals should be
>
> 1. Be able to completely replace autotools.  I don't fancy maintaining
> both in parallel.

Yes!

> 2. Be able to run vstart etc from the build dir.

I'm currently doing this (i.e. being in the build dir and running
../src/vstart.sh), along with the vstart_runner.py for cephfs tests.
I did indeed have to make sure that vstart_runner was aware of the
differing binary paths though.

Though I'm obviously using just MDS+OSD, so I might be overstating the
extent to which it currently works.

> 3. Be able to run ./ceph[-anything] from the build dir, or put the build
> dir in the path.  (I suppose we could rely in a make install step, but
> that seems like more hassle... hopefully it's not neceesary?)

Shall we just put all our libs and binaries in one place?  This works for me:
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)

(to get a bin/ and a lib/ with absolutely everything in)

That way folks can either get used to typing bin/foo instead of ./foo,
or add bin/ to their path.

> 4. make check has to work
>
> 5. Use make-dist.sh to generate a release tarball (not make dist)
>
> 6. gitbuilders use make-dist.sh and cmake to build packages
>
> 7. release process uses make-dist.sh and cmake to build a relelase
>
> I'm probably missing something?
>
> Should we set a target of doing the 10.0.2 or .3 with cmake?
>
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[Sage Weil]

On Wed, 16 Dec 2015, John Spray wrote:
> On Wed, Dec 16, 2015 at 5:33 PM, Sage Weil <sweil@redhat.com> wrote:
> > The work to transition to cmake has stalled somewhat.  I've tried to use
> > it a few times but keep running into issues that make it unusable for me.
> > Not having make check is a big one, but I think the hackery required to
> > get that going points to the underlying problem(s).
> >
> > I seems like the main problem is that automake puts all build targets in
> > src/ and cmake spreads them all over build/*.  This makes that you can't
> > just add ./ to anything that would normally be in your path (or,
> > PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh).
> > There's a bunch of kludges in vstart.sh to make it work that I think
> > mostly point to this issue (and the .libs things).  Is there simply an
> > option we can give cmake to make it put built binaries directly in build/?
> >
> > Stepping back a bit, it seems like the goals should be
> >
> > 1. Be able to completely replace autotools.  I don't fancy maintaining
> > both in parallel.
> 
> Yes!
> 
> > 2. Be able to run vstart etc from the build dir.
> 
> I'm currently doing this (i.e. being in the build dir and running
> ../src/vstart.sh), along with the vstart_runner.py for cephfs tests.
> I did indeed have to make sure that vstart_runner was aware of the
> differing binary paths though.
> 
> Though I'm obviously using just MDS+OSD, so I might be overstating the
> extent to which it currently works.
> 
> > 3. Be able to run ./ceph[-anything] from the build dir, or put the build
> > dir in the path.  (I suppose we could rely in a make install step, but
> > that seems like more hassle... hopefully it's not neceesary?)
> 
> Shall we just put all our libs and binaries in one place?  This works for me:
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
> 
> (to get a bin/ and a lib/ with absolutely everything in)
> 
> That way folks can either get used to typing bin/foo instead of ./foo,
> or add bin/ to their path.

I like the sound of this... ^^  it sort of mirrors what a 
make install would do.

sage


> 
> > 4. make check has to work
> >
> > 5. Use make-dist.sh to generate a release tarball (not make dist)
> >
> > 6. gitbuilders use make-dist.sh and cmake to build packages
> >
> > 7. release process uses make-dist.sh and cmake to build a relelase
> >
> > I'm probably missing something?
> >
> > Should we set a target of doing the 10.0.2 or .3 with cmake?
> >
> > sage
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: cmake

[Yehuda Sadeh-Weinraub]

On Wed, Dec 16, 2015 at 9:33 AM, Sage Weil <sweil@redhat.com> wrote:
> The work to transition to cmake has stalled somewhat.  I've tried to use
> it a few times but keep running into issues that make it unusable for me.
> Not having make check is a big one, but I think the hackery required to
> get that going points to the underlying problem(s).
>
> I seems like the main problem is that automake puts all build targets in
> src/ and cmake spreads them all over build/*.  This makes that you can't
> just add ./ to anything that would normally be in your path (or,
> PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh).
> There's a bunch of kludges in vstart.sh to make it work that I think
> mostly point to this issue (and the .libs things).  Is there simply an
> option we can give cmake to make it put built binaries directly in build/?
>
> Stepping back a bit, it seems like the goals should be
>
> 1. Be able to completely replace autotools.  I don't fancy maintaining
> both in parallel.
>

Is cmake a viable option in all environments we expect ceph (or any
part of) to be compiled on? (e.g. aix, solaris, freebsd, different
linux arm distros, etc.)

> 2. Be able to run vstart etc from the build dir.

There's an awful hack currently in vstart.sh and stop.sh that checks
for CMakeCache.txt in the current work directory to verify whether we
built using cmake or autotools. Can we make this go away?
We can do something like having the build system create a
'ceph-setenv.sh' script that would set the env (or open a shelll) with
the appropriate paths.

>
> 3. Be able to run ./ceph[-anything] from the build dir, or put the build
> dir in the path.  (I suppose we could rely in a make install step, but
> that seems like more hassle... hopefully it's not neceesary?)
>
> 4. make check has to work
>
> 5. Use make-dist.sh to generate a release tarball (not make dist)
>
> 6. gitbuilders use make-dist.sh and cmake to build packages
>
> 7. release process uses make-dist.sh and cmake to build a relelase
>
> I'm probably missing something?
>
> Should we set a target of doing the 10.0.2 or .3 with cmake?
>
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[Matt Benjamin]

Hi,

responding to all these at once.

----- Original Message -----
> From: "Yehuda Sadeh-Weinraub" <yehuda@redhat.com>
> To: "Sage Weil" <sweil@redhat.com>
> Cc: "ceph-devel" <ceph-devel@vger.kernel.org>
> Sent: Wednesday, December 16, 2015 1:45:54 PM
> Subject: Re: cmake
> 
> On Wed, Dec 16, 2015 at 9:33 AM, Sage Weil <sweil@redhat.com> wrote:
> > The work to transition to cmake has stalled somewhat.  I've tried to use
> > it a few times but keep running into issues that make it unusable for me.
> > Not having make check is a big one, but I think the hackery required to
> > get that going points to the underlying problem(s).

I'm going to push for cmake work already in progress to be moved to the next milestone ASAP.

With respect to "make check" blockers, which contains the issue of where cmake puts built objects.  Ali, Casey, and I discussed this today at some length.  We think the current "hackery" to make cmake make check work "the same way" auto* did is long-term undesirable due to it mutating files in the src dir.  I have not assumed that it would be an improvement to put all objects built in a tree of submakes into a single dir, as automake does.  I do think it is essential that at least eventually, it makes it simple to operate on any object that is built, and simple to extend processes like make check.

Ali and Casey agree, but contend that the current make check work is "almost finished"--specifically, that it could be finished and a PR sent -this week-.  Rewriting it will take additional time.  They propose starting with finishing and documenting the current setup, then doing a larger cleanup.

What do others think?

Matt

> >
> > I seems like the main problem is that automake puts all build targets in
> > src/ and cmake spreads them all over build/*.  This makes that you can't
> > just add ./ to anything that would normally be in your path (or,
> > PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh).
> > There's a bunch of kludges in vstart.sh to make it work that I think
> > mostly point to this issue (and the .libs things).  Is there simply an
> > option we can give cmake to make it put built binaries directly in build/?
> >
> > Stepping back a bit, it seems like the goals should be
> >
> > 1. Be able to completely replace autotools.  I don't fancy maintaining
> > both in parallel.
> >
> 
> Is cmake a viable option in all environments we expect ceph (or any
> part of) to be compiled on? (e.g. aix, solaris, freebsd, different
> linux arm distros, etc.)

One cannot expect cmake to be pre-installed on those platforms, but it will work on every one you mentioned, some others, not to mention Windows.

> 
> > 2. Be able to run vstart etc from the build dir.
> 
> There's an awful hack currently in vstart.sh and stop.sh that checks
> for CMakeCache.txt in the current work directory to verify whether we
> built using cmake or autotools. Can we make this go away?
> We can do something like having the build system create a
> 'ceph-setenv.sh' script that would set the env (or open a shelll) with
> the appropriate paths.



> 
> >
> > 3. Be able to run ./ceph[-anything] from the build dir, or put the build
> > dir in the path.  (I suppose we could rely in a make install step, but
> > that seems like more hassle... hopefully it's not neceesary?)
> >
> > 4. make check has to work
> >
> > 5. Use make-dist.sh to generate a release tarball (not make dist)
> >
> > 6. gitbuilders use make-dist.sh and cmake to build packages
> >
> > 7. release process uses make-dist.sh and cmake to build a relelase
> >
> > I'm probably missing something?
> >
> > Should we set a target of doing the 10.0.2 or .3 with cmake?
> >
> > sage
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

Re: cmake

[Sage Weil]

On Wed, 16 Dec 2015, Matt Benjamin wrote:
> I'm going to push for cmake work already in progress to be moved to the 
> next milestone ASAP.
> 
> With respect to "make check" blockers, which contains the issue of where 
> cmake puts built objects.  Ali, Casey, and I discussed this today at 
> some length.  We think the current "hackery" to make cmake make check 
> work "the same way" auto* did is long-term undesirable due to it 
> mutating files in the src dir.  I have not assumed that it would be an 
> improvement to put all objects built in a tree of submakes into a single 
> dir, as automake does.  I do think it is essential that at least 
> eventually, it makes it simple to operate on any object that is built, 
> and simple to extend processes like make check.

All of the binaries eventually go into /usr[/local]/bin anyway.  Can we 
do the same here?  (I don't care where intermediate .lo or .o objects 
go...)

> Ali and Casey agree, but contend that the current make check work is 
> "almost finished"--specifically, that it could be finished and a PR sent 
> -this week-.  Rewriting it will take additional time.  They propose 
> starting with finishing and documenting the current setup, then doing a 
> larger cleanup.
> 
> What do others think?

I'd like to aim for what will work best long-term, and that undoubtable 
also includes some source tree reorganization/cleanup.  But.. it seems 
like John's suggestion would do the trick here?

sage


> 
> Matt
> 
> > >
> > > I seems like the main problem is that automake puts all build targets in
> > > src/ and cmake spreads them all over build/*.  This makes that you can't
> > > just add ./ to anything that would normally be in your path (or,
> > > PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh).
> > > There's a bunch of kludges in vstart.sh to make it work that I think
> > > mostly point to this issue (and the .libs things).  Is there simply an
> > > option we can give cmake to make it put built binaries directly in build/?
> > >
> > > Stepping back a bit, it seems like the goals should be
> > >
> > > 1. Be able to completely replace autotools.  I don't fancy maintaining
> > > both in parallel.
> > >
> > 
> > Is cmake a viable option in all environments we expect ceph (or any
> > part of) to be compiled on? (e.g. aix, solaris, freebsd, different
> > linux arm distros, etc.)
> 
> One cannot expect cmake to be pre-installed on those platforms, but it will work on every one you mentioned, some others, not to mention Windows.
> 
> > 
> > > 2. Be able to run vstart etc from the build dir.
> > 
> > There's an awful hack currently in vstart.sh and stop.sh that checks
> > for CMakeCache.txt in the current work directory to verify whether we
> > built using cmake or autotools. Can we make this go away?
> > We can do something like having the build system create a
> > 'ceph-setenv.sh' script that would set the env (or open a shelll) with
> > the appropriate paths.
> 
> 
> 
> > 
> > >
> > > 3. Be able to run ./ceph[-anything] from the build dir, or put the build
> > > dir in the path.  (I suppose we could rely in a make install step, but
> > > that seems like more hassle... hopefully it's not neceesary?)
> > >
> > > 4. make check has to work
> > >
> > > 5. Use make-dist.sh to generate a release tarball (not make dist)
> > >
> > > 6. gitbuilders use make-dist.sh and cmake to build packages
> > >
> > > 7. release process uses make-dist.sh and cmake to build a relelase
> > >
> > > I'm probably missing something?
> > >
> > > Should we set a target of doing the 10.0.2 or .3 with cmake?
> > >
> > > sage
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> -- 
> -- 
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
> 
> http://www.redhat.com/en/technologies/storage
> 
> tel.  734-707-0660
> fax.  734-769-8938
> cel.  734-216-5309
> 
> 

Re: cmake

[Willem Jan Withagen]

On 16-12-2015 20:38, Sage Weil wrote:
> On Wed, 16 Dec 2015, Matt Benjamin wrote:
>> I'm going to push for cmake work already in progress to be moved to the 
>> next milestone ASAP.
>>
>> With respect to "make check" blockers, which contains the issue of where 
>> cmake puts built objects.  Ali, Casey, and I discussed this today at 
>> some length.  We think the current "hackery" to make cmake make check 
>> work "the same way" auto* did is long-term undesirable due to it 
>> mutating files in the src dir.  I have not assumed that it would be an 
>> improvement to put all objects built in a tree of submakes into a single 
>> dir, as automake does.  I do think it is essential that at least 
>> eventually, it makes it simple to operate on any object that is built, 
>> and simple to extend processes like make check.
> 
> All of the binaries eventually go into /usr[/local]/bin anyway.  Can we 
> do the same here?  (I don't care where intermediate .lo or .o objects 
> go...)

Why not take it one step further and have something like:
	..../ceph/build/{bin,sbin,lib,libexec,etc,tmp,test,log,.....}

which would be separate tree part where all the stuff is build.
Cleaning up will then also become a lot easier.... ATM the stuff in .lib
is not cleaned, I think.
It would also allow to process scripts to fit the local OS by running it
thru m4/sed/awk/perl/...

Or if you prefer so, hang it of ..../ceph/src

But then again this might require something like: make install-build

--WjW

Re: cmake

[Willem Jan Withagen]

On 16-12-2015 19:45, Yehuda Sadeh-Weinraub wrote:

> Is cmake a viable option in all environments we expect ceph (or any
> part of) to be compiled on? (e.g. aix, solaris, freebsd, different
> linux arm distros, etc.)

Hi,

For FreeBSD it does not really matter much. Recently the native builder
has become bmake (and is called as make).
To build things for Ceph I needed to install gmake and actually call it
like that, aka. gmake check....
It is easily installed as a package, and currently I've worked out most
required packages. The ports building platform allow for specifying the
required packages, as well as specifying which make to use. This
includes using Cmake. If a package requires {C,f,g}make and that make is
lacking, the package system first installs it.

It is not easy to actually to accommodate for FreeBSD in the autotools
with the current configure.ac and stuff. But I haven't looked at the
Cmake stuff to see if it gets any easier.

--WjW

cmake

[Pete Zaitcev]

Dear All:

I'm trying to run cmake, in order to make sure my patches do not break it
(in particular WIP 5073 added source files). Result looks like this:

[zaitcev@lembas ceph-tip]$ cmake src
-- The C compiler identification is GNU 5.1.1
-- The CXX compiler identification is GNU 5.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:1 (include):
  include could not find load file:

    GetGitRevisionDescription


-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
CMake Warning (dev) at CMakeLists.txt:11 (add_definitions):
  Policy CMP0005 is not set: Preprocessor definition values are now escaped
  automatically.  Run "cmake --help-policy CMP0005" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:12 (add_definitions):
  Policy CMP0005 is not set: Preprocessor definition values are now escaped
  automatically.  Run "cmake --help-policy CMP0005" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

--  we do not have a modern/working yasm
-- Performing Test COMPILER_SUPPORTS_CXX11
-- Performing Test COMPILER_SUPPORTS_CXX11 - Success
CMake Error at CMakeLists.txt:95 (get_git_head_revision):
  Unknown CMake command "get_git_head_revision".


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 3.3)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "/q/zaitcev/ceph/ceph-tip/CMakeFiles/CMakeOutput.log".
[zaitcev@lembas ceph-tip]$ rpm -qa | grep -i cmake
extra-cmake-modules-5.16.0-1.fc23.noarch
cmake-3.3.2-1.fc23.x86_64
[zaitcev@lembas ceph-tip]$ 

Is this expected? Is my cmake incantation wrong?

Thanks,
-- Pete

Re: cmake

[Adam C. Emerson]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On 03/12/2015, Pete Zaitcev wrote:
> Dear All:
> 
> I'm trying to run cmake, in order to make sure my patches do not break it
> (in particular WIP 5073 added source files). Result looks like this:
> 
> [zaitcev@lembas ceph-tip]$ cmake src

I believe the problem is 'cmake src'

The ceph-tip/src/CMakeLists.txt file is meant to be called from the
ceph-tip/CMakeLists.txt file. I like to create a completely separate
build directory and build there. i think the most popular incantation is
something like:

  mkdir ceph-tip/build
  cd ceph-tile/build
  cmake ..
  make

-- 
Senior Software Engineer           Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC, Freenode}
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C  7C12 80F7 544B 90ED BFB9

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 603 bytes --]

Re: cmake

[Pete Zaitcev]

On Thu, 3 Dec 2015 17:30:21 -0500
"Adam C. Emerson" <aemerson@redhat.com> wrote:

> On 03/12/2015, Pete Zaitcev wrote:

> > I'm trying to run cmake, in order to make sure my patches do not break it
> > (in particular WIP 5073 added source files). Result looks like this:
> > 
> > [zaitcev@lembas ceph-tip]$ cmake src
> 
> I believe the problem is 'cmake src'

Thanks for the tip about the separate build directory and the top-level
CMakeLists.txt. However, it still fails like this:

[zaitcev@lembas build]$ cmake ..
CMake Error at CMakeLists.txt:1 (include):
  include could not find load file:

    GetGitRevisionDescription
...................

Do you know by any chance where it gets that include? Also, what's
your cmake --version?

Greetings,
-- Pete

Re: cmake

[Matt Benjamin]

Pete,

Could you share the branch you are trying to build?  (ceph/wip-5073 would not appear to be it.)

Matt

----- Original Message -----
> From: "Pete Zaitcev" <zaitcev@redhat.com>
> To: "Adam C. Emerson" <aemerson@redhat.com>
> Cc: ceph-devel@vger.kernel.org
> Sent: Thursday, December 3, 2015 7:03:47 PM
> Subject: Re: cmake
> 
> On Thu, 3 Dec 2015 17:30:21 -0500
> "Adam C. Emerson" <aemerson@redhat.com> wrote:
> 
> > On 03/12/2015, Pete Zaitcev wrote:
> 
> > > I'm trying to run cmake, in order to make sure my patches do not break it
> > > (in particular WIP 5073 added source files). Result looks like this:
> > > 
> > > [zaitcev@lembas ceph-tip]$ cmake src
> > 
> > I believe the problem is 'cmake src'
> 
> Thanks for the tip about the separate build directory and the top-level
> CMakeLists.txt. However, it still fails like this:
> 
> [zaitcev@lembas build]$ cmake ..
> CMake Error at CMakeLists.txt:1 (include):
>   include could not find load file:
> 
>     GetGitRevisionDescription
> ...................
> 
> Do you know by any chance where it gets that include? Also, what's
> your cmake --version?
> 
> Greetings,
> -- Pete
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

Re: cmake

[Pete Zaitcev]

On Thu, 3 Dec 2015 19:26:52 -0500 (EST)
Matt Benjamin <mbenjamin@redhat.com> wrote:

> Could you share the branch you are trying to build?  (ceph/wip-5073 would not appear to be it.)

It's the trunk with a few of my insignificant cleanups.

But I found a fix: deleting the CMakeFiles/ and CMakeCache.txt let
it run. Thanks again for the tip about the separate build directory.

-- Pete

Re: cmake

[Daniel Gryniewicz]

On Fri, Dec 4, 2015 at 3:59 AM, Pete Zaitcev <zaitcev@redhat.com> wrote:
> On Thu, 3 Dec 2015 19:26:52 -0500 (EST)
> Matt Benjamin <mbenjamin@redhat.com> wrote:
>
>> Could you share the branch you are trying to build?  (ceph/wip-5073 would not appear to be it.)
>
> It's the trunk with a few of my insignificant cleanups.
>
> But I found a fix: deleting the CMakeFiles/ and CMakeCache.txt let
> it run. Thanks again for the tip about the separate build directory.
>

FWIW, many cmake issues can be fixed by nuking the cmake generated
files.  This is one of the big advantages to a separate build dir,
since the simplest way to do this is to nuke the build dir.

Daniel

Re: cmake

[Matt Benjamin]

I always run cmake from a build directory which is not the root, usually "build" in the root, so my minimal invocation would be "mkdir build; cd build; cmake ../src"--I'd at least try that, though I wouldn't have thought build location could affect something this basic (and it would be a bug).

Matt

----- Original Message -----
> From: "Pete Zaitcev" <zaitcev@redhat.com>
> To: ceph-devel@vger.kernel.org
> Sent: Thursday, December 3, 2015 5:24:36 PM
> Subject: cmake
> 
> Dear All:
> 
> I'm trying to run cmake, in order to make sure my patches do not break it
> (in particular WIP 5073 added source files). Result looks like this:
> 
> [zaitcev@lembas ceph-tip]$ cmake src
> -- The C compiler identification is GNU 5.1.1
> -- The CXX compiler identification is GNU 5.1.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> CMake Error at CMakeLists.txt:1 (include):
>   include could not find load file:
> 
>     GetGitRevisionDescription
> 
> 
> -- The ASM compiler identification is GNU
> -- Found assembler: /usr/bin/cc
> CMake Warning (dev) at CMakeLists.txt:11 (add_definitions):
>   Policy CMP0005 is not set: Preprocessor definition values are now escaped
>   automatically.  Run "cmake --help-policy CMP0005" for policy details.  Use
>   the cmake_policy command to set the policy and suppress this warning.
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> CMake Warning (dev) at CMakeLists.txt:12 (add_definitions):
>   Policy CMP0005 is not set: Preprocessor definition values are now escaped
>   automatically.  Run "cmake --help-policy CMP0005" for policy details.  Use
>   the cmake_policy command to set the policy and suppress this warning.
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> --  we do not have a modern/working yasm
> -- Performing Test COMPILER_SUPPORTS_CXX11
> -- Performing Test COMPILER_SUPPORTS_CXX11 - Success
> CMake Error at CMakeLists.txt:95 (get_git_head_revision):
>   Unknown CMake command "get_git_head_revision".
> 
> 
> CMake Warning (dev) in CMakeLists.txt:
>   No cmake_minimum_required command is present.  A line of code such as
> 
>     cmake_minimum_required(VERSION 3.3)
> 
>   should be added at the top of the file.  The version specified may be lower
>   if you wish to support older CMake versions for this project.  For more
>   information run "cmake --help-policy CMP0000".
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> -- Configuring incomplete, errors occurred!
> See also "/q/zaitcev/ceph/ceph-tip/CMakeFiles/CMakeOutput.log".
> [zaitcev@lembas ceph-tip]$ rpm -qa | grep -i cmake
> extra-cmake-modules-5.16.0-1.fc23.noarch
> cmake-3.3.2-1.fc23.x86_64
> [zaitcev@lembas ceph-tip]$
> 
> Is this expected? Is my cmake incantation wrong?
> 
> Thanks,
> -- Pete
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

Re: cmake

[Matt Benjamin]

sorry, "cmake .." for Ceph's setup.

Matt

----- Original Message -----
> From: "Matt Benjamin" <mbenjamin@redhat.com>
> To: "Pete Zaitcev" <zaitcev@redhat.com>
> Cc: ceph-devel@vger.kernel.org
> Sent: Thursday, December 3, 2015 5:30:28 PM
> Subject: Re: cmake
> 
> I always run cmake from a build directory which is not the root, usually
> "build" in the root, so my minimal invocation would be "mkdir build; cd
> build; cmake ../src"--I'd at least try that, though I wouldn't have thought
> build location could affect something this basic (and it would be a bug).
> 
> Matt
> 
> ----- Original Message -----
> > From: "Pete Zaitcev" <zaitcev@redhat.com>
> > To: ceph-devel@vger.kernel.org
> > Sent: Thursday, December 3, 2015 5:24:36 PM
> > Subject: cmake
> > 
> > Dear All:
> > 
> > I'm trying to run cmake, in order to make sure my patches do not break it
> > (in particular WIP 5073 added source files). Result looks like this:
> > 
> > [zaitcev@lembas ceph-tip]$ cmake src
> > -- The C compiler identification is GNU 5.1.1
> > -- The CXX compiler identification is GNU 5.1.1
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > CMake Error at CMakeLists.txt:1 (include):
> >   include could not find load file:
> > 
> >     GetGitRevisionDescription
> > 
> > 
> > -- The ASM compiler identification is GNU
> > -- Found assembler: /usr/bin/cc
> > CMake Warning (dev) at CMakeLists.txt:11 (add_definitions):
> >   Policy CMP0005 is not set: Preprocessor definition values are now escaped
> >   automatically.  Run "cmake --help-policy CMP0005" for policy details.
> >   Use
> >   the cmake_policy command to set the policy and suppress this warning.
> > This warning is for project developers.  Use -Wno-dev to suppress it.
> > 
> > CMake Warning (dev) at CMakeLists.txt:12 (add_definitions):
> >   Policy CMP0005 is not set: Preprocessor definition values are now escaped
> >   automatically.  Run "cmake --help-policy CMP0005" for policy details.
> >   Use
> >   the cmake_policy command to set the policy and suppress this warning.
> > This warning is for project developers.  Use -Wno-dev to suppress it.
> > 
> > --  we do not have a modern/working yasm
> > -- Performing Test COMPILER_SUPPORTS_CXX11
> > -- Performing Test COMPILER_SUPPORTS_CXX11 - Success
> > CMake Error at CMakeLists.txt:95 (get_git_head_revision):
> >   Unknown CMake command "get_git_head_revision".
> > 
> > 
> > CMake Warning (dev) in CMakeLists.txt:
> >   No cmake_minimum_required command is present.  A line of code such as
> > 
> >     cmake_minimum_required(VERSION 3.3)
> > 
> >   should be added at the top of the file.  The version specified may be
> >   lower
> >   if you wish to support older CMake versions for this project.  For more
> >   information run "cmake --help-policy CMP0000".
> > This warning is for project developers.  Use -Wno-dev to suppress it.
> > 
> > -- Configuring incomplete, errors occurred!
> > See also "/q/zaitcev/ceph/ceph-tip/CMakeFiles/CMakeOutput.log".
> > [zaitcev@lembas ceph-tip]$ rpm -qa | grep -i cmake
> > extra-cmake-modules-5.16.0-1.fc23.noarch
> > cmake-3.3.2-1.fc23.x86_64
> > [zaitcev@lembas ceph-tip]$
> > 
> > Is this expected? Is my cmake incantation wrong?
> > 
> > Thanks,
> > -- Pete
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> --
> --
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
> 
> http://www.redhat.com/en/technologies/storage
> 
> tel.  734-707-0660
> fax.  734-769-8938
> cel.  734-216-5309
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

cmake

[Shane Dixon]

I'm considering changing my projects over to cmake, but before I do, I
wanted to ask how good the cmake support is in OE.  I saw a recent
proposal to allow out-of-tree builds for cmake, but I'm not sure if that
happened or not.

Can I move forward with changing my projects to cmake and expect that it
will build correctly in OE?

-- 
Shane Dixon
Linux Engineer
Atmel Corporation
E-mail: shane.dixon@atmel.com

Re: cmake

[Jeremy Lainé]

Shane Dixon wrote:
> I'm considering changing my projects over to cmake, but before I do, I
> wanted to ask how good the cmake support is in OE.  I saw a recent
> proposal to allow out-of-tree builds for cmake, but I'm not sure if that
> happened or not.

At work we recently switched our projects over to CMake and they are building happily in
OE. Out-of-tree builds are indeed supported, see recipes/llvm/llvm.inc for an example.

-- 
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris

Re: cmake

[Otavio Salvador]

On Thu, Apr 2, 2009 at 2:30 AM, Jeremy Lainé
<jeremy.laine@bolloretelecom.eu> wrote:
> Shane Dixon wrote:
>> I'm considering changing my projects over to cmake, but before I do, I
>> wanted to ask how good the cmake support is in OE.  I saw a recent
>> proposal to allow out-of-tree builds for cmake, but I'm not sure if that
>> happened or not.
>
> At work we recently switched our projects over to CMake and they are building happily in
> OE. Out-of-tree builds are indeed supported, see recipes/llvm/llvm.inc for an example.

What do you mean by out-of-tree?

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: cmake

[Koen Kooi]

On 02-04-09 18:44, Otavio Salvador wrote:
> On Thu, Apr 2, 2009 at 2:30 AM, Jeremy Lainé
> <jeremy.laine@bolloretelecom.eu>  wrote:
>> Shane Dixon wrote:
>>> I'm considering changing my projects over to cmake, but before I do, I
>>> wanted to ask how good the cmake support is in OE.  I saw a recent
>>> proposal to allow out-of-tree builds for cmake, but I'm not sure if that
>>> happened or not.
>>
>> At work we recently switched our projects over to CMake and they are building happily in
>> OE. Out-of-tree builds are indeed supported, see recipes/llvm/llvm.inc for an example.
>
> What do you mean by out-of-tree?

S=work/foo-1.2-r0/foo-1.2/
B=work/foo-1.2-r0/build-foo-1.2

All generated stuff (makefiles, objects, binaries, etc) will end up in B 
so that S stays clean.

I'd like out-of-tree builds to be the default for autotools and cmake, 
but there are way too many broken autofoo and cmake using packages out 
there :(

regards,

Koen

Re: cmake

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

Hi Shane,

Shane Dixon schrieb:
> I'm considering changing my projects over to cmake, but before I do, I
> wanted to ask how good the cmake support is in OE.  I saw a recent
> proposal to allow out-of-tree builds for cmake, but I'm not sure if that
> happened or not.
> 
> Can I move forward with changing my projects to cmake and expect that it
> will build correctly in OE?
Go ahead, OE contains latest CMake release as well as out of tree build
functionality.

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 268 bytes --]