Re: [CMake] GLOB_RECURSE

[Dan Liew]

On 25 July 2018 at 23:47, Michael Hennebry
 wrote:
> Emphasis on curse.
>
> from CMakeLists.txt:
>
> file (GLOB_RECURSE ards ./ArduinoCore/src *.cpp *.c)
> file (GLOB_RECURSE apps ./SensorUnit *.cpp *.c)

Your syntax is wrong. `./ArduinoCore/src`, ` ./SensorUnit`, `*.cpp`,
`*.c` are all being treated as separate glob expressions so `*.cpp`
and `*.c` recursively match the current directory.
If you look at the signature of the function you're calling

```

file(GLOB_RECURSE  [FOLLOW_SYMLINKS]
 [LIST_DIRECTORIES true|false] [RELATIVE ]
 [...])
```

you can see that all your arguments after `ards` and `apps` are being
treated as ``.
Instead you want something like this

file(GLOB_RECURSE ards RELATIVE ArduinoCore/src *.cpp *.c)
file (GLOB_RECURSE apps RELATIVE ./SensorUnit *.cpp *.c)

Note the use of the `RELATIVE` argument. See
https://cmake.org/cmake/help/v3.10/command/file.html for more details.

Hope that helps.
-- 

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] Cannot find source file:

[Dan Liew]

On 24 June 2017 at 05:06, Sean Wayland  wrote:
> Hi all,
> I am having trouble getting an application to build.
> I keep getting this error "cannot find source file"
>
>
> /Users/seanwayland/Desktop/CATSMAT-masterfri/catsmat/catsmat/Analysis/src/*.cpp
>
> This is the first folder containing sources and when it doesn't find
> anything here it stops.
>
> There are indeed .cpp files in that directory.
> I tried putting a ./ at the start of the directory tree but it didn't help.
>
> My cmake file is below .. I am using CLION 2017.1.1 and OSX 10.12.1
>
> Can anyone shed any light ??

My high level comment would be to not glob for source files. This an
anti-pattern and will break your incremental builds.

For example if you add a new source files say "foo.cpp" and then run
"make" (or whatever your CMake generator is) the build
will fail if "foo.cpp" is actually needed because CMake will not know
it needs to re-configure to discover "foo.cpp" and so will
not try to build "foo.cpp". By listing source files manually in
"CMakeLists.txt" files you will force CMake to re-configure when you
add/remove source files from the build.

I also note you are setting a very old minimum CMake version and are
using the old style condition syntax (condition appears in `endif()`
and `else()`).
I'd really advise you don't use that syntax and set a high minimum
CMake version so you get some of the useful new features in CMake
unless
you have a specific reason for supporting such an old version of CMake.

As for your globbing problem

* This is definitely wrong

```
set (CATSMAT_DIR
./Users/seanwayland/Desktop/CATSMAT-masterfri/catsmat/catsmat/ )
```

The leading `.` means current directory and I doubt there's a `Users`
folder in your current directory.
Also hard coding paths like is very bad style and is not portable.

* This doesn't make sense

```
file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC})
```

"${SRC}" is a list of absolute paths but then you tell the `file()`
command to assume the paths are relative
to `${CMAKE_CURRENT_SOURCE_DIR}`.
-- 

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] Release flags on one target in debug build type

[Dan Liew]

On 5 May 2017 at 19:45, Konstantin Tokarev  wrote:
> Hello,
>
> Is there any clear way to build specific target in "Debug" mode with flags 
> that it would have in "Release"?
>
> In particular, build this specific target without effect of 
> CMAKE_CXX_FLAGS_DEBUG and CMAKE_C_FLAGS_DEBUG, while preserving flags added 
> by target_compile_options


Something like this would sort of do it.

```
target_compile_options(your_target
  PRIVATE
  $<$:$<$:${CMAKE_CXX_FLAGS_RELEASE}>>
  $<$:$<$:${CMAKE_C_FLAGS_RELEASE}>>
```

The problem you have though is that `your_target` in debug mode will
already debug build flags (e.g. `-O0 g`). So you may get conflicting
compiler options.

Another way of doing this is to build your target as an external
project where you set the build mode of the external project to be
release.
-- 

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] When Ninja byproduct is a directory causes `clean` target to fail.

[Dan Liew]

Hi,

I recently added support to a project to build its API documentation [1].

The documentation is generated by doxygen.
I used `add_custom_command()` to run doxygen and I use `BYPRODUCTS` to
specify the output directory that will be generated by doxygen in the
hope that this would tell ninja to remove it when the `clean` target
is run.

However this doesn't work because ninja complains that the directory
isn't empty.
Is `BYPRODUCTS` not supposed to be used with directories, or is this a bug?


[1] 
https://github.com/Z3Prover/z3/blob/a9d6ef68f02d636d9628a52a257d968a13321752/contrib/cmake/doc/CMakeLists.txt#L59

Thanks,
Dan.
-- 

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] Saving clang output to file when cmake is used with CLion

[Dan Liew]

Hi,

On 13 April 2017 at 01:35, mike lojkovic  wrote:
> I have a script I'm using to figure out which headers should be in my
> precompiled header. It requires the clang -H flag passed to work. I'm
> able to get the output on the console without issue, but can't figure
> out how to just pass clang's output to a file for my script to
> analyze. redirecting the console output to a file with ">" won't work
> since I'm compiling from CLion. Is there a way to do this from within
> a CMakeLists.txt?  I'm thinking something like tee would work, but
> can't find a variable to chain to tee.

I have two ideas for this

1. Write a wrapper script for clang and tell CMake to use that as the
compiler. Something like this would do it

```
#!/bin/bash
: ${STDOUT_DEST?"STDOUT_DEST is not set"}
: ${STDERR_DEST?"STDERR_DEST is not set"}
CLANG_BIN="$(which clang)"
{ ${CLANG_BIN} "$@" 2>&1 1>&3 3>&- | tee -i ${STDERR_DEST}; } 3>&1
1>&2 | tee -i ${STDOUT_DEST}
```

this wrapper script logs the standard output and standard error to
separate files (overwriting existing files). The file names are set by
environment variables. You'll probably need to modify this script to
suit your needs.

then configure cmake to use this as the compiler

```
CC=/path/to/clang_wrapper cmake /path/to/source_dir
```

If you have C++ code you'll need to write a similar wrapper for `clang++`.

2.  Use the compilation database [1] which will record all the clang
invocations and then write a script to read the JSON file
and re-run the commands with the `-H` flag added and capture the
output and do whatever you need to do with it.

[1] https://clang.llvm.org/docs/JSONCompilationDatabase.html


HTH,
Dan.
-- 

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 for fftw library

[Dan Liew]

> Where Am I going wrong ?
> Can anyone please help me out ?

You don't link against fftw which is why you get linking errors. The
`${fftw}` variable is empty.
-- 

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] libsndfile in winodws

[Dan Liew]

On 2 March 2017 at 12:07, aishwarya selvaraj
 wrote:
> Hi all ,
> I was trying to build my .cpp file in windows in Windows platform (windows
> 10) using cmake .
> My .cpp file makes use of two external libraries 1)armadillo 2)libsnd file.
> I have written a corresponding cmakelist.txt to compile and obtain the
> binary .
> I was successful in doing so in Linux , when it come to Windows I obtain the
> following error .
>
> 3>Time Elapsed 00:00:02.06
> 2> Current branch master is up to date.
> 2> No patch step for 'project_libsndfile'
> 2> Performing autogen step for 'project_libsndfile'
> 2> Performing configure step for 'project_libsndfile'
> 2>
> 'C:\Users\computing7\Desktop\TSM_cmake\build\lib\libsndfile\src\project_libsndfile\configure'
> is not recognized as an internal or external command,
> 2> operable program or batch file.

Above is your clue. Your build could not run `configure`. Your problem
is most likely in

```
ExternalProject_Add(project_libsndfile
GIT_REPOSITORY https://github.com/erikd/libsndfile.git
PREFIX  lib/libsndfile
CONFIGURE_COMMAND   /configure
BUILD_COMMAND   make
BUILD_IN_SOURCE 1
INSTALL_COMMAND echo Skipping install step for libsndfile
)
```

Running a `configure` script is not going to work on Windows out of
the box because libsnd uses GNU autotools which is for made for UNIX
like operating systems. You should try and figure out how (if it's
even possible) to build libsnd on Windows. At glance at the GitHub
page shows they have a CMake build system but the docs say it will
likely only work on Linux. There are some commits that mention MINGW
so maybe it might be possible to build using the MSYS environment.

Good Luck.
-- 

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] Default CMAKE_C_FLAGS value by OS

[Dan Liew]

Hi,

On 16 February 2017 at 09:06,   wrote:
> Hello,
>
> My question is related to CMAKE_*_FLAGS.
> I've got a project under linux fedora 24 and, in release mode, this project 
> compiles with the -O2 flag.
> But when I switched to other platform (ubuntu, fedora 16 - I now this one is 
> quite old but I need to compile on this platform), this default optimization 
> flag changes. On some platform, it's -O3.
> And because with -O3 flag some "risky" optimizations are enabled, my project 
> hangs ...

You can find CMake's defaults for gcc/clang in

/usr/share/cmake-/Modules/Compiler/GNU.cmake

where  is your CMake version.

E.g.

https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake

You'll see lines like

```
string(APPEND CMAKE_${lang}_FLAGS_INIT " ")
string(APPEND CMAKE_${lang}_FLAGS_DEBUG_INIT " -g")
string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
```

It's possible that the defaults changed at some point but I would be
really surprised by this. Are you sure you weren't doing a
RELWITHDEBINFO build on one system and a RELEASE build on the other?

It is possible to override these defaults by writing an overrides file
(example [1]) and then using those overrides before the `project()`
declaration in your root `CMakeLists.txt` file.
Here's an example [2].

So if you need fine grained control over the optimization level used
for different build types then I suggest you use overrides.


[1] 
https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/cmake/c_flags_override.cmake
[2] 
https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/CMakeLists.txt#L5

HTH,
Dan.
-- 

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 3.7.2 and parallel builds

[Dan Liew]

> What's weirder (and I forgot to mention) is that if I just build the project
> normally outside of my regression testing script (ie. "make -j5"), I don't
> get the jobserver warning.

The reason for this error message from make is given at [1].

I've seen something like this before when my build used "Unix
Makefiles" as the generator and the build invoked an external build
system as a `add_custom_command()` that also used makefiles to do its
build.

The problem was that make (in the outer most build system, i.e. the
CMake generated) one was setting the `MAKEFLAGS` environment variable
to do communicate various bits of information to handle recursive
makefiles (see [2]). This works fine until the CMake generated
makefiles invoked the external build system with `MAKEFLAGS` being
set.

My solution was to strip `MAKEFLAGS` out of the environment when
invoking the `make` command externally.

This isn't exactly your problem but it may help you figure out what is
wrong. My guess is that the sub-make isn't being invoked correctly.

[1] https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
[2] 
https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
-- 

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] Comaptibility with older gcc

[Dan Liew]

> I was also doubting about libstdc++ versions, is there maybe a way of asking
> Cmake to statistically include it in the built library?

I assume you mean statically. If so then you could try invoking cmake
like this on the command line.

```
mkdir new_build_dir
cd new_build_dir
CXXFLAGS="-static-libstdc++ " CFLAGS="-static-libstdc++" cmake
/path/to/source/tree
make -j$(nproc)
```

Note that `new_build_dir` must be empty every time you invoke the
`cmake` command
because it will only try to detect your compiler once. Subsequent
invocations of cmake
in an existing build directory does not change the compiler and
setting CXXFLAGS and
CFLAGS to different values has no effect.

However I don't think this is the best approach. I think you would be
much better of recreating
the production environment on your development machine. This makes it
much easier to reproduce
issues you may hit in production.

There are many ways about doing this but my suggestion would be to use
Docker or a virtual machine for that purpose.

You mention you want to use Eclipse so what you could do is develop
your application on your local machine (i.e. outside of Docker or the
virtual machine)
but have your source files mounted into your Docker container (these
are called volume mounts) or the virtual machine.

That way you can use Eclipse for your development locally but when you
want to, you can do a build inside the container/vm using the same
source files
to test the build still works and also produce binaries that will
"just work" on your production system.

HTH,
Dan.
-- 

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 vs. Python 3.4

[Dan Liew]

On 23 Dec 2016 7:58 pm, "Lev"  wrote:

Hi list,


I have this:

FIND_PACKAGE(PythonInterp)

and cmake finds this:

-- Found PythonInterp: /usr/bin/python (found version "2.7.9")

However, 3.4 is also installed. How can I specify to find 3.4?

If I say:

set(Python_ADDITIONAL_VERSIONS 3.4)
FIND_PACKAGE(PythonInterp 3 REQUIRED)

still no luck.

When you did that did you wipe the CMake cache (e.g. delete any existing
binary build directory)? In many cases where CMake is asked to find a
binary it will create a cache variable if it was found so that on
subsequent runs of CMake it doesn't have to search for it again. You may be
hitting 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

[Dan Liew]

Hi Aishwarya,

On 21 December 2016 at 11:51, aishwarya selvaraj
 wrote:
> Hi Everyone,
> Myself Aishwarya .I wanted to make use of Cmake , but I'm really new to this
> and doesn't have a clear idea about it.
>
> 1) My Goal :
> I'm using Praat a speech Processing Software to create plug - in for my
> Algorithm on Pitch and Time scaling .(I have the .cpp file)
> In order to do that I need to use the binary file obtained by compiling .cpp
> file
> in my Praat Script .
> I intent to share this plug - in with others ,Hence I want it to be machine
> independent .The binary file I obtained is using gcc in Linux (16.0.2),
> which clearly wont work in Mac or Windows or even in lower Linux Version.
> To solve this Problem I understand that I need to make use of Cmake files .

CMake is not going make your binaries machine independent. It can give
a way to build your application that will successfully compile on
different platforms but you will have to compile the binary on each
platform that you are targeting.

> 2) My .cpp file called TSM_CODE_V3.cpp is compiled as
> g++ TSM_CODE_V3.cpp -larmadillo -lsndfile -o TSM
>
> where armadillo and sndfile are two depended libraries.
>
> 3) What I have done :
> I have gone through a loot of tutorials for cmake .I have wage idea , but
> I'm not able to solve my problem mentioned above .
> My folder TSM consists of
> build - the folder which consists the final executable binary file and the
> related cmake files required to create binary file
> src - consists of my TSM_CODE_V3.cpp code
> CMakeLists.txt - The top level Cmake file :
>
>  cmake_minimum_required(VERSION 2.8.9)
>  project(directory_TSM)
>  include_directories(include)
>  file(GLOB SOURCES "src/*.cpp")
>  add_executable(tsm ${SOURCES})

Do not use `file(GLOB ...)` to find source files. It is very bad
practice because it prevents CMake from re-generating itself
automatically. You should list the source files explicitly. That way
when you add/remove a source file the fact you updated the
`CMakeLists.txt` file will trigger a re-configure of the build system.

>
> I need to include the library armadillo and lidsndfile .
> I dont know how to include it into my cmakefile .
> I have come across find_package ,find_library  but I am sure about it .
>  To create my Praat Plug - in I need to compile the source code no matter in
> which system it is ,which may or may not have these two libraries already
> installed.
> So how how do I add libraries using cmake ?

Use `target_link_libraries()` to link libraries into your target. If
you're not sure how to use it I highly recommend you read the
documentation for it [1].

In terms of finding the library if there is no package for those
libraries you can use the `find_library()` command. Again if you're
not sure how to use it check out the documentation [2].

Seeing as you are very new to CMake I would also recommend reading [3]
which explains some important high level concepts in CMake.

[1] https://cmake.org/cmake/help/v3.6/command/target_link_libraries.html
[2] https://cmake.org/cmake/help/v3.6/command/find_library.html
[3] https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html
-- 

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] Adding dependencies to the `clean` target in 2016?

[Dan Liew]

On 5 December 2016 at 14:05, Brad King <brad.k...@kitware.com> wrote:
> On 12/03/2016 06:52 AM, Dan Liew wrote:
>> There was a post about this 10 years ago [1], has anything changed since 
>> then?
>
> No.  From my response back then:
>
>>> The "clean" target is not a first class target available to
>>> CMakeLists.txt codeWe do plan to make targets like install
>>> and clean first class eventually but it is not yet implemented.
>
> This never happened.  These generator-provided targets have very
> different semantics (e.g. per-directory behavior in the Makefile
> generator) and that makes it hard to define them in a way that is
> visible to client code during configuration.  It may be possible but
> will require deep design thought.

Thanks for the info. Giving developers control of the `clean` target
is something I'd like to see even if it does require quite a bit of
thought.
CMake has special commands for doing `install` so I'd expect something
analogous for managing how `clean is performed`.
These would be declared on a per directory basis and if the generator
worked a per directory basis then we would have
per directory clean targets otherwise there would just be a global clean target.

>> I realise the `clean` target won't be available for all generators but
>> for those that do, it would be really nice to able to do something
>> like this.
>>
>> add_dependencies(clean CleanKLEERuntimes)
>
> Just as `ADDITIONAL_MAKE_CLEAN_FILES` is a make-specific solution I
> think something like `ADDITIONAL_MAKE_CLEAN_COMMAND` or perhaps
> `ADDITIONAL_MAKE_CLEAN_TARGET` could be offered.  Such configuration
> could be interpreted by the makefile generator while generating the
> "make clean" target.

I suppose that would do the job. I do use Ninja as a generator a lot
too. Would Ninja support it too?

Dan.
-- 

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] Adding dependencies to the `clean` target in 2016?

[Dan Liew]

Hi,

As part of a project I work on we use CMake's `ExternalProject()` to
build a set of runtime libraries that the project needs via a second
build system (Makefile based) that knows how to build the runtime
libraries. The code (which is full of hacks... sorry) is at [1].

What I want to do is when the `clean` target is invoked in the CMake
generated build system is have the command `make clean` invoked on the
project being built by `ExternalProject()`.

There was a post about this 10 years ago [1], has anything changed since then?

Using `ADDITIONAL_MAKE_CLEAN_FILES` is not really an option because
CMake doesn't know what files are generated by the other build system.
Even if CMake did know what those files were I don't think it should
be removing them itself. It should be using the other build system
because that knows best how to do a clean.

I realise the `clean` target won't be available for all generators but
for those that do, it would be really nice to able to do something
like this.

```
if (TARGET clean)
  add_custom_target(CleanKLEERuntimes
COMMAND
make -f mycustom_makefile clean
USES_TERMINAL
)
add_dependencies(clean CleanKLEERuntimes)
endif()
```
Right now this doesn't work though.

* `if (TARGET clean)` is always false
* `add_dependencies()` does not work on the `clean` target.

[1] 
https://github.com/klee/klee/blob/28a3d47fa03b9ed98f1bbb4f1b38ecbd44ab1a00/runtime/CMakeLists.txt#L104
[2] https://cmake.org/pipermail/cmake/2006-October/011477.html


Thanks,
Dan.
-- 

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] Calling find_package(self) for in-project builds

[Dan Liew]

> What would be the suggested way to handle this?

Couldn't you build the examples using CMake's ``ExternalProject``
module [1] and have that build after the main project has finished
building?

[1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html
-- 

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] RFC: LLVM community CMake documentation

[Dan Liew]

Hi Chris,

Thanks for doing this. I've had a quick scan and I have a few minor comments.

# Scripting overview

This is personal preference but I don't like ``add_definitions()`` due
to its global behaviour so I think its use should be discouraged. I
much prefer ``target_compile_definitions()`` which isn't global.

# Dereferencing

One "Gotcha" I think that is worth mentioning is implicit derefencing
of variables in ``if()`` conditionals

for example

```
if ("${SOME_VAR}" STREQUAL "MSVC")
```

behaves very strangely because CMake will implicitly dereference
"MSVC" (as if it was "${MSVC}") where as someone reading the code
probably thinks that it is trying to check if the contents of the
SOME_VAR as a string are "MSVC".

This behaviour is prevented by setting CMP0054 to NEW but this was
only introduced with CMake 3.1 and I don't think that's LLVM's minimum
version so developers might hit this issue. Run ``cmake --help-policy
CMP0054`` for more details.

A hacky work around I employ is to write conditionals like that like this

```
if ("X${SOME_VAR}" STREQUAL "XMSVC")
```

It's not good though...

# Scope

You don't mention "GLOBAL" properties. IIRC LLVM's CMake code uses
these so it might be worth mentioning these

# LLVM specific macros/functions

LLVM's CMake code pretty much avoids using many of the standard CMake
commands for declaring targets favouring its own (sometimes
confusingly named, e.g. add_llvm_library Vs. llvm_add_library) which I
sometime find quite confusing. Seeing as this guide is aimed at LLVM
developers I think this document (or an accompanying document) should
describe these macros/functions.

Thanks,
Dan.
-- 

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] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why?

[Dan Liew]

Hi,

On 28 March 2016 at 15:05, Brad King <brad.k...@kitware.com> wrote:
> On 03/27/2016 06:11 AM, Dan Liew wrote:
>> OUTPUT does not accept generator expressions, why?
>
> It hasn't been implemented.  At least at one time it would have been
> very hard to implement.  I'm not sure now because there has been a lot
> of refactoring since I last looked at it.
>
> There is some discussion here:
>
>  https://cmake.org/Bug/view.php?id=13840
>  https://cmake.org/Bug/view.php?id=12877#c28315
>
>> If I can't use generator expressions with ``OUTPUT``, how am I
>> supposed to output a file into the build directory of a target?
>
> Unfortunately it is not possible to do cleanly without fixing the
> above.  Approximations include:
>
> * Use a POST_BUILD command on the target instead.
>
> * Make the OUTPUT a timestamp file and generate the real output
>   as a side effect.
>
> If anyone is interested in trying to implement generator expressions
> for custom command outputs, I can provide more details to get started.

Thanks for the info Brad. I wish I had time to look into this but I
don't so for now I'll just work around it.

Dan.
-- 

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] add_custom_command() OUTPUT does not accept generator expressions, why?

[Dan Liew]

Hi,

On 28 March 2016 at 15:05, Brad King <brad.k...@kitware.com> wrote:
> On 03/27/2016 06:11 AM, Dan Liew wrote:
>> OUTPUT does not accept generator expressions, why?
>
> It hasn't been implemented.  At least at one time it would have been
> very hard to implement.  I'm not sure now because there has been a lot
> of refactoring since I last looked at it.
>
> There is some discussion here:
>
>  https://cmake.org/Bug/view.php?id=13840
>  https://cmake.org/Bug/view.php?id=12877#c28315
>
>> If I can't use generator expressions with ``OUTPUT``, how am I
>> supposed to output a file into the build directory of a target?
>
> Unfortunately it is not possible to do cleanly without fixing the
> above.  Approximations include:
>
> * Use a POST_BUILD command on the target instead.
>
> * Make the OUTPUT a timestamp file and generate the real output
>   as a side effect.
>
> If anyone is interested in trying to implement generator expressions
> for custom command outputs, I can provide more details to get started.

Thanks for the info Brad. I wish I had time to look into this but I
don't so for now I'll just work around it.

Dan.
-- 

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] add_custom_command() OUTPUT does not accept generator expressions, why?

[Dan Liew]

Hi,

I tried writing a add_custom_command statement that will output the
generated file into the same directory as another target


```
set(OUTPUT_NAME "$/MyThing.dll")
add_custom_command(OUTPUT "${OUTPUT_NAME}"
  COMMAND "csc.exe" "/output:$" "MySource.cs"
)
```

This doesn't work. CMake emits this error message

```
add_custom_command called with OUTPUT containing a "<".  This
character is not allowed
```

If I can't use generator expressions with ``OUTPUT``, how am I
supposed to output a file into the build directory of a target? It
doesn't look like reading the ``LIBRARY_OUTPUT_DIRECTORY`` property of
a target is really an option as according to the documentation that
itself may contain generator expressions.

Any thoughts would be appreciated.

Thanks,
Dan.
-- 

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] Support for colored makefile output with tmux

[Dan Liew]

On 26 March 2016 at 09:30, Dan Liew <d...@su-root.co.uk> wrote:
> On 26 March 2016 at 01:15, Mike Lui <md...@drexel.edu> wrote:
>> When I use tmux and set my TERM to either 'tmux' or 'tmux-256color', I don't
>> get colorized output of from cmake generated Makefiles.
>
> My TERM is set to "xterm-256color" and with that coloured output when
> running ``make`` in Tmux works fine for me.
>
> I'm using tmux 2.1-2, in gnome-terminal 3.18.3 on Arch Linux with CMake 3.5.0

Just to note coloured output in makefiles seems to be implemented
using an undocumented cmake command

``cmake -E cmake_echo_color --cyan hello world``

If you look at [1] you can see the supported switches for different colours.

[1] 
https://github.com/Kitware/CMake/blob/bd15330da1edaf4a662335ff53648074fdc30e2b/Source/cmcmd.cxx#L1176
-- 

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] Support for colored makefile output with tmux

[Dan Liew]

On 26 March 2016 at 01:15, Mike Lui  wrote:
> When I use tmux and set my TERM to either 'tmux' or 'tmux-256color', I don't
> get colorized output of from cmake generated Makefiles.

My TERM is set to "xterm-256color" and with that coloured output when
running ``make`` in Tmux works fine for me.

I'm using tmux 2.1-2, in gnome-terminal 3.18.3 on Arch Linux with CMake 3.5.0
-- 

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] Problem using VS-compiled Clang as a C/C++ compiler.

[Dan Liew]

> -- check which cl.exe is used:
> $which cl
> D:\CL\cl.EXE
>
> -- trying to build:
> $cmake -G "Ninja" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang ..

If your goal is use your renamed clang-cl (cl.exe) then why are you
telling CMake to use to use clang.exe ?

You can clearly see if your error message that ``clang.exe`` is being invoked.

Shouldn't your command line be something like this?

CC=cl.exe CXX=cl.exe cmake -G "Ninja" ..

If you want to be really specific you could do

CC=D:\LLVM-3.7.1\bin\clang-cl.exe CXX=D:\LLVM-3.7.1\bin\clang-cl.exe
cmake -G "Ninja" ..
-- 

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] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Dan Liew]

On 3 March 2016 at 22:02, Nils Gladitz <nilsglad...@gmail.com> wrote:
> On 03.03.2016 22:57, Dan Liew wrote:
>>
>> Hi,
>>
>> I noticed recently is you do something like this
>>
>> add_executable(foo a.cpp b.cpp)
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")
>>
>> then the flags that end up being passed to the compiler during linking
>> are like this.
>>
>> gcc -g -O0 -fopenmp;-static
>>
>> It looks like when using the property with APPEND it becomes a list
>> but when emitted the list isn't expanded properly. I noticed this
>> using CMake 3.4.3 using the "Unix Makefile" generator.
>>
>> Is this intentional or is this a bug?
>
>
> LINK_FLAGS is not a list property; flags have to be whitespace separated.
> You can use APPEND_STRING instead of APPEND for this.

Thanks for this. Shouldn't the fact that ``LINK_FLAGS`` is a string
property and not a list property be in the ``cmake-properties``
documentation? The version of the documentation for my version of
CMake (3.4.3) doesn't say what the property type is.

Thanks,
Dan.
-- 

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] [cmake-developers] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Dan Liew]

On 3 March 2016 at 22:02, Nils Gladitz <nilsglad...@gmail.com> wrote:
> On 03.03.2016 22:57, Dan Liew wrote:
>>
>> Hi,
>>
>> I noticed recently is you do something like this
>>
>> add_executable(foo a.cpp b.cpp)
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")
>>
>> then the flags that end up being passed to the compiler during linking
>> are like this.
>>
>> gcc -g -O0 -fopenmp;-static
>>
>> It looks like when using the property with APPEND it becomes a list
>> but when emitted the list isn't expanded properly. I noticed this
>> using CMake 3.4.3 using the "Unix Makefile" generator.
>>
>> Is this intentional or is this a bug?
>
>
> LINK_FLAGS is not a list property; flags have to be whitespace separated.
> You can use APPEND_STRING instead of APPEND for this.

Thanks for this. Shouldn't the fact that ``LINK_FLAGS`` is a string
property and not a list property be in the ``cmake-properties``
documentation? The version of the documentation for my version of
CMake (3.4.3) doesn't say what the property type is.

Thanks,
Dan.
-- 

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] Problem using VS-compiled Clang as a C/C++ compiler.

[Dan Liew]

Hi,

On 4 March 2016 at 11:16, Anton Yartsev  wrote:
> Hi Cristian,
>
> thanks for the replay. I have clang-cl first in PATH, the problem persists.

Just to check. Did you run cmake in a new (i.e. empty) build directory
when you fixed that? IIRC once a compiler has been picked
during configure you can't change it so if you need to change it you
have to build in a new build directory or delete everything in
the current build directory.

Shouldn't the following work (assuming clang-cl.exe is in your path)

CXX=clang-cl.exe CC=clang-cl.exe cmake -G "Ninja" ..

?
-- 

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] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Dan Liew]

Hi,

I noticed recently is you do something like this

add_executable(foo a.cpp b.cpp)
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")

then the flags that end up being passed to the compiler during linking
are like this.

gcc -g -O0 -fopenmp;-static

It looks like when using the property with APPEND it becomes a list
but when emitted the list isn't expanded properly. I noticed this
using CMake 3.4.3 using the "Unix Makefile" generator.

Is this intentional or is this a bug?

Thanks,
Dan.
-- 

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] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Dan Liew]

Hi,

I noticed recently is you do something like this

add_executable(foo a.cpp b.cpp)
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")

then the flags that end up being passed to the compiler during linking
are like this.

gcc -g -O0 -fopenmp;-static

It looks like when using the property with APPEND it becomes a list
but when emitted the list isn't expanded properly. I noticed this
using CMake 3.4.3 using the "Unix Makefile" generator.

Is this intentional or is this a bug?

Thanks,
Dan.
-- 

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] [CMake] Obtaining header file dependencies of a source file manually

[Dan Liew]

>> There is an alternative which I suggested in the post. Have CMake
>> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
>> at configure time and spit that into the build files of the generator
>> (that would work for any generator). Then have any changes made to the
>> files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the
>> dependencies can be recomputed.
>
> Perhaps, but after regenerating the project the build tool will not
> re-load the build files and start building again.  That will take
> an additional invocation.  The number of iterations required is
> bounded only by the depth of dependency chains.

I don't understand what you mean. What do you mean by "build tool" here?
I also don't see why you would need to reconfigure multiple times.
-- 

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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

>> There is an alternative which I suggested in the post. Have CMake
>> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
>> at configure time and spit that into the build files of the generator
>> (that would work for any generator). Then have any changes made to the
>> files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the
>> dependencies can be recomputed.
>
> Perhaps, but after regenerating the project the build tool will not
> re-load the build files and start building again.  That will take
> an additional invocation.  The number of iterations required is
> bounded only by the depth of dependency chains.

I don't understand what you mean. What do you mean by "build tool" here?
I also don't see why you would need to reconfigure multiple times.
-- 

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-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

> I fail to see why that should not work. Producing LLVM bitcode from
> C++ with Clang is just adding -emit-llvm flag, right? So, why can't
> the SuperBuild configure the child build to use Clang and this flag?
> And Bob's your uncle...

Hmm, to be honest I hadn't tried. It works better than expected but...

The problem for this particular project is that it doesn't file a very
standard compilation process. It compiles to LLVM IR, then to LLVM
bitcode and then it invokes and external program to generate source
files with the LLVM bitcode embedded in specially named arrays these
generated source files then are compiled along with other sources into
the projects main library. If I made the external project create
OBJECT libraries rather than regular libraries then that might work
but when I add the ``-emit-llvm`` flag to CMAKE_C_FLAGS things start
breaking..., e.g.

```
include(CheckCCompilerFlag)
CHECK_C_COMPILER_FLAG("-g" SUPPORTS_DEBUG)
```

Checking this compiler flag fails if CMAKE_C_FLAGS contains
``-emit-llvm`` due to linking errors.

I also need a way of communicating to the outside world where the
object files are as they are the final output. Using ``add_library(foo
OBJECT ...)`` is just a hack to avoid invoking the linker.

Maybe I should use a tool-chain file? I've never used this feature of
CMake before but perhaps that would solve these problems. That way I
could have CMake use, llvm-link rather than the system linker. Then
things wouldn't break when trying to link.

Dan.
-- 

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] Obtaining header file dependencies of a source file manually

[Dan Liew]

> I fail to see why that should not work. Producing LLVM bitcode from
> C++ with Clang is just adding -emit-llvm flag, right? So, why can't
> the SuperBuild configure the child build to use Clang and this flag?
> And Bob's your uncle...

Hmm, to be honest I hadn't tried. It works better than expected but...

The problem for this particular project is that it doesn't file a very
standard compilation process. It compiles to LLVM IR, then to LLVM
bitcode and then it invokes and external program to generate source
files with the LLVM bitcode embedded in specially named arrays these
generated source files then are compiled along with other sources into
the projects main library. If I made the external project create
OBJECT libraries rather than regular libraries then that might work
but when I add the ``-emit-llvm`` flag to CMAKE_C_FLAGS things start
breaking..., e.g.

```
include(CheckCCompilerFlag)
CHECK_C_COMPILER_FLAG("-g" SUPPORTS_DEBUG)
```

Checking this compiler flag fails if CMAKE_C_FLAGS contains
``-emit-llvm`` due to linking errors.

I also need a way of communicating to the outside world where the
object files are as they are the final output. Using ``add_library(foo
OBJECT ...)`` is just a hack to avoid invoking the linker.

Maybe I should use a tool-chain file? I've never used this feature of
CMake before but perhaps that would solve these problems. That way I
could have CMake use, llvm-link rather than the system linker. Then
things wouldn't break when trying to link.

Dan.
-- 

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] [CMake] Obtaining header file dependencies of a source file manually

[Dan Liew]

On 30 November 2015 at 18:35, Brad King <brad.k...@kitware.com> wrote:
> On 11/30/2015 01:32 PM, Dan Liew wrote:
>> It works but only for makefile generators... That's an annoying
>> limitation. I'll file a feature request to get this implemented for
>> other generators.
>
> It happens to work for Makefile generators because it was easy to
> implement since those generators already do their own scanning.
> For other generators it is not possible to implement.

Well I found the open issue [1]. It's been open for a while.

It doesn't look completely impossible. For Ninja, it looks like it has
some support for compiler
generated dependency files [2]. Incorporating that into
``add_custom_command()`` would require
an extra call to the host compiler to generate the dependencies when
the custom command is invoked.

For other generators that are Makefile or Ninja based I guess that
approach wouldn't work.

There is an alternative which I suggested in the post. Have CMake
determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
at configure
time and spit that into the build files of the generator (that would
work for any generator). Then have any changes made to the files
passed to ``IMPLICIT_DEPENDS``
trigger a reconfigure so that the dependencies can be recomputed. For
Makefiles you can don't need to do this and can take the "fast path"
instead.

[1] https://cmake.org/Bug/view.php?id=13234
[2] https://ninja-build.org/manual.html#_depfile

Dan.
-- 

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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

On 30 November 2015 at 18:35, Brad King <brad.k...@kitware.com> wrote:
> On 11/30/2015 01:32 PM, Dan Liew wrote:
>> It works but only for makefile generators... That's an annoying
>> limitation. I'll file a feature request to get this implemented for
>> other generators.
>
> It happens to work for Makefile generators because it was easy to
> implement since those generators already do their own scanning.
> For other generators it is not possible to implement.

Well I found the open issue [1]. It's been open for a while.

It doesn't look completely impossible. For Ninja, it looks like it has
some support for compiler
generated dependency files [2]. Incorporating that into
``add_custom_command()`` would require
an extra call to the host compiler to generate the dependencies when
the custom command is invoked.

For other generators that are Makefile or Ninja based I guess that
approach wouldn't work.

There is an alternative which I suggested in the post. Have CMake
determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
at configure
time and spit that into the build files of the generator (that would
work for any generator). Then have any changes made to the files
passed to ``IMPLICIT_DEPENDS``
trigger a reconfigure so that the dependencies can be recomputed. For
Makefiles you can don't need to do this and can take the "fast path"
instead.

[1] https://cmake.org/Bug/view.php?id=13234
[2] https://ninja-build.org/manual.html#_depfile

Dan.
-- 

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-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

> For other generators that are Makefile or Ninja based I guess that
> approach wouldn't work.

Sorry that should read

For other generators that **aren't** Makefile or Ninja based I guess
that approach wouldn't work.
-- 

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-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi Michael,

> Not going into detail as I'm typing on the phone, but this really sounds
> like a case where a "SuperBuild"
> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
> can help you to simplify things a lot.

Thanks for the suggestion but this certainly is not a case where a
"SuperBuild" would help. CMake does not know how to configure a
compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
going to help.

Dan.
-- 

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] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi Michael,

> Not going into detail as I'm typing on the phone, but this really sounds
> like a case where a "SuperBuild"
> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
> can help you to simplify things a lot.

Thanks for the suggestion but this certainly is not a case where a
"SuperBuild" would help. CMake does not know how to configure a
compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
going to help.

Dan.
-- 

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] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 18:03, Dan Liew <d...@su-root.co.uk> wrote:
> Hi,
>
> On 30 November 2015 at 08:09, Petr Kmoch <petr.km...@gmail.com> wrote:
>> Hi Dan,
>>
>> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
>> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>>
>> I don't have direct experience with it, but it looks like it could do what
>> you're looking for.
>
> Oh. That sounds exactly like what I'm looking for!

It works but only for makefile generators... That's an annoying
limitation. I'll file a feature request to get this implemented for
other generators.

Dan.
-- 

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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 08:09, Petr Kmoch  wrote:
> Hi Dan,
>
> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>
> I don't have direct experience with it, but it looks like it could do what
> you're looking for.

Oh. That sounds exactly like what I'm looking for!

Thanks,
Dan.
-- 

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] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 08:09, Petr Kmoch  wrote:
> Hi Dan,
>
> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>
> I don't have direct experience with it, but it looks like it could do what
> you're looking for.

Oh. That sounds exactly like what I'm looking for!

Thanks,
Dan.
-- 

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] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

# TL;DR

I need a way of determining the header file dependencies of a source
file and inform CMake about them. CMake doesn't do this automatically
because I'm using custom commands for the compilation step so CMake
doesn't do it's usual magic of automatically inferring source file
header dependencies. This is because this part of the compilation step
requires a separate C++ compiler (completely independent from the one
that CMake detects at configure time).

Is there a way of doing this that will also regenerate the
dependencies if the source file changes?

# Long version

A C++ project that I work on [1] is (amongst other things) a compiler.
In order to compile applications it needs to link in a supporting
runtime that is compiled to LLVM bitcode which is linked into the
applications it compiles.

The supporting runtime is written in C++ and compiled with Clang. The
compilation of the runtime is currently achieved using
``add_custom_command()`` and so I am not using CMake's in built
support for detecting header file dependencies. The reason for doing
it this way is because the LLVM bitcode compiler (i.e. Clang) **is
not** the same compiler as the host C++ compiler for the project. For
example the host code might be built with MSVC but the supporting
runtime is **always** built with Clang.

To see this concretely take a look at [2].

The build works correctly if you build from a clean build directory.
It does not work correctly if you perform a rebuild and change one of
the header files that the supporting runtime depends on. This is
because CMake doesn't know that the runtime source files depend on the
header files and so doesn't rebuild the relevant source files.

I can obviously tell CMake about these manually (adding more entries
under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this
is very cumbersome.

What I really need is a way to

* Automatically infer the dependencies of a source file and tell CMake
about them
* Have the dependencies automatically regenerated if the source file
changes (someone could add or remove a header file include).

In a simple Makefile build system this typically achieved by doing
something like this:

```
all:: $(SRCS:.cpp:.o)

SRCS := foo.cpp bar.cpp

# Include SRC file dependencies generated by the compiler if they exist
-include $(SRCs:.cpp=.d)

%.o : %.cpp
  $(CXX) -c $< -o $@ -MP -MMD -MF $*.d
```

Note the ``-M*`` flags get the compiler when it runs to generate
additional makefile rules that will get included next time a build
happens.

I don't really know how to do the same thing with CMake. One idea is
at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each
runtime source file, extract the dependencies then pass them to
``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies
regenerated if the runtime source file changes then I would need to
somehow get CMake to reconfigure every time this happens.

I don't like this idea very much due to

* Having to invoke Clang manually to determine the dependencies. CMake
already knows how to determine source file dependencies, but this
functionality (AFAIK) isn't exposed to me.

* Reconfiguring every time one of the runtime source file changes is
annoying (configuring can be slow sometimes).

Does anyone have any other ideas? CMake obviously knows how to do all
this stuff already for source files being compiled for the detected
host C++ compiler, I just don't know how to get at this logic for
source files that need to be built with a second independent C++
compiler.

[1] https://github.com/halide/Halide
[2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140

Thanks,
Dan.
-- 

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_BUILD_TYPE and exact control of compiler options

[Dan Liew]

Hi,


> - If not, what is the best/official way to get exact control over the compiler
> and linker options used?

I had to do something similar recently where I didn't want
``-DNDEBUG`` to be in any of the configurations.

I used  ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file
containing overrides, this must be set before calling ``project()``

```
set(CMAKE_USER_MAKE_RULES_OVERRIDE
${CMAKE_CURRENT_SOURCE_DIR}/cmake/c_flags_override.cmake)
project(ABC C)
```

The contents of ``c_flags_override.cmake`` looks like this

```
if (("${CMAKE_C_COMPILER_ID}" MATCHES "Clang") OR
("${CMAKE_C_COMPILER_ID}" MATCHES "GNU"))
# Taken from Modules/Compiler/GNU.cmake but -DNDEBUG is removed
  set(CMAKE_C_FLAGS_INIT "")
  set(CMAKE_C_FLAGS_DEBUG_INIT "-g")
  set(CMAKE_C_FLAGS_MINSIZEREL_INIT "-Os")
  set(CMAKE_C_FLAGS_RELEASE_INIT "-O3")
  set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-O2 -g")
else()
  message(FATAL_ERROR "Overrides not set for compiler ${CMAKE_C_COMPILER_ID}")
endif()
```

I'm not sure if this is really the correct route to go down though for
your use case.

Dan.
-- 

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] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

On 4 August 2015 at 14:32, Iosif Neitzke iosif.neitzke+cm...@gmail.com wrote:
 And:

 A target created in the same directory (CMakeLists.txt file) that
 specifies any output of the custom command as a source file is given a
 rule to generate the file using the command at build time.

 http://www.cmake.org/cmake/help/v3.3/command/add_custom_command.html

That documentation is for the first signature of
``add_custom_command()`` (Generating Files section in the docs) which
I'm not using here. I'm using the other signature (Build Events in the
docs) which mentions nothing about add_custom_command(TARGET ...)
working only on targets created in the same directory.

CMakes behaviour could be clearer here, it should probably raise an
error rather than pretending that the target doesn't exist which is
clearly does.

 But it's not super clear in the documentation.

Agreed!
-- 

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] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

 foolib is defined in this CMakeLists.txt:
 https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt

 That is the (only) context in which you can extend the definition of the
 target with custom commands.

Since when? I haven't seen that documented anywhere. IMHO this
behavior is counter-intuitive, in general I expect the scope of a
target to not depend on the cmake command I am trying to use. Seeing
as targets seem to be visible globally to all the commands (that I've
used so far) it seems to reasonable to me to expect
add_custom_command() to be able to see these targets too.
-- 

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] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

 foolib is defined in this CMakeLists.txt:
 https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt

 That is the (only) context in which you can extend the definition of the
 target with custom commands.

Since when? I haven't seen that documented anywhere. IMHO this
behavior is counter-intuitive, in general I expect the scope of a
target to not depend on the cmake command I am trying to use. Seeing
as targets seem to be visible globally to all the commands (that I've
used so far) it seems to reasonable to me to expect
add_custom_command() to be able to see these targets too.
-- 

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] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

Hi,

I'm almost certain this is a bug but I thought I'd ask the mailing lists first.

I'm observing a problem with CMake's add_custom_command() when using
the TARGET version of the signature.

Code demonstrating the issue can be found at [1]

In ``test/CMakeLists.txt`` [2] I try using add_custom_command() to
build and run an executable every time the ``foolib`` library is
rebuilt. The motivation behind doing this is to have some very quick
and simple library tests run every time the library is built.

This use of add_custom_command() does not seem to work at all.

Using CMake 2.8.12.2 the requested command is not invoked when running
``make foolib``. I am aware that the custom command won't run if
``foolib`` has already been made but even if I do a clean build the
custom command specified does not run.

When using CMake 3.2.3 I get a warning about CMP0040 which complains
that the target passed to the TARGET argument in
``add_custom_command()`` doesn't exist.

```
  Policy CMP0040 is not set: The target in the TARGET signature of
  add_custom_command() must exist.  Run cmake --help-policy CMP0040 for
  policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.

  The target name foolib is unknown in this context.
This warning is for project developers.  Use -Wno-dev to suppress it
```


This doesn't make sense the target **clearly exists and is in scope**
because the ``simple_test`` executable links against it and also it is
possible to read properties of the target.

Seems like there's some sort of weird scope issue going on here.

Thoughts?

[1] https://github.com/delcypher/cmake_add_custom_command_bug
[2] 
https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/test/CMakeLists.txt

Thanks,
Dan Liew
-- 

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] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

Hi,

I'm almost certain this is a bug but I thought I'd ask the mailing lists first.

I'm observing a problem with CMake's add_custom_command() when using
the TARGET version of the signature.

Code demonstrating the issue can be found at [1]

In ``test/CMakeLists.txt`` [2] I try using add_custom_command() to
build and run an executable every time the ``foolib`` library is
rebuilt. The motivation behind doing this is to have some very quick
and simple library tests run every time the library is built.

This use of add_custom_command() does not seem to work at all.

Using CMake 2.8.12.2 the requested command is not invoked when running
``make foolib``. I am aware that the custom command won't run if
``foolib`` has already been made but even if I do a clean build the
custom command specified does not run.

When using CMake 3.2.3 I get a warning about CMP0040 which complains
that the target passed to the TARGET argument in
``add_custom_command()`` doesn't exist.

```
  Policy CMP0040 is not set: The target in the TARGET signature of
  add_custom_command() must exist.  Run cmake --help-policy CMP0040 for
  policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.

  The target name foolib is unknown in this context.
This warning is for project developers.  Use -Wno-dev to suppress it
```


This doesn't make sense the target **clearly exists and is in scope**
because the ``simple_test`` executable links against it and also it is
possible to read properties of the target.

Seems like there's some sort of weird scope issue going on here.

Thoughts?

[1] https://github.com/delcypher/cmake_add_custom_command_bug
[2] 
https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/test/CMakeLists.txt

Thanks,
Dan Liew
-- 

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] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

On 4 August 2015 at 14:20, Iosif Neitzke iosif.neitzke+cm...@gmail.com wrote:
 Dependencies listed with the DEPENDS argument may reference files and
 outputs of custom commands created with add_custom_command() in the
 same directory (CMakeLists.txt file).

 http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:add_custom_target

That doesn't really seem to have anything to do with the issue I'm
using. That's the documentation for the DEPENDS argument to
add_custom_target() which I'm not using here. I'm using
add_custom_command()
-- 

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] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

   I haven't seen that documented anywhere. IMHO this
 behavior is counter-intuitive, in general I expect the scope of a
 target to not depend on the cmake command I am trying to use.


 I think it is sensible that the definition of a target is scoped to one
 single directory.
 Where the definition of a target consists of e.g. sources, properties,
 dependencies and custom commands related to the target.

 You can reference/query global targets in other directories but you can not
 change them.

It seems sensible from a safety standpoint (preventing targets from
accidentally being modified from other directories) but it also
limiting in that
it prevents certain directory layouts (like the one I tried in my example).
-- 

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] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

   I haven't seen that documented anywhere. IMHO this
 behavior is counter-intuitive, in general I expect the scope of a
 target to not depend on the cmake command I am trying to use.


 I think it is sensible that the definition of a target is scoped to one
 single directory.
 Where the definition of a target consists of e.g. sources, properties,
 dependencies and custom commands related to the target.

 You can reference/query global targets in other directories but you can not
 change them.

It seems sensible from a safety standpoint (preventing targets from
accidentally being modified from other directories) but it also
limiting in that
it prevents certain directory layouts (like the one I tried in my example).
-- 

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] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

For reference I've opened up a bug report
http://www.cmake.org/Bug/view.php?id=15681
-- 

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] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

For reference I've opened up a bug report
http://www.cmake.org/Bug/view.php?id=15681
-- 

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] Incorrect path handling in generation of export files

[Dan Liew]

Hi,

There is a bug in CMake's export file generator where it does not
correctly escape Windows paths when generating export files . This was
originally reported on the LLVM mailing list [1]. I'm using CMake
3.2.3.

In a generated export file I see

```
# Create imported target LLVMDebugInfoPDB
add_library(LLVMDebugInfoPDB STATIC IMPORTED)

set_target_properties(LLVMDebugInfoPDB PROPERTIES
  INTERFACE_LINK_LIBRARIES LLVMObject;LLVMSupport;C:\Program Files
(x86)\Microsoft Visual Studio 14.0\DIA SDK\lib\diaguids.lib
)
```

One of the libraries listed in the INTERFACE_LINK_LIBRARIES has
invalid syntax because the slashes have not been escaped. I believe
the correct solution would be to have CMake convert all paths to CMake
style paths before writing them to export files.


Brad King (CC'ed) had this comment

```
However, CMake should also be taught to escape the backslashes correctly
when generating the export files.  Take a look at

 Source/cmExportFileGenerator.cxx
 Source/cmExportBuildFileGenerator.cxx
 Source/cmExportInstallFileGenerator.cxx

in the CMake source tree.  There are several places that just generate
double quotes around a raw value that should instead use EscapeForCMake.
```

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/086958.html

Thanks,
Dan
-- 

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] Recursively include target include directories only

[Dan Liew]

 Can you explain what you mean by strong and weak symbols?


Google is your friend

https://en.wikipedia.org/wiki/Weak_symbol

http://stackoverflow.com/questions/2290587/gcc-style-weak-linking-in-visual-studio
-- 

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] Recursively include target include directories only

[Dan Liew]

Hi,

On 18 June 2015 at 12:16, Robert Dailey rcdailey.li...@gmail.com wrote:
 On Thu, Jun 18, 2015 at 12:02 PM, Dan Liew d...@su-root.co.uk wrote:
 Can you explain what you mean by strong and weak symbols?


 Google is your friend

 https://en.wikipedia.org/wiki/Weak_symbol

 http://stackoverflow.com/questions/2290587/gcc-style-weak-linking-in-visual-studio

 Normally Google is my friend, but today it hates me. Because no such
 feature exists for MSVC that I saw.

The stackoverflow suggests it is possible for MSVC.

Thinking about it some more I think what I'm suggesting is the wrong
approach. If you're writing C++ code you should avoid coupling your
classes to allow dependency injection (i.e. you pick how classes are
coupled at run time not at compile time). If your classes are written
with dependency injection in mind then you don't need the weak symbol
stuff I was talking about.
-- 

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] Recursively include target include directories only

[Dan Liew]

 This is the approach that the LLVM project uses which is very simple
 and very clean (take a look at the sources). This also works very well
 for installing your header files, the contents of ${CMAKE_SOURCE_DIR}
 just need to be copied into /usr/include .

Oops I meant to say the contents of

${CMAKE_SOURCE_DIR}/include

and

${CMAKE_BINARY_DIR}/include

can be copied into /usr/include.
-- 

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] Recursively include target include directories only

[Dan Liew]

 The reason I'm asking this question is because of how I handle unit
 tests in CMake right now. Instead of just defining an executable
 target for the test and then adding a link dependency on the library
 containing the class or set of classes to be tested, I am manually
 pulling in the CPP and H file into the test target and building them
 inline with the test code. This is to support mocking (I can't mock
 objects already compiled into a static library). As such, I need the
 transitive includes and defines, but I do not want the transitive link
 libraries.

Okay with that context what I suggested isn't going to completely
solve the problem.

It is actually possible to link with your static library and a mock
implementation by making the symbols that you want mock in the library
weak. Then when you link the linker will choose the strong (the mock)
implementation in preference to the weak implementation. It probably
isn't desirable to have weak symbols in a shipping library just to
make unit testing easier so you could build two versions of the
library (one with weak symbols and one without).
This would allow to use target_link_libraries() but not get link
conflicts between your mock implementation and the real
implementation.

However Petr's suggestion also sounds good (although I haven't tested it).
-- 

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] Recursively include target include directories only

[Dan Liew]

On 17 June 2015 at 12:28, Robert Dailey rcdailey.li...@gmail.com wrote:
 Is there a way to only take (recursively) the include directiories from
 a target or set of targets? I know that include directories propagate
 when passing targets to target_link_libraries(), but I do not want to
 link the libs; I only want the include directories.

 How can I do this? Thanks.

I presume recursively you mean propagating the required include
directories between targets rather anything to do recursively handling
directories.

As you mentioned include directories do propagate but this only
happens under certain conditions (when using PUBLIC or INTERFACE
scopes).

I don't know of a way of doing it without target_link_libraries but if
it is necessary for you to do this it sounds like you have bigger
problems relating to the way you have your project header files
organised.

The approach I use for include directories is to have all includes for
the project rooted in a single include directory in the source tree
and have all includes relative to that directory. Then if I you

```
include_directories(${CMAKE_SOURCE_DIR}/include)
include_directories(${CMAKE_BINARY_DIR}/include) # for generated header files
```

in the root of the project you never need to set include paths
anywhere else for sources that are in your project tree. E.g. if there
is header file in

${CMAKE_SOURCE_DIR}/include/project/moduleA/interface.h

then in the sources this is included as

#include project/moduleA/interface.h

(note there are never relative header file includes).

This is the approach that the LLVM project uses which is very simple
and very clean (take a look at the sources). This also works very well
for installing your header files, the contents of ${CMAKE_SOURCE_DIR}
just need to be copied into /usr/include .
-- 

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] (no subject)

[Dan Liew]

Hi,

On 21 May 2015 at 23:00,  lucas.pet...@engilitycorp.com wrote:
 Hello,

 I am trying to compile a code written in C, but using an external library
 that contains C++ functions. I am on a Cray system and everything works if I
 manually link with the cray CC wrapper. When I change the linker language
 with this command:

 set_property(TARGET adh PROPERTY LINKER_LANGUAGE CXX)

 CMake is using the CC wrapper, but adding -lstdc++ to the link line. This
 causes an error. Can anyone tell me how to not get this added library?

Why are you telling CMake that the linker language is C++ in the
target you are building is C code? The C code you are compiling be
must calling into extern C functions in the external library you
mention which means the linker (at compile time) should not need to
know about C++ at all. At runtime the linker needs to know that your
external library depends on C++ but you don't need to be concerned
with this because when your external library was built those
dependencies end up in the shared library.

E.g.

```
$ readelf -d /usr/lib/libboost_program_options.so
...
  TagType Name/Value
...
0x0001 (NEEDED) Shared library: [libstdc++.so.6]
...
```

Does your target build if you just leave  LINKER_LANGUAGE alone (i.e.
set C)? I would expect that it would.

Thanks,
Dan.
-- 

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] OBJECT libraries and target visibility properties seem broken

[Dan Liew]

Hi,

I'm not sure if this is actually a bug but I've been relying on the
OBJECT library[1] feature as a convenient way of having source code in
multiple directories be put into a shared library. I now have a need
to hide the symbols in my libraries but I've found that using OBJECT
libraries means that setting the CXX_VISIBILITY_PRESET and
VISIBILITY_INLINES_HIDDEN on the final resulting shared library and/or
constituent OBJECT libraries does absolutely nothing.

Here's an example. I've kept everything in a single directory for
simplicity but the real world use case would be that  ``fooX`` and
``barX`` OBJECT libraries are defined in a sub directory.

```
project(objlibtest)
cmake_minimum_required(VERSION 3.0)

add_library(fooX OBJECT
foo.cpp)

add_library(barX OBJECT
bar.cpp)

add_library(result SHARED $TARGET_OBJECTS:fooX $TARGET_OBJECTS:barX)
set_target_properties(result fooX barX PROPERTIES
CXX_VISIBILITY_PRESET hidden
VISIBILITY_INLINES_HIDDEN 1)
```

If you watch the build (``make VERBOSE=1``) you'll see that neither
``-fvisibility=hidden`` nor ``-fvisibility-inlines-hidden`` get passed
to the compiler.

If the CMakeLists.txt file is like this

```
project(objlibtest)
cmake_minimum_required(VERSION 3.0)

add_library(result SHARED foo.cpp bar.cpp)
set_target_properties(result PROPERTIES
CXX_VISIBILITY_PRESET hidden
VISIBILITY_INLINES_HIDDEN 1)
```

then setting ``-fvisibility=hidden`` and
``-fvisibility-inlines-hidden`` get passed.

Is this a bug or it intentional? If the only purpose of OBJECT
libraries is to provide a convenient way to group source files in
other directories then this seems like a bug.

[1] http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library

Thanks,
Dan.
-- 

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