Re: cmake

[Sage Weil]

On Wed, 16 Dec 2015, John Spray wrote:
> On Wed, Dec 16, 2015 at 5:33 PM, 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.
> 
> 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 majord...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[John Spray]

On Wed, Dec 16, 2015 at 5:33 PM, 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.

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 majord...@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 majord...@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  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 majord...@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 majord...@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" <yeh...@redhat.com>
> To: "Sage Weil" <sw...@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 <sw...@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 majord...@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 majord...@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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[Loic Dachary]

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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre



signature.asc
Description: OpenPGP digital signature

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


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

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

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

Re: cmake

[Pete Zaitcev]

On Thu, 3 Dec 2015 19:26:52 -0500 (EST)
Matt Benjamin  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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[Daniel Gryniewicz]

On Fri, Dec 4, 2015 at 3:59 AM, Pete Zaitcev  wrote:
> On Thu, 3 Dec 2015 19:26:52 -0500 (EST)
> Matt Benjamin  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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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" 
> 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 CMP".
> 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 majord...@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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[Matt Benjamin]

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

Matt

- Original Message -
> From: "Matt Benjamin" <mbenja...@redhat.com>
> To: "Pete Zaitcev" <zait...@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" <zait...@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 CMP".
> > 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 majord...@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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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" <zait...@redhat.com>
> To: "Adam C. Emerson" <aemer...@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" <aemer...@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 majord...@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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cmake

[Pete Zaitcev]

On Thu, 3 Dec 2015 17:30:21 -0500
"Adam C. Emerson"  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CMake blueprint

[Ilya Dryomov]

On Wed, Mar 5, 2014 at 6:04 PM, Casey Bodley ca...@linuxbox.com wrote:
 Hi Ilya,

 Regarding the CMake blueprint at 
 http://wiki.ceph.com/Planning/Blueprints/Giant/CMake, we at The Linux Box are 
 excited to see more interest!  I know that we've made several improvements to 
 the CMakeLists on our local branches that haven't made it to our github 
 repository.  We'll get everything consolidated, and should have another push 
 ready sometime next week.

That's great to hear!  Looking forward to it.

Thanks,

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