Re: [CMake] cmake + ninja how to use several CPU cores?

[Bruce Stephens]

You might find it interesting to look at build.ninja. By the looks of
it there's a (phony) target guving the dependencies of the library.
(That's called cmake_object_order_depends_target_internal_lib) and
CMakeFiles/app.dir/main.cpp.o is depending on that.

Presumably the idea is that there's no point trying to compile
main.cpp before we could build the library, since (as in this case)
that might require generated headers which main.cpp might need.

If I get rid of the wait5 thing, then main.cpp gets compiled (using
"ninja -v CMakeFiles/app.dir/main.cpp.o") without the library. Just
the headers (and lib/lib1.cpp) get generated.

I think it's reasonable for CMake/Ninja to require the headers be
generated, especially since main.cpp does include one of them (though
CMake/Ninja doesn't know that until later). lib/lib1.cpp is more
arguable, but I imagine there's no real distinction made: main.cpp.o
depends on all the dependencies of the libraries.

On Mon, 29 Jul 2019 at 10:34, Alan W. Irwin  wrote:
>
> On 2019-07-28 23:39-0700 Alan W. Irwin wrote:
>
> > @Both: I also plan to look at whether this issue exists for
> > the internal library case so more later when I get that
> > corresponding simple test project implemented.
>
> @Brad and David:
>
> I have now implemented a simple test project for the internal library
> case.  See the attached tarball (and please let me know if your input
> mail software chain allows you to receive that tarball).  In general I
> think this test case improves somewhat on Dave's test project by
> making the sleep more explicit at the CMake level, generating the
> headers explicitly rather than including them in the tarball,
> generating all header and source code files and the library (internal
> in this case) within the build tree rather than source tree (which
> considerably simplifies making a clean start), and by allowing the
> user to specify the -DBUILD_SHARED_LIBS=ON (or OFF) cmake option to
> choose whether the library is built shared on static.  (Of course,
> none of these improvements should affect the delayed compilation
> issue.)
>
> For this new simple test project, here are the results for the -G"Ninja" case 
> (when -DBUILD_SHARED_LIBS=ON is specified):
>
> irwin@merlin> ninja -j16 -v app
> [1/10] cd 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib
>  && sh 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/include_generator.sh
> [2/10] cd 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib
>  && sh 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/lib_generator.sh
> [3/10] cd 
> /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir 
> && sleep 5
> [4/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c lib/lib1.cpp
> [5/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c lib/lib3.cpp
> [6/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c lib/lib4.cpp
> [7/10] /usr/bin/c++  -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c lib/lib2.cpp
> [8/10] : && /usr/bin/c++ -fPIC-shared -Wl,-soname,libinternal_lib.so -o 
> libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o 
> CMakeFiles/internal_lib.dir/lib/lib2.cpp.o 
> CMakeFiles/internal_lib.dir/lib/lib3.cpp.o 
> CMakeFiles/internal_lib.dir/lib/lib4.cpp.o   && :
> [9/10] /usr/bin/c++   -Ilib  -MD -MT CMakeFiles/app.dir/main.cpp.o -MF 
> CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c 
> ../main.cpp
> [10/10] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o  -o app  
> -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir
>  libinternal_lib.so && :
>
> Note that the build of main.cpp.o is (unreasonably in my opinion) delayed to 
> step 9.
>
> And that build is similarly delayed in the -G"Unix Makefiles" case.
> That is this newly implemented test case for the internal library
> build shows exactly the same unexplained compilation delays for
> main.cpp for both -G"Ninja" and -G"Unix Makefiles" as David's test
> case for the external library build.
>
> @Brad and other CMake developers who might be lurking here:
>
> Can anybody explain why CMake has this delayed compilation "feature"
> for apps that depend on internal or external libraries, and if there
> is no compelling reason for it would it be straightforward to 

Re: [CMake] Question about looping inside a macro.

[Bruce Stephens]

This works:
macro(bsPrintList)
  foreach(l ${ARGN})
message(STATUS "List entry: ${l}")
  endforeach()
endmacro()

bsPrintList(foo bar baz)

On Tue, 4 Jun 2019 at 22:14, Steven Truppe  wrote:
>
> Hi everyone, like you know i'm relative new the cmake and i'm working my way 
> through the book and the documentation but there is something that i don't 
> understand in the docs.
>
> I just want to write a macro that uses as first argument a list and then 
> iterates over it.
>
> The docs show the example:
>
> macro(_BAR)
>   foreach(arg IN LISTS ARGN)
> [...]
>   endforeach()
> endmacro()
>
> So i wrote this macro:
>
> macro(bsPrintList list)
>
> foreach(l IN LISTS ARGN)
>
> message(STATUS "List entry: ${l})
>
> endforeach()
>
> endmacro()
>
>
> I tried all sorts of combinations like foreach(l ${list}) etc. but come to no 
> result =(.
>
>
> This is a really easy questin so i hope someone can explain to me what i'm 
> doing wrong here, next part i'm going to learn are functions and how to 
> handle their arguments...
>
>
> best regards!
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop.

[Bruce Stephens]

On Mon, 4 Mar 2019 at 04:00, Yu, Mingli  wrote:

> Is there any means to make the logic run in /source/sql/CMakeLists.txt
> before which is in /source/libmysqld/CMakeLists.txt?

Use a dependency between targets. There's a limitation/bug with things
that depend on files created by add_custom_command() in different
directories (different CMakeLists,txt files). So create a target for
the generated file (in the directory where it's created), and use
add_dependencies() for the thing that uses the file.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] if(ON) not considered true?

[Bruce Stephens]

The behaviour's controlled by CMP0012. (The documentation for if()
doesn't seem as helpful as it could be. It does seem to suggest that
ON, TRUE, etc., ought to be true, without mentioning CMP0012.)

On Sat, 26 Jan 2019 at 17:22, frodak17  wrote:
>
> $ cmake --version
> cmake version 3.13.2
>
> $ cmake -S src -B testON
> ON is ON
> -- Configuring done
> -- Generating done
> -- Build files have been written to:...
>
> $ cat src/CMakeLists.txt
> cmake_minimum_required(VERSION 3.12)
>
> project(sample C)
>
> if(ON)
>   message("ON is ON")
> endif()
>
> What version are you using?
>
> On Sat, Jan 26, 2019 at 10:39 AM Mario Emmenlauer  wrote:
>>
>>
>> Dear All,
>>
>> I'm plagued by an issue that I do not understand. An if-statement
>> (in a package configuration file) evaluates ON to false:
>>
>> IF(ON)
>> ...some code here
>> ENDIF()
>>
>> The part inside IF is *not* executed. Replacing ON by TRUE does not
>> help, only replacing it by 1 helps. Is this correct behaviour? I can
>> not understand this from the documentation. The docs seem to say "ON"
>> would be a valid token for true: 
>> https://cmake.org/cmake/help/v3.6/command/if.html
>>
>> The full user story is that in the package configuration I'd like to
>> treat shared libraries specially, so I use "IF(@BUILD_SHARED_LIBS@)".
>> The user configures the build with
>>
>> cmake -DBUILD_SHARED_LIBS=ON .
>>
>> so the package configuration gets resolved to "IF(ON)". I have not
>> too much control about the way users specify the options, so I'd
>> like to solve this on my end. If options should not keep the value
>> "ON", how can I cleanly resolve them to the corresponding number 0/1?
>>
>> Am I doing something wrong?
>>
>> All the best,
>>
>> Mario Emmenlauer
>>
>>
>> --
>> BioDataAnalysis GmbH, Mario Emmenlauer Tel. Office: +49-89-74677203
>> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
>> D-81669 Munich   http://www.biodataanalysis.de/
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Bruce Stephens]

On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey  wrote:
> Actually I think your idea does work. Why do you think it won't? I'm
> using it right now and so far it seems OK.

I assumed (without testing, admittedly) is that it would fail if
someone used -D to set the value,
then changed some CMakeLists.txt file, then executed the build command
again. I'd expect that
to rerun cmake to update the build files and I'd fear that you'd then
get BUILD_VERSION from
the CMakeLists.txt file rather than the value explicitly set.

However, I haven't tried it, and maybe it works fine (with the
generators you care about) even without
caching?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Bruce Stephens]

On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens
<bruce.r.steph...@gmail.com> wrote:
> You could do something like
>
> if(NOT "${BUILD_VERSION}")
>   set(BUILD_VERSION 1.2.3.4)
> endif()


That doesn't work at all, come to think of it. I suspect your best bet
is to handle
the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and
maybe "include(... OPTIONAL)"). That should allow whatever behaviour
you want.

I note that llvm's builds have the same sort of problem, so whatever
fix is required
isn't obvious even to obviously bright people. (That is, when the
version switched
from 4.0.0 to 5.0.0 my builds didn't change their version number. I
had to remove the
build directory and build again from clean.)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Bruce Stephens]

You could do something like

if(NOT "${BUILD_VERSION}")
  set(BUILD_VERSION 1.2.3.4)
endif()

On Mon, Apr 10, 2017 at 2:29 PM, Robert Dailey  wrote:
> I have a file called version.cmake that my root CMakeLists.txt
> includes. There is only a single line in this file:
>
> set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" )
>
> I have two scenarios where this version number setting needs to work
> slightly differently from a CMake perspective:
>
> 1. Our CI build server does a fresh clone of our repo, and generates
> from scratch. It sometimes needs to override the version number from
> the command line via arguments. So it will do:
>
> -D BUILD_VERSION=99.99.1.2
>
> This works since it's a cache variable. In fact, the current solution
> ONLY works well for this scenario (since it will allow overriding from
> command line, but also allow the file to set the value if it is not
> specified as a -D argument).
>
> 2. Local work machine builds. Local builds never override using -D,
> they always use what is in the version.cmake file. However, because
> it's a cache variable and I'm not using FORCE with set(), it never
> updates if I change the version and push it to origin. This is the
> missing requirement: it needs to update when the number (value)
> changes in version control
>
> I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on
> the command line, and if specified, it will set the BUILD_VERSION
> value to the overridden value. However, I don't like the idea of 2
> separate variables to manage this. Using a non-cache variable doesn't
> allow overriding with the same variable value on the command line
> either.
>
> What's the best solution here for my situation?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Handling generated headers

[Bruce Stephens]

Yes, that's the idea: I have custom commands (created with
add_custom_command) listing the headers in OUTPUT.

And there are source files which #include such headers.

I'd like it so that compiling such a source file would cause the
header to be generated.

Concretely, with a CMakeLists.txt like the attached, with the obvious
main.c (also attached), I'd like "ninja exe" to work.

I find that it does not.

After "ninja build-incl" (or "ninja incl.h") then "ninja exe" will
work. And then after removing incl.h,
"ninja exe" will recreate incl.h and then rebuild exe. (Presumably
ninja is caching some dependency information, likely
in its .ninja_deps file.) But correct recompilation (while obviously
desirable) doesn't seem sufficient; I want the first
build to work too.

(I'm also not sure why the add_custom_target is required, but it does
seem to be. Presumably without it CMake
can't see why the custom command might be used.)

In most cases I have a natural place where I need the things to be
built, so the custom target can have ALL DEPENDS
(rather than.the DEPENDS in the example). However, in some cases in
parallel builds I still end up with (sometimes)
source files not compiling because the needed headers haven't been generated.

As I say, so far this is OK: I can just generated dependencies
explicitly in a pre-CMake step. But handling cases where
main.c includes some source header which includes this generated
incl.h seems not easily doable.

If I'm not missing something silly and all this is expected behaviour
(as it appears to be) it's not a disaster. We can add
a few explicit dependencies and get things to work. But maybe I'm
missing something and this should work more
smoothly.


On Mon, Mar 27, 2017 at 4:08 PM, Michael Ellery <mellery...@gmail.com> wrote:
>
>> On Mar 27, 2017, at 6:31 AM, Bruce Stephens <bruce.r.steph...@gmail.com> 
>> wrote:
>>
>> I have a build with two or three tools that generate headers and
>> source files. Getting the source files compiled is easy enough: when
>> they're mentioned as source files (in add_library or add_executable)
>> the custom rule gets triggered.
>>
>> But that doesn't seem to be true for header files included by
>> non-generated source files, presumably because CMake's not looking at
>> those files, but rather Ninja is (presumably other generators will
>> behave similarly). If the (generated) header changes then anything
>> using
>> the source file gets rebuilt (as expected), but the first build seems
>> not to necessarily succeed (depending on accidents of when the
>> generated files are produced).
>>
>> Concretely, suppose I have an XML file compat.xml with a custom rule
>> to generate messages/Compat.h, and some source files which include
>> that header (which does not exist to begin with), I'd like a compile
>> of any of those source files to depend on messages/Compat.h such that
>> it'll be generated if necessary.
>>
>> That doesn't seem to happen automatically using the Ninja generator.
>> Is that expected, or have I messed something up?
>>
>> For the moment I'm assuming it's as expected and have a workaround: a
>> simple Python script that scans source files and creates a deps.cmake
>> with calls
>> to add_file_dependencies. (Fortunately all the generated headers have
>> simple patterns so accurately determining them is straightforward.)
>>
>> Unfortunately there are also (non-generated) header files which
>> include these headers and that seems harder to handle.
>> Calling add_file_dependencies on header files doesn't seem to work.
>>
>> It's not a showstopper: I can just explicitly add some dependencies.
>> And later, we'll probably split out some of these things so they'll
>> be separate builds. It seems a bit annoying, though. Am I missing some
>> better way to handle this?
>> --
>
>
> it’s not clear from your message — are you using add_custom_command() to 
> create the rule that generates the header from the XML? If you get all of the 
> parameters right to that command (like OUTPUT, DEPENDS, BYPRODUCTS..), then I 
> would expect this to work and the header should get generated before any 
> other source that needs it. In some cases you might need to explicitly 
> specify that a target depends on that header, but if at least ONE thing 
> depends on the header, the the add_custom_command rule should get executed.  
> You might also try running CMAKE with —trace and generating a verbose 
> makefile if you are still not seeing your custom command running when it 
> should.
>
> -Mike Ellery
cmake_minimum_required(VERSION 3.7)
add_executable(exe main.c)
target_include_directories(exe PUBLIC ${CMAKE_CUR

[CMake] Handling generated headers

[Bruce Stephens]

I have a build with two or three tools that generate headers and
source files. Getting the source files compiled is easy enough: when
they're mentioned as source files (in add_library or add_executable)
the custom rule gets triggered.

But that doesn't seem to be true for header files included by
non-generated source files, presumably because CMake's not looking at
those files, but rather Ninja is (presumably other generators will
behave similarly). If the (generated) header changes then anything
using
the source file gets rebuilt (as expected), but the first build seems
not to necessarily succeed (depending on accidents of when the
generated files are produced).

Concretely, suppose I have an XML file compat.xml with a custom rule
to generate messages/Compat.h, and some source files which include
that header (which does not exist to begin with), I'd like a compile
of any of those source files to depend on messages/Compat.h such that
it'll be generated if necessary.

That doesn't seem to happen automatically using the Ninja generator.
Is that expected, or have I messed something up?

For the moment I'm assuming it's as expected and have a workaround: a
simple Python script that scans source files and creates a deps.cmake
with calls
to add_file_dependencies. (Fortunately all the generated headers have
simple patterns so accurately determining them is straightforward.)

Unfortunately there are also (non-generated) header files which
include these headers and that seems harder to handle.
Calling add_file_dependencies on header files doesn't seem to work.

It's not a showstopper: I can just explicitly add some dependencies.
And later, we'll probably split out some of these things so they'll
be separate builds. It seems a bit annoying, though. Am I missing some
better way to handle this?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake source tree pollution ?

[Bruce Stephens]

Looks like https://github.com/redguardtoo/cpputils-cmake might be involved...

On Fri, Sep 9, 2016 at 5:04 PM, Vania Joloboff  wrote:
> On 09/09/2016 05:45 PM, Michael Ellery wrote:
>>
>> This kinda’ sounds like you are doing an in-source build. Are you certain
>> that your currrent/working directory is different from your source tree root
>> when you run cmake? The typical way of doing this is just to make a
>> subdirectory of your source root:
>>
>> mkdir my_build
>> cd my_build
>> cmake ..
>> make
>>
> Yes this is what I do. And indeed there is a  big Makefile with 730 lines
>  created in my build directory, that builds the software.
> The source directories get polluted only with the 5 lines Makefiles attached
> in my previous mail.
> It seems only one thing related to cpp-utils is writing where it should not.
> All binaries are built in my build directory.
>  I do have a full hierarchy of CMakefiles directories that contain what they
> should contain.
> The top level build/CMakefiles directory does contain the CMakeOutput.log
> file
> but I can't make sense of what is wrong at which point.
> It contains also a fille CMakeFiles/TargetDirectories.txt with the right
> directories
> I list below the first 5 lines. They are correct and you can see there is a
> build directory
> The source is in trunk
>
> /home/vjf/workspace/merging/simsoc/trunk/build/libsimsoc/tools/debugger/CMakeFiles/debugger.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/examples/SerialISS/CMakeFiles/build_serial_iss.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/utils/ISC/CMakeFiles/isc.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/examples/TI_AM1707/CMakeFiles/ti-am1707.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/examples/SPEAr/CMakeFiles/spear.dir
>
>
> The source directory (trunk) remains entirely clean,
> except for these strange 5 lines Makefiles.
>
> Vania
>
>
>>> On Sep 9, 2016, at 8:17 AM, Vania Joloboff 
>>> wrote:
>>>
>>> Hi,
>>>
>>> I have started to use CMake for my software.
>>> I build in a separate directory using :
>>> $> cmake -G "Unix Makefiles"  
>>>
>>> Everything is built correctly and the software works fine.
>>> However all of my source code directories get polluted.
>>> Into each source directory, a new Makefile is created.
>>> All of these Makefiles are identical. They are
>>>
>>> -
>>> # Generated by cpputils-cmake.
>>> include /flags.make
>>> .PHONY: check-syntax
>>> check-syntax:
>>> ${CC} -o /dev/null ${C_FLAGS} ${C_DEFINES} -I/usr/src/linux/include
>>> -DNDEBUG -S ${CHK_SOURCES}
>>> 
>>>
>>> Any clue ??
>>>
>>> Vania
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>
>>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake source tree pollution ?

[Bruce Stephens]

On Fri, Sep 9, 2016 at 4:45 PM, Michael Ellery  wrote:
> This kinda’ sounds like you are doing an in-source build. Are you certain 
> that your currrent/working directory is different from your source tree root 
> when you run cmake? The typical way of doing this is just to make a 
> subdirectory of your source root:

Not to me. Looks like something (called cpputils, probably) is
deliberately adding
these Makefiles to the source tree. The check-syntax rule is something used by
flymake-mode in Emacs (possibly other things, but that's the one I know of).

[...]

>> On Sep 9, 2016, at 8:17 AM, Vania Joloboff  wrote:
>>
>> Hi,
>>
>> I have started to use CMake for my software.
>> I build in a separate directory using :
>> $> cmake -G "Unix Makefiles"  
>>
>> Everything is built correctly and the software works fine.
>> However all of my source code directories get polluted.
>> Into each source directory, a new Makefile is created.
>> All of these Makefiles are identical. They are
>>
>> -
>> # Generated by cpputils-cmake.
>> include /flags.make
>> .PHONY: check-syntax
>> check-syntax:
>>${CC} -o /dev/null ${C_FLAGS} ${C_DEFINES} -I/usr/src/linux/include 
>> -DNDEBUG -S ${CHK_SOURCES}
>> 
>>
>> Any clue ??
>>
>> Vania
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to Determine If a Perl Module Is Installed?

[Bruce Stephens]

On Tue, May 24, 2016 at 3:52 AM, Eric Eide  wrote:

> As a CMake newbie, I was afraid that I was overlooking some sort of
> "prepackaged" version of this.

Doesn't look like it, but I agree it's the kind of thing that might be usefully
included with CMake.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to Determine If a Perl Module Is Installed?

[Bruce Stephens]

On Mon, May 23, 2016 at 11:30 PM, Eric Eide  wrote:
> Hi!  I am a CMake newbie, and I have a question about examining the set of
> available Perl modules on a system.
>
> In CMake (version 2.8.12+), how can I test for the presence of a particular
> Perl module, e.g., "Sys::CPU"?

I think use execute_process to execute a command like

   perl -MSys::CPU -e ""

So, something like

execute_process(COMMAND ${PERL_EXECUTABLE} -MSys::CPU -e ""
 ERROR_QUIET RESULT_VARIABLE status)

if ${status} is zero then the module exists, otherwise it doesn't. You
can wrap it in a function,
obviously.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Fwd: Using CPack to package things not built using CMake

[Bruce Stephens]

Sorry, that should obviously have gone to this mailing list.

-- Forwarded message --
From: Bruce Stephens <bruce.r.steph...@gmail.com>
Date: Mon, May 23, 2016 at 2:40 PM
Subject: Using CPack to package things not built using CMake
To: cmake-develop...@cmake.org


Suppose I have a build which uses a number of external projects
(perhaps built using ExternalProject_Add) but which use a variety of
build systems.

And I want to package the result (so I arrange for the external
projects to build expecting themselves to be installed under
/opt/foo).

What are good ways to do that, without going in and replacing all the
existing build systems with CMake (which is likely the route we'll
take for some, but doing all doesn't seem practical)?

A possibility is just to build static rather than shared libraries;
for quite a few cases that would mean nothing would need to be
installed.

Another one (which would be a bit more general, I think) is to replace
the build with a CMake wrapper, so the building bit calls the
underlying build script but the install part is all done in CMake. In
these cases the numbers of files is usually quite small, so doing that
shouldn't be too annoying, and would presumably produce the right
scripts to use in CPack.

Any better ideas (or problems I'm missing with the last idea I suggest)?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[cmake-developers] Using CPack to package things not built using CMake

[Bruce Stephens]

Suppose I have a build which uses a number of external projects
(perhaps built using ExternalProject_Add) but which use a variety of
build systems.

And I want to package the result (so I arrange for the external
projects to build expecting themselves to be installed under
/opt/foo).

What are good ways to do that, without going in and replacing all the
existing build systems with CMake (which is likely the route we'll
take for some, but doing all doesn't seem practical)?

A possibility is just to build static rather than shared libraries;
for quite a few cases that would mean nothing would need to be
installed.

Another one (which would be a bit more general, I think) is to replace
the build with a CMake wrapper, so the building bit calls the
underlying build script but the install part is all done in CMake. In
these cases the numbers of files is usually quite small, so doing that
shouldn't be too annoying, and would presumably produce the right
scripts to use in CPack.

Any better ideas (or problems I'm missing with the last idea I suggest)?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] ExternalProject and libraries again

[Bruce Stephens]

On Wed, Mar 9, 2016 at 9:27 PM, Nicholas Braden
 wrote:
> I'm not sure which discussion you're referring to, so forgive me if
> this was already mentioned - but are you using a superproject to
> ensure that dependencies are built and installed before your own
> project? That is, all dependencies as well as your own project are
> built via ExternalProject_Add and you use the DEPENDS option to ensure
> build order. This is generally the easiest way to do things, in my
> experience.

Ah! That makes sense. So I have a project (say a single
CMakeLists.txt) which just contains one or more ExternalProject_Add
(maybe other things too, but not much else), and then the subprojects
can sensibly get at previous subprojects. And those can be ordered
using DEPENDS.

OK, I see how that can work. Thanks (and apologies, I'm sure I've read
that advice before but probably I didn't understand it then).
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] ExternalProject and libraries again

[Bruce Stephens]

(This is really a continuation of a discussion from 25/26 January.)

I'm still confused about ExternalProject_Add and libraries.

I'd like to get to the point where I (or more likely a process
somewhere) can check out a project, then run cmake and ninja (or make
or whatever) and have that build the project and its dependencies.

Concretely, suppose I have a trivial project that uses libcrypto from
OpenSSL and I have a local repository with OpenSSL with some patches
to build it with cmake.

One suggestion is that I can use ExternalProject_Add to download and
build this openssl which can then export a FindOpenSSL.cmake script.
But that happens too late, doesn't it?

When I run cmake on my project it can't use find_library and things to
find the right library files since those won't exist until I actually
build the project?

Hence hunter's approach of downloading and building projects during
the cmake process, I imagine. Which feels a bit icky, but maybe it's
really the most straightforward way to do it?

I think I might resort to some trickery: build the various dependent
things on the platforms I care about, and then have my main project
just know about where the interesting targets are relative to
BINARY_DIR for each of the external projects. (Or use the approach of
hunter, or use some build script.)

Am I missing something obvious? It feels like I must be somehow.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Proposed patch for 0014140: Ninja generator doesn't set version in dylib

[Bruce Stephens]

On Mon, Mar 7, 2016 at 8:06 PM, Brad King <brad.k...@kitware.com> wrote:
> On 03/07/2016 02:49 PM, Bruce Stephens wrote:
>> Moving the method into there worked cleanly.
>
> Thanks.  I split that into a separate commit:

Thanks. I wondered whether or not to do that separately.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Proposed patch for 0014140: Ninja generator doesn't set version in dylib

[Bruce Stephens]

On Mon, Mar 7, 2016 at 6:06 PM, Brad King <brad.k...@kitware.com> wrote:
> On 03/01/2016 04:58 PM, Bruce Stephens wrote:
>> I just copied the relevant code from the Makefiles generator.
>
> Thanks.  Instead of copying, please look at moving the relevant
> methods up to cmCommonTargetGenerator so it can be shared between
> the two generators instead.

Ah, thanks for the class name. I did look for a suitable one but for some reason
didn't spot that one (though the comment makes it obvious that it's suitable).

Moving the method into there worked cleanly.


0001-Add-OS-X-dylib-versioning-to-Ninja-generator.patch
Description: Binary data
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Proposed patch for 0014140: Ninja generator doesn't set version in dylib

[Bruce Stephens]

I just copied the relevant code from the Makefiles generator. (And now
I find gmail
doesn't let me change the properties of the attachment. Bother.)


0001-Copy-logic-for-OS-X-dylib-versioning-to-Ninja-genera.patch
Description: Binary data
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] shared library versioning on OS X

[Bruce Stephens]

In case anyone cares, I think https://github.com/brucestephens/CMake
contains a quick fix.

On Sat, Feb 20, 2016 at 7:17 PM, Bruce Stephens <bruce.r.steph...@gmail.com>
wrote:

> Ah, yes. That looks like exactly the bug, thanks.
>
> So it's a straight bug in the ninja generator, not something deliberate
> that I was just failing to understand. And with the Unix Makefile generator
> the compatibility version is set (presumably the current version would be
> set if I used VERSION).
>
> On Sat, Feb 20, 2016 at 6:59 PM, <clin...@elemtech.com> wrote:
>
>> Perhaps this bug report fits what you are seeing.  Are you seeing this
>> limitation in the ninja generator?
>>
>> https://cmake.org/Bug/view.php?id=14140
>>
>> Clint
>>
>> On Feb 20, 2016 11:49 AM, Bruce Stephens <bruce.r.steph...@gmail.com>
>> wrote:
>> >
>> > By the looks of it setting the SOVERSION when generating a SHARED
>> library creates the symbolic link, but it doesn't seem to use the
>> -current_version or -compatibility_version flags when linking.
>> >
>> > Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and
>> CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages)
>> but those don't seem to be used.
>> >
>> > Is that deliberate?
>> >
>>
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] shared library versioning on OS X

[Bruce Stephens]

Ah, yes. That looks like exactly the bug, thanks.

So it's a straight bug in the ninja generator, not something deliberate
that I was just failing to understand. And with the Unix Makefile generator
the compatibility version is set (presumably the current version would be
set if I used VERSION).

On Sat, Feb 20, 2016 at 6:59 PM, <clin...@elemtech.com> wrote:

> Perhaps this bug report fits what you are seeing.  Are you seeing this
> limitation in the ninja generator?
>
> https://cmake.org/Bug/view.php?id=14140
>
> Clint
>
> On Feb 20, 2016 11:49 AM, Bruce Stephens <bruce.r.steph...@gmail.com>
> wrote:
> >
> > By the looks of it setting the SOVERSION when generating a SHARED
> library creates the symbolic link, but it doesn't seem to use the
> -current_version or -compatibility_version flags when linking.
> >
> > Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and
> CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages)
> but those don't seem to be used.
> >
> > Is that deliberate?
> >
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] shared library versioning on OS X

[Bruce Stephens]

By the looks of it setting the SOVERSION when generating a SHARED library
creates the symbolic link, but it doesn't seem to use the -current_version
or -compatibility_version flags when linking.

Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and
CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages)
but those don't seem to be used.

Is that deliberate?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

[Bruce Stephens]

On Mon, Dec 21, 2015 at 10:11 PM, DJ  wrote:

> One of the things that seems to me to be missing is some kind of quick
> description of the overall "theory of cmake". I am a top-down kind of
> person, so I really dislike being left with nothing but "here, type this
> in" which is what a lot of the web stuff seems to be. A sketch of how it
> works conceptually would help me. (Of course, I need examples too.)
>


There's the manages. Specifically cmake-buildsystem(7) and
cmake-language(7) (and the others, though those are more reference lists of
details).
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Shared library from sources in several subdirectories

[Bruce Stephens]

On Mon, Dec 7, 2015 at 9:08 AM, Nils Gladitz  wrote:

> I would avoid creating these single use, per directory libraries entirely.
>
>
Well, creating the static libraries is obviously just an artifact of our
current
build scheme, so it makes sense to ditch it.

Creating these CMake object libraries doesn't seem bad; is there some
reason to avoid doing that? A reason for doing it is it gives targets for
target_include_directories, so just the crypto objects can be built with
the OpenSSL include directory.

Also for some reason setting the POSITION_INDEPENDENT_CODE
property for the top-level shared library (the default anyway) doesn't
seem to propagate down (and maybe it can't), and the named thing
makes it easy to apply the property to the sources. Though now I look,
I could use set_property on the sources (or the directory), and I could
use set_property similarly to add include directories (and compile
definitions).


> A single target can build sources located in any number of directories.
>
> If you want to subdivide the source file listing of that one target for
> organizational purposes you can do so with e.g. include(), target_sources()
> and/or list variables.
>

Thanks for suggesting that. For some reason it hadn't occurred to me.
I'm not sure whether that would work out better for this particular case
or not, or for the larger library I'd like to do (with ~500 sources in a
tree
of ~40 directories).

(I suspect there's not that much in it ultimately and worrying about the
choice is as much bike shedding as anything.)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Shared library from sources in several subdirectories

[Bruce Stephens]

Any suggestions on how to organise that? Presumably there are
lots of examples in (for example) KDE, but I'm not familiar enough
with that codebase to be able to find them easily.

Currently our GNU Make build builds static libraries in the subdirectories,
then those are put into a big static library and that's linked into a shared
library. (The last step uses a shell script which knows how to do that for
various platforms.)

My first attempt uses add_library(... OBJECT ...) in the subdirectories,
then add_library(... SHARED $ $)
to combine them.

That works, though it means repeating the same information (more or less)
twice
since for each add_subdirectory() there'll be a $. Also
the dependent libraries need to be added in the top-level but they're
triggered
by the subdirectory (by the looks of it I can't use target_link_libraries()
on an OBJECT
library). It works, though, and didn't take me very long to do, and the
result looks
clean and relatively easy to follow.

Any better ways to do this? (In the particular case I'm looking at,
splitting the
libraries and just having one per subdirectory might make sense, but not in
all
cases.)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake