from:"David"

>
> >What generator are you using?
>

Ninja


> That thread seems to contain a lot of misunderstandings about the issue.
>
> If you are using the Makefile generator then refer to
> https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake.
> After building the project for the first time inspect the depend.make
> files that are generated to verify if the headers are being picked up
> correctly as a dependency.
>

Thanks, I made a mistake and was touching the wrong header file. Sorry
about that. Dependencies are correctly generated and working. There seems
to be no need to add the header files to the list of sources.

BTW It seems that dependencies for header files in the same path as the
sources are generated implicitly. Is that expected?

Thanks for your help.

>
>
-- 

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

[CMake] How to properly add include directories?

Hi again,

My CMakeLists.txt file for my shared library contains:

add_library(MyLib SHARED my_source.cpp etc.)
target_include_directories( MyLib PRIVATE ../MyHeaders)

The library builds ok, but there is no dependency on directory ../MyHeaders
- touching a header file does not result in a re-compile of dependent
source files.

There's a discussion here:

https://stackoverflow.com/questions/13703647/how-to-properly-add-include-directories-with-cmake

Opinion seems divided over whether or not it is necessary to add the header
files to the list of source files for the target, e.g.:

set(SOURCES file.cpp file2.cpp ${YOUR_DIRECTORY}/file1.h
${YOUR_DIRECTORY}/file2.h)
add_library(test ${SOURCES})

Please will you tell me what is the best practice?
-- 

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] Concerning ninja -v

>
> >Does just invoking ninja with -v not show verbosity? That should do it.
> > don't believe CMAKE_VERBOSE_MAKEFILE affects Ninja builds.
>
> >Kyle
>

Yes thanks, that does do it. I just wondered whether there was a neater way
for when CMake is invoked by an IDE such as VS Code with the cmake-tools
extension. But it seems that I can specify option '-v' to that tool 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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Concerning ninja -v

I have a simple CMake project with subdirectories:

cmake_minimum_required(VERSION 3.10)
project(MyProject VERSION 1.0.0)

set(CMAKE_VERBOSE_MAKEFILE ON CACHE BOOL "ON")

add_subdirectory(say-hello)
add_subdirectory(hello-exe)

Will the 'CMAKE_VERBOSE_MAKEFILE' option be inherited by the CMakeLists.txt
files in the subdirectories?

I want to run ninja with the '-v' option for verbosity but the above 'set'
command is not achieving this. What do I need to do differently?

(I am running CMake 3.15.4 on WSL - Ubuntu 18.04).
-- 

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] Help request for hierarchical directory example

2019-10-18 Thread David Aldrich

Hi Eric

Thanks very much for your answer. I understand now.

David

On Fri, Oct 18, 2019 at 12:57 PM Eric Noulard 
wrote:

>
>
> Le ven. 18 oct. 2019 à 12:53, David Aldrich 
> a écrit :
>
>> Hi
>>
>>
>>
>> I'm learning how to use hierarchical directories in CMake and am trying
>> to get an example to work that I saw on YouTube. The example isn't doing
>> what I expect so I would be grateful for some help in understanding why.
>>
>>
>>
>> I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.
>>
>>
>>
>> I have a project called 'cmake-good' that should build library
>> 'libsay-hello.a' and executable 'cmake-good'.
>>
>>
>>
>> Here's the directory tree (excluding CMake artifacts which I don't think
>> I need to show):
>>
>>
>>
>> ├── CMakeLists.txt
>>
>> ├── build
>>
>> │   ├── CMakeCache.txt
>>
>> │   ├── CMakeFiles
>>
>> │   ├── Makefile
>>
>> │   ├── cmake_install.cmake
>>
>> │   ├── hello-exe
>>
>> │   │   ├── Makefile
>>
>> │   │   ├── cmake-good
>>
>> │   └── say-hello
>>
>> │   ├── Makefile
>>
>> │   └── libsay-hello.a
>>
>> ├── hello-exe
>>
>> │   ├── CMakeLists.txt
>>
>> │   └── main.cpp
>>
>> ├── say-hello
>>
>> ├── CMakeLists.txt
>>
>> └── src
>>
>> └── say-hello
>>
>> ├── hello.cpp
>>
>> └── hello.hpp
>>
>>
>>
>> Here are the CMakeLists.txt files:
>>
>>
>>
>> 1) Top level CMakeLists.txt:
>>
>>
>>
>> cmake_minimum_required(VERSION 3.10)
>>
>> project(MyProject VERSION 1.0.0)
>>
>> add_subdirectory(say-hello)
>>
>> add_subdirectory(hello-exe)
>>
>>
>>
>> 2) hello_exe/CMakeLists.txt:
>>
>>
>>
>> add_executable(cmake-good main.cpp )
>>
>> target_link_libraries(cmake-good PRIVATE say-hello)
>>
>>
>>
>> 3) say-hello/CMakeLists.txt:
>>
>>
>>
>> add_library(
>>
>> say-hello
>>
>> src/say-hello/hello.hpp
>>
>> src/say-hello/hello.cpp
>>
>> )
>>
>> target_include_directories(say-hello PUBLIC
>> "${CMAKE_CURRENT_SOURCE_DIR}/src")
>>
>>
>>
>> My problem is that I expect to see:
>>
>>
>>
>> hello-exe/cmake-good
>>
>> say-hello/libsay-hello.a
>>
>>
>>
>> but I see:
>>
>>
>>
>> build\hello-exe\cmake-good
>>
>> build\say-hello\libsay-hello.a
>>
>>
>>
>> Why is that?
>>
>
> Because build/ is your build directory and you apparently did an
> out-of-source build (which is good practice)
> see :
> https://gitlab.kitware.com/cmake/community/wikis/FAQ#out-of-source-build-trees
>
> You should have done something like:
>
> cd cmake-good/build
> cmake ..
> make
>
> In this case everything the build is generating (CMake artefact, build
> artefact etc...) gets written build/
> the directory hierarchy in build will have the same structure as your
> source tree.
>
> This is an expected behaviour.
>
>
>
> --
> Eric
>
-- 

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

[CMake] Help request for hierarchical directory example

2019-10-18 Thread David Aldrich

Hi



I'm learning how to use hierarchical directories in CMake and am trying to
get an example to work that I saw on YouTube. The example isn't doing what
I expect so I would be grateful for some help in understanding why.



I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.



I have a project called 'cmake-good' that should build library
'libsay-hello.a' and executable 'cmake-good'.



Here's the directory tree (excluding CMake artifacts which I don't think I
need to show):



├── CMakeLists.txt

├── build

│   ├── CMakeCache.txt

│   ├── CMakeFiles

│   ├── Makefile

│   ├── cmake_install.cmake

│   ├── hello-exe

│   │   ├── Makefile

│   │   ├── cmake-good

│   └── say-hello

│   ├── Makefile

│   └── libsay-hello.a

├── hello-exe

│   ├── CMakeLists.txt

│   └── main.cpp

├── say-hello

├── CMakeLists.txt

└── src

└── say-hello

├── hello.cpp

└── hello.hpp



Here are the CMakeLists.txt files:



1) Top level CMakeLists.txt:



cmake_minimum_required(VERSION 3.10)

project(MyProject VERSION 1.0.0)

add_subdirectory(say-hello)

add_subdirectory(hello-exe)



2) hello_exe/CMakeLists.txt:



add_executable(cmake-good main.cpp )

target_link_libraries(cmake-good PRIVATE say-hello)



3) say-hello/CMakeLists.txt:



add_library(

say-hello

src/say-hello/hello.hpp

src/say-hello/hello.cpp

)

target_include_directories(say-hello PUBLIC
"${CMAKE_CURRENT_SOURCE_DIR}/src")



My problem is that I expect to see:



hello-exe/cmake-good

say-hello/libsay-hello.a



but I see:



build\hello-exe\cmake-good

build\say-hello\libsay-hello.a



Why is that?
-- 

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

[CMake] How to make a hierarchical application using CMake?

2019-10-14 Thread David Aldrich

Hi



I am trying to convert a large software project from makefiles to CMake.
The project is organised as a set of shared ‘star’ libraries, linked to a
static ‘kernel’ library. The current directory arrangement is:



|--stars

| |-- star1_lib

|  |-- source files

|  |-- makefile

| |-- star2_lib

|  |-- source files

|  |-- makefile

| |-- solibs

|  |-- Release

| |-- .so files

|

|--kernel

| |-- source files

| |-- makefile

| |-- Release

|  |-- kernel.a

|

|--application

  |-- makefile

  |-- Release

   |-- myapp.exe



In high-level terms, how could I implement this using CMake, such that
invoking ‘make’ in directory ‘application’ invokes a make of each shared
and static library, and links them to form ‘myapp.exe’?



(I understand the basics of CMake, the issue here is how to handle the make
of source code and libraries spread across a directory hierarchy).



Best regards



David
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to support separate debug and release build directories?

2019-06-24 Thread David Aldrich

>
> David,
>
> I think a bit more explanation of the philosophy (at least how I
> interpret it) is needed. I see in your emails that you are “targeting
> makefiles”. With CMake you need to really stop thinking this way. Rarely do
> you need to target any specific build system (although those times do come
> up…). A lot of folks I see coming from autoconf to CMake still try to treat
> CMake in the same way. Don’t. There are a few golden rules with CMake that
> if you adhere to those will allow you to use CMake much easier.
>
>
>
> 1: NEVER have the Source directory and the Build directory be the same
> place.
>
> 2: PREFER out-of-source build directories (Not required but helpful)
>
> 3: Try not to target specific generators (makefiles, visual studio, xcode)
>
> 
>

Hi Michael

Thanks very much for your reply and explanation. As a result, I now have
the separate Debug/Release build subdirectories working correctly.

Best regards

David
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to support separate debug and release build directories?

>
> > What would best practice be to provide convenient commands for our
> > developers to easily build the target ?
>
> For the Makefile generator, best practice is to use separate build
> directories (i.e., places where you run cmake) for different
> configurations (i.e., different settings recorded during the
> configuration step).
>
> If you want to provide developers with some known set(s) of
> configuration settings, I suggest wrapper scripts that invoke cmake
> with those settings.
>
> Thanks for your advice. I am not finding it easy to find 'patterns' for
these sort of issues. I would have thought that configuring a project with
separate debug and release directories would be quite typical. But it's
hard to find the recommended way of doing such things. Anyway, I think I am
on the right track now.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to support separate debug and release build directories?

>
> > I would also like this to work if I use the make targets e.g. make
> > debug.
>
> I think that's outside the scope of the Makefile generator.  For that
> generator, CMAKE_BUILD_TYPE is a configuration-wide setting.  If you
> want a different configuration, you need a different build directory
> (where "build directory" is wherever you run cmake).
>

If I don't use make targets (so that user can type 'make debug' etc) the
build command would be more cumbersome:

cmake3 --build -D CMAKE_BUILD_TYPE=Debug .

What would best practice be to provide convenient commands for our
developers to easily build the target ?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to support separate debug and release build directories?

2019-06-21 Thread David Demelier


Le 21/06/2019 à 15:42, David Aldrich a écrit :

Do never test CMAKE_BUILD_TYPE in CMakeLists.txt files, it is
ignored in
multiple generators (e.g. Visual Studio).

Does that mean I shouldn't have this in CMakeLists.txt? :

# Specify a Release build by default
if(NOT CMAKE_BUILD_TYPE)
   set(CMAKE_BUILD_TYPE "Release")
   message(STATUS "Build type not specified: Use Release by default")
endif(NOT CMAKE_BUILD_TYPE)


It may be handy if you're sure that the project will only use single 
generators tools (e.g. make, ninja) otherwise yes it's strongly advised 
to not touch/inspect CMAKE_BUILD_TYPE if your project can be build with 
any kind of generators.


Regards

--
David

--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to support separate debug and release build directories?

>
> Do never test CMAKE_BUILD_TYPE in CMakeLists.txt files, it is ignored in
> multiple generators (e.g. Visual Studio).
>

Does that mean I shouldn't have this in CMakeLists.txt? :

# Specify a Release build by default
if(NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "Release")
  message(STATUS "Build type not specified: Use Release by default")
endif(NOT CMAKE_BUILD_TYPE)


>
> Just use the appropriate variables that contain suffixes regarding the
> configuration.
>
> e.g
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/debug)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/release)
>
> See [0] for a list with _ variables.
>
> [0]: https://cmake.org/cmake/help/v3.15/manual/cmake-variables.7.html
>
> HTH
>

Thank you. That is working for me.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to support separate debug and release build directories?

2019-06-21 Thread David Demelier


Le 21/06/2019 à 15:19, David Aldrich a écrit :
I now want to support separate target directories: build/debug and 
build/release.  I've shown my CMakeLists.txt below. So far I've just 
added an attempt to support build/debug:


if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
     message("debug mode")
     set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")



Do never test CMAKE_BUILD_TYPE in CMakeLists.txt files, it is ignored in 
multiple generators (e.g. Visual Studio).


Just use the appropriate variables that contain suffixes regarding the 
configuration.


e.g

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/debug)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/release)

See [0] for a list with _ variables.

[0]: https://cmake.org/cmake/help/v3.15/manual/cmake-variables.7.html

HTH

--
David
--

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

[CMake] How to support separate debug and release build directories?

Thanks for the help I have received in the past few days. I am making
incremental improvements to my CMake project and have a new challenge.  I
am running CMake 3.13 on Centos 7.6, targeting make.  My CMake file
successfully builds debug or release targets and puts the executable in an
out-of-source build directory.  I have added debug and release make targets
so I can execute 'make debug' etc.

I now want to support separate target directories: build/debug and
build/release.  I've shown my CMakeLists.txt below. So far I've just added
an attempt to support build/debug:

if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
message("debug mode")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")

but:

$ cmake3 -DCMAKE_BUILD_TYPE=DEBUG ..

puts the target into build, not build/debug.

I would also like this to work if I use the make targets e.g. make debug.

Here's my full CMakeLists.txt.  Any advice would be appreciated.

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)

if(NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "Release")
  message(STATUS "Build type not specified: Use Release by default")
endif(NOT CMAKE_BUILD_TYPE)

project(hello_world LANGUAGES CXX)# Among other things, this sets
PROJECT_NAME

add_executable(${PROJECT_NAME} "")

target_include_directories(${PROJECT_NAME}
PRIVATE
${CMAKE_CURRENT_SOURCE_DIR})

target_sources(${PROJECT_NAME}
  PRIVATE
main.cpp
Message.cpp)

ADD_CUSTOM_TARGET(debug
  COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Debug ${CMAKE_SOURCE_DIR}
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target all
  COMMENT "Creating the executable in the debug mode.")

ADD_CUSTOM_TARGET(release
  COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${CMAKE_SOURCE_DIR}
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target all
  COMMENT "Creating the executable in the release mode.")

if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
message("debug mode")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to specify Redhat Developer Toolset compiler?

Thanks for all the replies. I decided to set CC and CXX in .bashrc:

source scl_source enable devtoolset-7
export CXX="/opt/rh/devtoolset-7/root/usr/bin/g++"
export CC="/opt/rh/devtoolset-7/root/usr/bin/gcc"

For reference, the FAQ entry is:
https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-do-i-use-a-different-compiler

I wonder why it says to avoid using set()?
-- 

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

[CMake] How to specify Redhat Developer Toolset compiler?

2019-06-20 Thread David Aldrich

My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:

$ /usr/bin/x86_64-redhat-linux-g++ --version
x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

I have a very simple CMakeLists.txt:

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
project(hello_world LANGUAGES CXX)

add_executable(hello_world "")

target_sources(hello_world
  PRIVATE
main.cpp
Message.hpp
Message.cpp)

I also have Redhat Developer Toolset 7 installed which I can enable in my
bash shell:

$ scl enable devtoolset-7 bash
$ which g++
/opt/rh/devtoolset-7/root/usr/bin/g++
$ g++ --version
g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)

How can I get CMake to use the later version of g++ instead of 4.8.5?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to specify debug version of CRT library for Visual Studio generator?

2019-06-19 Thread David Aldrich

> Just a heads up, CMake 3.15 is introducing policy 91 which removes the
> runtime library from the default set of flags, and instead has targets
> establish what runtime they want.

Thanks for this.

On Tue, Jun 18, 2019 at 7:08 PM Robert Maynard 
wrote:

> Just a heads up, CMake 3.15 is introducing policy 91 which removes the
> runtime library from the default set of flags, and instead has targets
> establish what runtime they want.
>
> For more information see:
> https://cmake.org/cmake/help/v3.15/prop_tgt/MSVC_RUNTIME_LIBRARY.html
>
> On Tue, Jun 18, 2019 at 10:06 AM Eric Dönges  wrote:
> >
> > On 18.06.19 12:53, David Aldrich wrote:
> > > I have a simple CMake project that builds an executable using Visual
> > > Studio 2017:
> >
> >
> > >
> > >  Files 
> > > #   --   Add files to project.   --   #
> > > ###
> > >
> > > file(GLOB SRC_FILES
> > > ${CPP_DIR_1}/*.cpp
> > > ${CPP_DIR_2}/*.cpp
> > > ${CPP_DIR_3}/*.cpp
> > > ${CPP_DIR_4}/*.cpp
> > > ${HEADER_DIR_1}/*.h
> > > )
> > >
> > > # Add executable to build.
> > > add_executable(${PROJECT_NAME}
> > >${SRC_FILES}
> > > )
> > >
> > > if(MSVC)
> > >target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> > > endif(MSVC)
> > >
> > > #=
> > >
> > > The Release build succeeds but the Debug build fails with linker errors
> > > such as:
> > >
> > > [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> > > __imp___CrtDbgReport
> > >
> > > I think this is because the linker is not using the debug version of
> CRT
> > > (C Run-time Library).
> > >
> > > Should CMake select the debug build of CRT automatically or do I need
> to
> > > specify it manually? If so, should I do so using
> CMAKE_EXE_LINKER_FLAGS?
> > >
> >
> > CMake will select the correct CRT automatically if you let it (unless
> > you want the static CRT, in which case you have to override CMake's
> > default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG
> incorrectly:
> >
> > > if(MSVC)
> > >#set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> > > /MD /Od /Zi /EHsc")
> > >set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> > > /Oi /Gy /Zi /EHsc")
> > >set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> > > /GL /Od /Oi /Gy /Zi /EHsc")
> > > endif(MSVC)
> >
> > In case of the setting you've commented out, you are explicitly telling
> > CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
> > since you append the /MD, that is what the compiler will actually use.
> >
> > For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
> > to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
> > you want (and also specifies /MD).
> >
> > I would suggest looking at what flags CMake sets by default (look at the
> > Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
> > only setting those flags that CMake doesn't already. For version 3.14,
> > CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
> > default (assuming you are using MVSC >= 1310, no Clang toolset):
> >
> > /MDd /Zi /Ob0 /Od /GR /EHSC
> >
> > So in your case, it would probably be enough to
> >
> > string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")
> >
> > As a final recommendation, use string(APPEND  ...) (or list(APPEND
> >  ...), if the variable is interpreted as a list) when appending
> > values to existing variables. This makes your intent clearer.
> >
> >
> >  - when appending compiler flags, use the "string(APPEND ...)" command
> > to make is clearer what you are doing).
> > --
> >
> > 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: ht

Re: [CMake] How to specify debug version of CRT library for Visual Studio generator?

2019-06-19 Thread David Aldrich

>
> > On Tue, Jun 18, 2019 at 3:07 PM Eric Dönges  wrote:
> > On 18.06.19 12:53, David Aldrich wrote:
> > > I have a simple CMake project that builds an executable using Visual
> > > Studio 2017:
> >
> >
> > >
> > >  Files 
> > > #   --   Add files to project.   --   #
> > > ###
> > >
> > > file(GLOB SRC_FILES
> > > ${CPP_DIR_1}/*.cpp
> > > ${CPP_DIR_2}/*.cpp
> > > ${CPP_DIR_3}/*.cpp
> > > ${CPP_DIR_4}/*.cpp
> > > ${HEADER_DIR_1}/*.h
> > > )
> > >
> > > # Add executable to build.
> > > add_executable(${PROJECT_NAME}
> > >${SRC_FILES}
> > > )
> > >
> > > if(MSVC)
> > >target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> > > endif(MSVC)
> > >
> > > #=
> > >
> > > The Release build succeeds but the Debug build fails with linker errors
> > > such as:
> > >
> > > [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> > > __imp___CrtDbgReport
> > >
> > > I think this is because the linker is not using the debug version of
> CRT
> > > (C Run-time Library).
> > >
> > > Should CMake select the debug build of CRT automatically or do I need
> to
> > > specify it manually? If so, should I do so using
> CMAKE_EXE_LINKER_FLAGS?
> > >
> >
> > CMake will select the correct CRT automatically if you let it (unless
> > you want the static CRT, in which case you have to override CMake's
> > default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG
> incorrectly:
> >
> > > if(MSVC)
> > >#set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> > > /MD /Od /Zi /EHsc")
> > >set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> > > /Oi /Gy /Zi /EHsc")
> > >set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> > > /GL /Od /Oi /Gy /Zi /EHsc")
> > > endif(MSVC)
> >
> > In case of the setting you've commented out, you are explicitly telling
> > CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
> > since you append the /MD, that is what the compiler will actually use.
> >
> > For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
> > to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
> > you want (and also specifies /MD).
> >
> > I would suggest looking at what flags CMake sets by default (look at the
> > Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
> > only setting those flags that CMake doesn't already. For version 3.14,
> > CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
> > default (assuming you are using MVSC >= 1310, no Clang toolset):
> >
> > /MDd /Zi /Ob0 /Od /GR /EHSC
> >
> > So in your case, it would probably be enough to
> >
> > string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")
> >
> > As a final recommendation, use string(APPEND  ...) (or list(APPEND
> >  ...), if the variable is interpreted as a list) when appending
> > values to existing variables. This makes your intent clearer.
> >
> >
> >  - when appending compiler flags, use the "string(APPEND ...)" command
> > to make is clearer what you are doing).
>
> Thanks for your help and advice. I've followed your suggestions and the
> debug
> and release builds are now working correctly. I produced my CMakeLists.txt
> from
> a Visual Studio solution using a conversion utility. I will need to rework
> it to adopt best practices.
>
>
-- 

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

[CMake] How to specify debug version of CRT library for Visual Studio generator?

2019-06-18 Thread David Aldrich

I have a simple CMake project that builds an executable using Visual Studio
2017:

#==

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)

### Variables. 
# Change if you want modify path or other values. #
###

set(PROJECT_NAME CPlaneTest)
# Output Variables
set(OUTPUT_DEBUG Debug/bin)
set(OUTPUT_RELEASE Release/bin)
# Folders files
set(CPP_DIR_1 ./)
set(CPP_DIR_2 ./)
set(CPP_DIR_3 ./)
set(CPP_DIR_4 ./)
set(HEADER_DIR_1 )

## CMake Project 
#The main options of project#
#

project(${PROJECT_NAME} CXX)

# Define Release by default.
if(NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "Release")
  message(STATUS "Build type not specified: Use Release by default.")
endif(NOT CMAKE_BUILD_TYPE)

# Definition of Macros
add_definitions(
   -D_CONSOLE
   -DUNICODE
   -D_UNICODE
)

## Artefacts Output #
# Defines outputs , depending Debug or Release. #
#

if(CMAKE_BUILD_TYPE STREQUAL "Debug")
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
  set(CMAKE_EXECUTABLE_OUTPUT_DIRECTORY
"${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
else()
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
  set(CMAKE_EXECUTABLE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
endif()

# Flags 
# Defines Flags for Windows and Linux. #


if(MSVC)
   #set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3 /MD
/Od /Zi /EHsc")
   set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od /Oi
/Gy /Zi /EHsc")
   set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3 /GL
/Od /Oi /Gy /Zi /EHsc")
endif(MSVC)
if(NOT MSVC)
   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
   if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
   endif()
endif(NOT MSVC)

 Files 
#   --   Add files to project.   --   #
###

file(GLOB SRC_FILES
${CPP_DIR_1}/*.cpp
${CPP_DIR_2}/*.cpp
${CPP_DIR_3}/*.cpp
${CPP_DIR_4}/*.cpp
${HEADER_DIR_1}/*.h
)

# Add executable to build.
add_executable(${PROJECT_NAME}
   ${SRC_FILES}
)

if(MSVC)
   target_link_libraries(${PROJECT_NAME} ws2_32.lib )
endif(MSVC)

#=

The Release build succeeds but the Debug build fails with linker errors
such as:

[build] CPlaneTest.obj : error LNK2001: unresolved external symbol
__imp___CrtDbgReport

I think this is because the linker is not using the debug version of CRT (C
Run-time Library).

Should CMake select the debug build of CRT automatically or do I need to
specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
-- 

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

[CMake] ExternalProject_Add() setting build command to run external project's makefile

2019-05-31 Thread David Starkweather

Hello
First off, much thanks to all the contributors of cmake. A truly invaluable
build utility. Your efforts
are greatly appreciated.

I've been successfully using cmake to build an external project (the client
library for redis, hiredis)
that has already been downloaded. I was able to do this with
BUILD_IN_SOURCE set to true, like so:

ExternalProject_Add(hiredis
PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/hiredis
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis
BUILD_IN_SOURCE 1
CONFIGURE_COMMAND echo configure
BUILD_COMMAND make static
INSTALL_COMMAND echo install)

However, now i'd like to automatically download the source from github.
So, I switch to
the following:

set(HIREDIS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis)
set(HIREDIS_INCLUDE_DIRS ${HIREDIS_DIR}/include)
ExternalProject_Add(hiredis
  URL https://github.com/redis/hiredis/archive/v0.9.0.tar.gz
  PREFIX ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  DOWNLOAD_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  BUILD_IN_SOURCE 1
  CONFIGURE_COMMAND ""
  BUILD_COMMAND make static
  INSTALL_COMMAND "")

*And I get the following error:*

[  3%] Creating directories for 'hiredis'
[  6%] Performing download step (download, verify and extract) for 'hiredis'
-- Downloading...
   dst='/home/david/projects/clipseekr/hiredis/v0.9.0.tar.gz'
   timeout='none'
-- Using src='https://github.com/redis/hiredis/archive/v0.9.0.tar.gz'
-- Downloading... done
-- extracting...
 src='/home/david/projects/clipseekr/hiredis/v0.9.0.tar.gz'
 dst='/home/david/projects/clipseekr/hiredis'
-- extracting... [tar xfz]
-- extracting... [analysis]
-- extracting... [rename]
-- extracting... [clean up]
-- extracting... done
make[2]: *** [CMakeFiles/hiredis.dir/build.make:93:
hiredis/src/hiredis-stamp/hiredis-download] Error 1
make[1]: *** [CMakeFiles/Makefile2:147: CMakeFiles/hiredis.dir/all] Error 2
make: *** [Makefile:163: all] Error 2

It seems cmake is trying to invoke its internal cmake make files, rather
than just run the "make static"
build command.  How do I just run the the "make static" command directly?

Once again, thanks.
starkdg
-- 

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

[CMake] ExternalProject_Add() Trouble Invoking Build Command to run the projects makefile

2019-05-31 Thread David Starkweather

set(HIREDIS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis)
set(HIREDIS_INCLUDE_DIRS ${HIREDIS_DIR}/include)
ExternalProject_Add(hiredis
  URL https://github.com/redis/hiredis/archive/v0.9.0.tar.gz
  PREFIX ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  DOWNLOAD_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  BUILD_IN_SOURCE 1
  CONFIGURE_COMMAND ""
  BUILD_COMMAND make static
  INSTALL_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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Building a repo with multiple applications and install process

2019-02-06 Thread David Jobet

Hello,

so I didn't get a lot of answers, here's a quick POC which only uses
add_subdirectory() / include_guard() for more questions.

/CMakeLists.txt
/app1/CMakeLists.txt
/app2/CMakeLists.txt
/common/CMakeLists.txt

We have app1 depending on common, and app2 depending on common.
All 3 projects are living in the same mono-repo.

With those CMakeLists.txt, I'm able to build/install app1, app2, and
common as standalone projects with the following command line
e.g for app1 :
mkdir build_app1 && cd build_app1 && cmake -DCMAKE_INSTALL_PREFIX=
/path/to/app1 && make && DESTDIR=dist make install

I'm also able to build all apps at once using the following
mkdir build_all && cd build_all && cmake -DCMAKE_INSTALL_PREFIX=
/path/to/root && make && DESTDIR=dist make install

See below for the content of the files.

Now the question :
Do you think it would be possible to use the "build all" approach to
populate all .o, libs and executables, then to reconfigure the build
dir, say for app1 so I can then issue "make install" only for app1 ?
This would involve the "build all" project to have the same layout as
the "app1" project which currently is not the case.
In the "build all" project, app1 is a directory
In the "app1" project, app1 is a binary

Thanks for your help

David

---
/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)

project(main-klib CXX)

add_subdirectory(app1)
add_subdirectory(app2)
add_subdirectory(common)

---
/app1/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
include_guard(GLOBAL)

project(app1 CXX)

add_subdirectory(../common common)

add_executable(app1 main.cc)
target_link_libraries(app1 common::lib)

install(
   TARGETS app1
   RUNTIME DESTINATION bin
)

---
/app2/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
include_guard(GLOBAL)

project(app2 CXX)

add_subdirectory(../common common)

add_executable(app2 main.cc)
target_link_libraries(app2 common::lib)

install(
   TARGETS app2
   RUNTIME DESTINATION bin
)

---
/common/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
include_guard(GLOBAL)

project(common CXX)

add_library(common common.cc)
add_library(common::lib ALIAS common)
target_include_directories(common PUBLIC ${PROJECT_SOURCE_DIR})

install(
   FILES common.py
   DESTINATION site-packages
)

On Tue, Feb 5, 2019 at 10:05 AM David Jobet  wrote:
>
> Hello,
>
> at work, we have a mono-repo with multiple applications/libs (dozens).
> The build phase is ok, but I'm not sure about the release process.
>
> When we release, we release one application at a time.
> (CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is true)
> In order to speed up releases, we always perform an incremental build.
>
> Unfortunately, we don't have one unique release process :
> process 1 :
> - a Jenkins pipeline executes some automatic tests then release the
> binary to production. This Jenkins pipeline only builds this single
> application, then executes the install step, then packages the binary
> with some auxiliary files for deployment in prod.
> process 2 :
> - the whole source tree is built regularly through Jenkins, then, from
> another Jenkins pipeline, an install step will be performed in the
> last built directory to deploy only the required application
>
> Both process 1 and process 2 are built in our CMakeLists.txt.
>
> Process 1 just uses regular install directives + ninja install
> Pros : simple
> Cons : install step can be costly
>
> Install step can be costly because, as the build directory is not
> emptied, the install step will install every single binaries left over
> from a previous build that have an install rule.
> Also, we have install directives for non binary files (python files
> for example) which will be installed unconditionally every time.
>
> Process 2 is not triggered through the install step but as a regular
> build target. Under the hood, the build step will add a POST_BUILD
> step attached to the target that will invoke "cmake -P
> ${CMAKE_BINARY_DIR}/cmake_install.cmake -DCOMPONENT=${component}"
> Pros : more "chirurgical", only install what's required
> Cons : - if an application depends on several components, we need to
> describe this in cmake (dependencies are described twice : once for
> the build, once for the install)
>- need to maintain an extra "non standard" layer (albeit a small layer)
>
> At this point, I'd like to ask if you see simple steps we could take
> to stay as simple and standard as possibl

[CMake] Building a repo with multiple applications and install process

2019-02-05 Thread David Jobet

Hello,

at work, we have a mono-repo with multiple applications/libs (dozens).
The build phase is ok, but I'm not sure about the release process.

When we release, we release one application at a time.
(CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is true)
In order to speed up releases, we always perform an incremental build.

Unfortunately, we don't have one unique release process :
process 1 :
- a Jenkins pipeline executes some automatic tests then release the
binary to production. This Jenkins pipeline only builds this single
application, then executes the install step, then packages the binary
with some auxiliary files for deployment in prod.
process 2 :
- the whole source tree is built regularly through Jenkins, then, from
another Jenkins pipeline, an install step will be performed in the
last built directory to deploy only the required application

Both process 1 and process 2 are built in our CMakeLists.txt.

Process 1 just uses regular install directives + ninja install
Pros : simple
Cons : install step can be costly

Install step can be costly because, as the build directory is not
emptied, the install step will install every single binaries left over
from a previous build that have an install rule.
Also, we have install directives for non binary files (python files
for example) which will be installed unconditionally every time.

Process 2 is not triggered through the install step but as a regular
build target. Under the hood, the build step will add a POST_BUILD
step attached to the target that will invoke "cmake -P
${CMAKE_BINARY_DIR}/cmake_install.cmake -DCOMPONENT=${component}"
Pros : more "chirurgical", only install what's required
Cons : - if an application depends on several components, we need to
describe this in cmake (dependencies are described twice : once for
the build, once for the install)
   - need to maintain an extra "non standard" layer (albeit a small layer)

At this point, I'd like to ask if you see simple steps we could take
to stay as simple and standard as possible without paying the cons
(lenghty install step, double description of dependencies, extra layer
to maintain).

I have a proposal of my own, I'm just not sure this is technically
feasible. I will definitively run a POC sometime, but I thought I
would run it by you first to get your advice/experience.

So maybe the problem is we have one monolithic CMake system where all
apps are described.
What if every single application had its own independent CMake system
(while still being able to depend on common libs, that needs to be
built only once) ?
One app would describe its dependencies, the install step would then
stay simple, and only the reachable install directives would be
triggered in a per-app build.

Is it something which is feasible ? How would you implement it ? (I
thought about ExternalProject_Add but have no experience with it and
I'm not sure it would work in that case ?)

Also, we would still need to be able to build all applications in one
single command.
Do you think creating a "meta" cmake, equivalent to what we have right
now, but on top of those independent, per-app cmake, is feasible ?
(Again, I guess using ExternalProject_Add) ?

Thanks very much for your help

David
-- 

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] cmake -gsplit-dwarf dwp and install step

2018-12-28 Thread David Blaikie

Hi there - I'm not a CMake person, but a Clang/LLVM developer who helped in
the implementation of Split DWARF in Clang/LLVM, so I know a bit about DWOs
and DWPs, etc & thought I'd offer a few extra details...

On Fri, Dec 21, 2018 at 3:39 AM David Jobet 
wrote:

> Hello,
>
> in order to speed up our link step, I wanted to experiment with split
> dwarf.
> See http://www.productive-cpp.com/improving-cpp-builds-with-split-dwarf/
>
> Adding the compilation flag is easy, but I'm stumbling on the installation
> step.
> In our current mode, we redirect the STRIP step to extract the symbols
> and strip the binary.
>

When you say "symbols" - do you mean only debug info? Or other things (like
the ELF symbol table (.symtab section) - since they're no longer needed if
no one's calling into the binary (I guess maybe a symbol table that
contains the entry point - 'main' would be needed? - this is the part of
ELF I don't understand too well))

> With split dwarf, I want to use 'dwp' to collect all .dwo files and
> assemble a symbol file. No need to strip I guess since symbols are
> already put elsewhere.
>

Actually there's probably still a desire to strip the executable - Split
DWARF leaves some debug info in the .o/executable (& at least the GNU
extension form of Split DWARF available in DWARFv4 leaves quiet a bit in
the .o/executable, especially in an optimized build, unfortunately) that
you can benefit from stripping out - along with the non-debug-related
symbol table, if that's a thing you're stripping (see above).

> So I figure I would just use dwp as the strip command in my custom
> strip command.
>
> Problem is .dwo files are recorded in the .o files relative to the
> build directory and the strip command is executed on the installed
> directory.
>

I think this depends on your build system - and might be resolvable
relative to the comp_dir in the debug info remaining in the .o file? Though
I haven't looked/checked closely (but yeah, moving debug info around when
using Split DWARF is a bit tricky)

> As a result, 'dwp' complains it cannot find the .dwo files.
>
> I don't want to add a POST_BUILD step on each our binaries (we have
> lots of binaries), and anyway I'd rather prefer to have the 'dwp' step
> executed at install time so it's executed only when we want to
> deliver.
>
> Is there a way to either
> - pass the build_dir to the strip command ?
> - define a custom step of the install process that would execute on
> the build dir previous to the install step itself ? (for the same
> reason I don't want to manually define a POST_BUILD step on each
> binaries, I don't want to manually define a custom INSTALL step that
> would precede the INSTALL step of all our binaries)
> - or another option ?
>
> With regards
>
> David
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] cmake -gsplit-dwarf dwp and install step

2018-12-21 Thread David Jobet

Hello,

in order to speed up our link step, I wanted to experiment with split dwarf.
See http://www.productive-cpp.com/improving-cpp-builds-with-split-dwarf/

Adding the compilation flag is easy, but I'm stumbling on the installation step.
In our current mode, we redirect the STRIP step to extract the symbols
and strip the binary.

With split dwarf, I want to use 'dwp' to collect all .dwo files and
assemble a symbol file. No need to strip I guess since symbols are
already put elsewhere.

So I figure I would just use dwp as the strip command in my custom
strip command.

Problem is .dwo files are recorded in the .o files relative to the
build directory and the strip command is executed on the installed
directory.
As a result, 'dwp' complains it cannot find the .dwo files.

I don't want to add a POST_BUILD step on each our binaries (we have
lots of binaries), and anyway I'd rather prefer to have the 'dwp' step
executed at install time so it's executed only when we want to
deliver.

Is there a way to either
- pass the build_dir to the strip command ?
- define a custom step of the install process that would execute on
the build dir previous to the install step itself ? (for the same
reason I don't want to manually define a POST_BUILD step on each
binaries, I don't want to manually define a custom INSTALL step that
would precede the INSTALL step of all our binaries)
- or another option ?

With regards

David
-- 

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] dependencies on system include files

2018-12-17 Thread David Blaikie

If you're willing to run a different command or flag when rebuilding after
upgrading system libraries, I would guess the thing to do would be to do a
clean and rebuild, perhaps?

On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans  Hi all
>
>
>
> I’ve just had a problem caused by an upgrade of my system files (in this
> particular case: boost). Rebuilding our software didn’t correctly rebuild
> those files that depend on the updated boost files. (I’m using CMake 3.9
> with make on Ubuntu 16.04)
>
>
>
> Checking a bit more carefully it appears that the system .h files are not
> included in depend.make. I guess this is done to save some time checking
> all those dependencies as system files are supposed to be relatively
> stable, but if they’re not, it creates trouble of course.
>
>
>
> Is there any way to change this behaviour? (ideally something like for one
> time only, check if dependent system include files are more recent then
> what was compiled, but that’s a stretch of course).
>
>
>
> Thanks
>
>
>
> Kris
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to find GTK3 in CMake

2018-11-21 Thread David Demelier


Le 21/11/2018 à 10:19, Jan Wielemaker a écrit :

Good. I was already considering providing a cmake file after migrating
SWI-Prolog to cmake. Are there good guidelines for this? Pkg-config asks
for providing a .pc file and installing in a well-known place. Is there
a similar place for project cmake `find' files or some other convention
to make them available to users?


Yes, it requires a little bit of boilerplate as CMake is a bit more 
extensive than pkg-config.


https://cmake.org/cmake/help/v3.12/manual/cmake-packages.7.html#creating-packages

Note: lot of things are optional, this guide shows everything you can do 
with provided package.


But the minimal required is:

1. install(TARGETS yourlibrary EXPORT yourlibrary-targets)
2. install(EXPORT yourlibrary-targets FILE yourlibrary-targets.cmake 
NAMESPACE yourlibrary DESTINATION lib/cmake/yourlibrary)

3. install(FILES yourlibrary-config.cmake DESTINATION lib/cmake/yourlibrary)

And create yourlibrary-config.cmake with

include("${CMAKE_CURRENT_LIST_DIR}/yourlibrary-targets.cmake")

Regards

--
David
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to find GTK3 in CMake

2018-11-21 Thread David Demelier


Le 20/11/2018 à 17:03, Harry Mallon a écrit :

Hi,

FindGTK and FindGTK2 exist in the CMake tree. How come there isn't one for 
GTK3? Should the GTK2 one work, or is there another way?


GNOME people don't like CMake (they use meson). The philosophy behind 
CMake is to let upstream projects provides their own CMake configuration 
packages rather than providing Find modules for every single library 
existing in the world.


CMake should already not provide any of these, but this general 
recommendation came after.


It's the same thing for pkg-config, pkg-config by itself does not 
provide any .pc file.


Also, Gtk is much more tied to Linux than being portable. I think that's 
why portable software don't use Gtk that much and thus, not CMake either.


Regards,

--
David
--

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

[CMake] Regarding creation of APK through CMake (CMakeAPK idea)

2018-10-23 Thread David Demelier

Hello,

I'm currently experimenting Android development with CMake without using
gradle, Android Studio, ant or anything else.

The idea is to use Android's sdk-tools only (aapt, dx, zipalign, apksigner).

The process isn't that hard but consists of several steps. The only real
question is how should an hypothetical CPackAPK would build the
application because the user has to write some java code and
AndroidManifest file.

In a nutshell the process of building an apk consist of:

1. aapt package -f -m -J -M AndroidManifest.xml -S -I
android.jar

2. javac *.java and output to obj
3. dx --dex --output=classes.dex obj
4. aapt package -f -m -F app.unaligned.apk -M AndroidManifest.xml -S
-I android.jar

5. apksigner sign --ks debug.keystore --ks-pass "blabla"
6. zipalign -f 4 app.unaligned.apk app.apk

So basically, the 1, 3, 4, 5, 6 steps are quite “easy” to implement in a
CPackAPK module but I need to dig how the step 2 should be handled by
that module. Also, we need to incorporate all .so required into the
output directory as well (this could be done with a simple variable I
think).

Any opinions are welcome,

Some sources which helped me:

https://medium.com/@authmane512/how-to-do-android-development-faster-without-gradle-9046b8c1cf68
https://stackoverflow.com/questions/41132753/how-can-i-build-an-android-apk-without-gradle-on-the-command-line

Regards

--
David
--

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] Pre-install targets?

2018-10-17 Thread David Thompson

Hi all,

After some hallway conversation, here is a follow-up:

The consensus was that there were 2 options for the documentation target:

+ Leave documentation out of the install step when documentation is not built 
as part of the ALL target.
+ Change the configuration option for documentation from a boolean to a 
tri-state enum, i.e.,

set(${PROJECT}_BUILD_DOCUMENTATION "never" CACHE STRING "When to build 
documentation.")
set_property(CACHE ${PROJECT}_BUILD_DOCUMENTATION PROPERTY STRINGS never 
manual always)

 so that automated builds for continuous integration can function (using 
"always" or "never")
 while developers can enable documentation but not be forced to refresh it 
every time they
 modify source code (using "manual").

For the latter, a recent change[1] to CMake has made the execution of 
install-rules consistently ordered when processing subdirectories, so it is 
possible to make the INSTALL target build documentation as needed with 
something like:

   if (${PROJECT}_BUILD_DOCUMENTATION STREQUAL "manual")
 install(CODE "execute_process(COMMAND \"${CMAKE_COMMAND}\" cmake --build 
\"${CMAKE_BINARY_DIR}\" --target docs --config $)")
   endif()

so long as care is taken within each directory's CMakeLists.txt to place the 
above before any install() directives related to the generated documentation.

David

[1]: https://gitlab.kitware.com/cmake/cmake/merge_requests/2434

> On Oct 11, 2018, at 09:09, David Thompson  wrote:
> 
> Hi all,
> 
> Is there a way to force a custom target (i.e., ADD_CUSTOM_TARGET) to be built 
> just before installation?
> 
> We have documentation added as a custom target that is **not** passed the 
> "ALL" keyword because generating the documentation is slow. However, that 
> target creates files that have a matching INSTALL, so "make install" or 
> "ninja install" will fail unless the target is built before installation. We 
> want to encourage developers to configure with documentation turned on, but 
> want buildbot/dashboard builds to work without magic options or special 
> configuration.
> 
> Along those lines:
> 
> 1. Is there any ordering of INSTALL(CODE ...) relative to INSTALL(FILES ...)? 
> If it is guaranteed to run first, we could force the target to build that way.
> 
> 2. Is there really nothing to replace the deprecated PRE_INSTALL_SCRIPT 
> property?
> 
>   Thanks,
>   David

-- 

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] Error using sudo ./bootstrap && make && make install

2018-10-17 Thread David Demelier



Le 16/10/2018 à 23:04, Frank Tocci a écrit :

Hello,

I am trying to install Cmake and I am running into an error when I 
enter the install directory and run

sudo ./bootstrap && make && make install
as specified in the README file


Hello,

You're not supposed to do sudo bootstrap. You should always build as 
your user. Only make install has to be run as root.


So do the following:

./boostrap

make

sudo make install

I'll update the README.

regards


--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Controlling order of includes with INTERFACE_INCLUDE_DIRECTORIES for an IMPORTED target

2018-10-12 Thread David Jobet

> what version of CMake are you using?
I'm using cmake version 3.10.0.

> Which seems at odds with your observations/comments, unless I'm 
> misunderstanding what you're saying.
Well, what's for sure is that the above invocation does not compile,
but if at our root CMakeLists.txt we add
include_directories(/apps/homefs1/USER/work/.../libllvm/icc/include)

so that the invocation is now :

g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
/apps/homefs1/USER/work/.../libllvm/icc/include -isystem
/spare/local/USER/conda_root/envs/gcc6cxx14/include ...

it compiles fine.

Actually, what's odd is that the path that's being added by
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)

does not materialize with
-I/apps/homefs1/USER/work/.../libllvm/icc/include
but with
-isystem/apps/homefs1/USER/work/.../libllvm/icc/include

So if -isystem are searched last, then if there's a way to tweak
INTERFACE_INCLUDE_DIRECTORIES to use -I instead of -isystem that would
also work.

David

On Fri, Oct 12, 2018 at 9:02 AM Craig Scott  wrote:
>
>
>
> On Fri, Oct 12, 2018 at 6:42 PM David Jobet  wrote:
>>
>> Hello,
>>
>> we embed in our source a copy of an ICC build of LLVM, that we import :
>>
>> add_library(global_llvm_external STATIC IMPORTED)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMCore.a)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> INTERFACE_LINK_LIBRARIES
>> ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMLTO.a ...)
>>
>> add_library(global_llvm INTERFACE)
>> target_link_libraries(global_llvm INTERFACE global_llvm_external)
>> add_library(global::llvm ALIAS global_llvm)
>>
>> It works fine, until someone decided to install a more recent version
>> of LLVM in its development env. (which is not ABI compatible)
>>
>> Somehow, system includes path are looked into first
>> g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
>> /spare/local/USER/conda_root/envs/gcc6cxx14/include -isystem
>> /apps/homefs1/USER/work/.../libllvm/icc/include ...
>>
>> so, as with include_directories where it's possible to control the
>> ordering with BEFORE or AFTER, is there a way to tell cmake that when
>> linking against global::llvm we want the include directories needed by
>> global::llvm to be prepended (instead of appended) ?
>>
>
> While not directly answering your question, what version of CMake are you 
> using? There was a change related to this area in the following merge request 
> that went in for the 3.12 release:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1968
>
> The part that got my attention is the following claim in the description:
>
>> An effect of the -isystem flag is to search the directory after those 
>> specified via -I flags.
>
>
> Which seems at odds with your observations/comments, unless I'm 
> misunderstanding what you're saying.
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
-- 

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

[CMake] Controlling order of includes with INTERFACE_INCLUDE_DIRECTORIES for an IMPORTED target

2018-10-12 Thread David Jobet

Hello,

we embed in our source a copy of an ICC build of LLVM, that we import :

add_library(global_llvm_external STATIC IMPORTED)
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
set_property(TARGET global_llvm_external APPEND PROPERTY
IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMCore.a)
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_LINK_LIBRARIES
${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMLTO.a ...)

add_library(global_llvm INTERFACE)
target_link_libraries(global_llvm INTERFACE global_llvm_external)
add_library(global::llvm ALIAS global_llvm)

It works fine, until someone decided to install a more recent version
of LLVM in its development env. (which is not ABI compatible)

Somehow, system includes path are looked into first
g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
/spare/local/USER/conda_root/envs/gcc6cxx14/include -isystem
/apps/homefs1/USER/work/.../libllvm/icc/include ...

so, as with include_directories where it's possible to control the
ordering with BEFORE or AFTER, is there a way to tell cmake that when
linking against global::llvm we want the include directories needed by
global::llvm to be prepended (instead of appended) ?

With regards

David
-- 

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

[CMake] Pre-install targets?

2018-10-11 Thread David Thompson

Hi all,

Is there a way to force a custom target (i.e., ADD_CUSTOM_TARGET) to be built 
just before installation?

We have documentation added as a custom target that is **not** passed the "ALL" 
keyword because generating the documentation is slow. However, that target 
creates files that have a matching INSTALL, so "make install" or "ninja 
install" will fail unless the target is built before installation. We want to 
encourage developers to configure with documentation turned on, but want 
buildbot/dashboard builds to work without magic options or special 
configuration.

Along those lines:

1. Is there any ordering of INSTALL(CODE ...) relative to INSTALL(FILES ...)? 
If it is guaranteed to run first, we could force the target to build that way.

2. Is there really nothing to replace the deprecated PRE_INSTALL_SCRIPT 
property?

Thanks,
David
-- 

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] protobuf and imports relative to root (and --proto_path)

2018-10-01 Thread David Jobet

Tx Alexander.

Unfortunately, the version of cmake that we use (2.6.0) does not have a 
--dependency_out arg.
So I just coded a small python parser that recursively check for imports and 
create a ninja depfile out of it. (injected with DEPFILE in custom command)
It looks like it works fine thanks !

David

Le 25 septembre 2018 21:15:54 GMT+01:00, Alexander Neundorf  
a écrit :
>On 2018 M09 25, Tue 16:53:27 CEST David Jobet wrote:
>> > What I do have a problem is rerunning protoc automatically on
>proto-files
>> > which import proto files that have been modified.
>> > How do you handle this ?
>> 
>> I just found out I don't.
>> Any idea on that one ?
>
>here are some suggestions:
>https://cmake.org/pipermail/cmake-developers/2018-May/030664.html
>
>Alex
>
>-- 
>
>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

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.-- 

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] protobuf and imports relative to root (and --proto_path)

2018-09-25 Thread David Jobet

> What I do have a problem is rerunning protoc automatically on proto-files 
> which
> import proto files that have been modified.
> How do you handle this ?

I just found out I don't.
Any idea on that one ?

Otherwise I'm going to create a small .proto parser (python) that will
just list the imports recursively.
I will add that as DEPENDS to the add_custom_command.

David
On Thu, Aug 23, 2018 at 9:36 PM Alexander Neundorf  wrote:
>
> On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote:
> > Hello,
> >
> > I'm trying to port an existing project from premake to cmake.
> > I'm trying to avoid modifying the source files while doing so.
> >
> > Right now, we have several libraries (read in different directories) using
> > proto files with imports between them.
> > All imports are made relative to the root of the project.
> >
> > e.g :
> > work/lib1/sublib1/a.proto
> > work/lib1/sublib1/b.proto
> >
> > with a.proto having a link to b.proto like this "import
> > lib1/sublib1/b.proto"
> >
> > If I compile this with an unchanged FindProtobuf.cmake, I do this :
> >
> > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
> > add_library(...)
> >
> > the problem being that it looks like the "namespaces" generated by protoc
> > in b.proto do not match the one used in a.proto : it does not compile.
>
> do you mean protoc fails, or that the C++ compiler fails when compiling the
> generated file ?
> I'm also using proto files with imports between them and don't have problems
> with finding them.
> Are you setting the PROTOBUF_IMPORT_DIRS variable ?
>
> What I do have a problem is rerunning protoc automatically on proto-files 
> which
> import proto files that have been modified.
> How do you handle this ?
>
> > Is there a way to make this work ?
> >
> > Otherwise, I made the patch below which solves my problem. Do you think it
> > could be included in cmake ?
> > it defines a new option PROTO_PATH, so the decl above becomes
> > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR}
> > a.proto b.proto)
> >
> > With regards
> >
> > David
> >
> > $ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig
> > share/cmake-3.10/Modules/FindProtobuf.cmake
>
> can you please use diff -bup ?
> This makes the patch easier to read.
>
> Thanks
> Alex
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Best way to combine generated static libraries into a single static library

2018-09-21 Thread David Jobet

Hello,

glad that could help you.
For your newer problem, you don't describe them, so it's tough to know
what kind of problems you're facing.
Maybe a small example of your CMakeLists.txt + a capture of the error
cmake gives you could help ?

David
On Fri, Sep 21, 2018 at 4:52 PM Ke Gao  wrote:
>
> Thank you all for the help.
>
> I finally use a way quite similar to David's first approach. I first generate 
> all sub-projects into object libraries using add_library(lib1 OBJECT 
> SOURCES). Then in the final library, I use add_library(single_static_lib 
> STATIC SOURCES) and target_link_libraries( single_static_lib lib1 lib2 ...). 
> Note that I didn't use " $" in the final "add_library" 
> and also didn't use "PUBLIC" keyword in the final "target_link_libraries". It 
> works on CMake v3.12.2 and gives me a single static lib which combines all 
> the objs I want.
>
> But currently I still have problems of further combining third party static 
> libraries into the final generated static single_static_lib. Can anybody 
> provide a solution for this?
>
> Thank you very much.
>
> Ke
>
> On Fri, Sep 21, 2018 at 6:15 AM Deniz Bahadir  wrote:
>>
>> Am 21.09.2018 um 09:33 schrieb David Jobet:
>> > Hello,
>> >
>> > I had a similar issue lately and wanted to "pack" several static libs
>> > into a dynamic one. (Not even talking about an INTERFACE lib since I
>> > really wanted that .so)
>> > I made it work with 3 different solutions, none of them being "clean"
>> > from my point of view.
>> >
>> > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT SOURCES) and
>> > for the single static lib : add_library(single_static_lib STATIC
>> > $ ...)
>> > Problem I faced : since OBJECT libs do not support
>> > target_link_libraries(), I had to remove the existing one and move
>> > them instead to the target_include_directories() using generators.
>>
>> This is no longer true. Since CMake 3.12 `target_link_libraries` fully
>> supports OBJECT libraries. You just need to pay attention to the special
>> case of linking an OBJECT library with keyword "PUBLIC". (Object-files
>> are always private and inherited object-files are therefore never
>> further inherited. See:
>> https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries)
>>
>> > e.g : target_include_directories(lib1 PUBLIC
>> > $)
>> > Because I had a dependency to a protobuf generated lib, I also had to
>> > add manual add_dependencies to respect proper build order.
>> > Not clean at all
>> >
>> > 2- add_library(mysharedlib STATIC CMakeLists.txt)
>> > target_linked_libraries(mysharedlib PUBLIC lib1 ...)
>> > Maybe the cleanest way I found.
>> > The trick with CMakeLists.txt is that add_library needs at least one
>> > source file. You can put any kind of files you want. CMakeLists.txt is
>> > not compilable, so no extra compilation step, no need for dummy empty
>> > source file and add_library is happy.
>> > It did not work in my case because of problems related to how our .so
>> > are used/generated. (problems at runtime with duplicated symbols in
>> > protobufs)
>> >
>> > 3- a variation around 1
>> > instead of defining OBJECT libs, define a variable holding all the
>> > sources for lib1, another for lib2, ...
>> > then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1}
>> > ${SOURCES_FOR_lib2})
>> > It works a little bit like 1) but does not have any of its problems
>> > (target_link, add_dependencies, generators, ...)
>> > It has new problems of its own though : if your libs live in different
>> > subfolders, the variables might not be visible from your
>> > add_library(mysharedlib...) call.
>> > To work around that, you can use PARENT_SCOPE (not sure if that works
>> > accross several levels), or includes (defines those variables into
>> > separate files living in each subfolders and include them in the
>> > parent CMakeLists).
>> >
>> > Hope this helps (and I'd be happy to know of other ways)
>> >
>> > David
>> > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have a project which includes many sub-projects. Each sub-project 
>> >> generates a static library. In the main project, I want to combine the 
>> >> generated objs, generated static libraries fr

Re: [CMake] Best way to combine generated static libraries into a single static library

2018-09-21 Thread David Jobet

Hello,

I had a similar issue lately and wanted to "pack" several static libs
into a dynamic one. (Not even talking about an INTERFACE lib since I
really wanted that .so)
I made it work with 3 different solutions, none of them being "clean"
from my point of view.

1- OBJECT libs on sub projects : add_library(lib1 OBJECT SOURCES) and
for the single static lib : add_library(single_static_lib STATIC
$ ...)
Problem I faced : since OBJECT libs do not support
target_link_libraries(), I had to remove the existing one and move
them instead to the target_include_directories() using generators.
e.g : target_include_directories(lib1 PUBLIC
$)
Because I had a dependency to a protobuf generated lib, I also had to
add manual add_dependencies to respect proper build order.
Not clean at all

2- add_library(mysharedlib STATIC CMakeLists.txt)
target_linked_libraries(mysharedlib PUBLIC lib1 ...)
Maybe the cleanest way I found.
The trick with CMakeLists.txt is that add_library needs at least one
source file. You can put any kind of files you want. CMakeLists.txt is
not compilable, so no extra compilation step, no need for dummy empty
source file and add_library is happy.
It did not work in my case because of problems related to how our .so
are used/generated. (problems at runtime with duplicated symbols in
protobufs)

3- a variation around 1
instead of defining OBJECT libs, define a variable holding all the
sources for lib1, another for lib2, ...
then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1}
${SOURCES_FOR_lib2})
It works a little bit like 1) but does not have any of its problems
(target_link, add_dependencies, generators, ...)
It has new problems of its own though : if your libs live in different
subfolders, the variables might not be visible from your
add_library(mysharedlib...) call.
To work around that, you can use PARENT_SCOPE (not sure if that works
accross several levels), or includes (defines those variables into
separate files living in each subfolders and include them in the
parent CMakeLists).

Hope this helps (and I'd be happy to know of other ways)

David
On Thu, Sep 20, 2018 at 5:45 PM Ke Gao  wrote:
>
> Hi,
>
> I have a project which includes many sub-projects. Each sub-project generates 
> a static library. In the main project, I want to combine the generated objs, 
> generated static libraries from other sub-projects, and some other third 
> party static libraries together into a single static library. Is there an 
> elegant way to do this, or maybe an existing function?
>
> Thank you very much.
>
> --
> ..
> Ke Gao
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] protobuf and imports relative to root (and --proto_path)

2018-08-28 Thread David Jobet

Hello, thanks for your answer.

Here's a mockup :
projectroot/lib1
projectroot/lib1/CMakeLists.txt
projectroot/lib1/a.proto
projectroot/lib1/b.proto
projectroot/lib1/test.cc

See below for the content of the files.

Here's the cmake output :
$ cmake --build build
[0/1] Re-running CMake...
-- Configuring done
-- Generating done
-- Build files have been written to: XXX/temp/build
[1/3] Building CXX object lib1/CMakeFiles/protolib1.dir/a.pb.cc.o
FAILED: lib1/CMakeFiles/protolib1.dir/a.pb.cc.o
XXX/bin/g++   -I. -isystem XXX/include -std=c++14 -Wall   -std=c++14
-MD -MT lib1/CMakeFiles/protolib1.dir/a.pb.cc.o -MF
lib1/CMakeFiles/protolib1.dir/a.pb.cc.o.d -o lib1/CMakeFiles/protoli
b1.dir/a.pb.cc.o -c lib1/a.pb.cc
lib1/a.pb.cc: In function 'void protobuf_AddDesc_a_2eproto()':
lib1/a.pb.cc:79:3: error: '::protobuf_AddDesc_lib1_2fb_2eproto' has
not been declared
  ::protobuf_AddDesc_lib1_2fb_2eproto();
  ^~
ninja: build stopped: subcommand failed.

Here's what's generated from b.proto :
$ cat build/lib1/b.pb.h | grep AddDesc
void  protobuf_AddDesc_b_2eproto();
 friend void  protobuf_AddDesc_b_2eproto();


If I remove the PROTOBUF_IMPORT_DIRS and add "PROTO_PATH
${CMAKE_SOURCE_DIR}" on protobuf_generate_cpp to use my patch (this
injects --proto_path on protoc command line), everything works.
e.g :
#set(PROTOBUF_IMPORT_DIRS ${CMAKE_SOURCE_DIR})
protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH
${CMAKE_SOURCE_DIR} a.proto b.proto)

And indeed, the namespace is now correct :
$ cat build/lib1/b.pb.h | grep AddDesc
void  protobuf_AddDesc_lib1_2fb_2eproto();
 friend void  protobuf_AddDesc_lib1_2fb_2eproto();

Again, does anyone know how to make this works without the patch ?
If not, how do someone proposes a patch on cmake ? (posting to the
developper mailing list ?)

David


File contents

-

$ cat lib1/CMakeLists.txt
project(lib1 LANGUAGES CXX C)

find_package(Protobuf REQUIRED)

set(PROTOBUF_IMPORT_DIRS ${CMAKE_SOURCE_DIR})
protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
add_library(protolib1 STATIC ${PROTO_SRCS} ${PROTO_HRDS})
target_include_directories(protolib1 PUBLIC ${CMAKE_BINARY_DIR})
target_link_libraries(protolib1 PUBLIC protobuf::libprotobuf)

add_library(lib1 test.cc)
target_include_directories(lib1 PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_link_libraries(lib1 PRIVATE protolib1)

-

$ cat lib1/a.proto
import "lib1/b.proto";

message A
{
 optional string toto = 1;
 optional BType  type = 2;
}

-

$ cat lib1/b.proto
message BType
{
   optional double d = 1;
}

-

$ cat lib1/test.cc
// Protocol buffer
#include 
#include "lib1/a.pb.h"
On Thu, Aug 23, 2018 at 9:36 PM Alexander Neundorf  wrote:
>
> On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote:
> > Hello,
> >
> > I'm trying to port an existing project from premake to cmake.
> > I'm trying to avoid modifying the source files while doing so.
> >
> > Right now, we have several libraries (read in different directories) using
> > proto files with imports between them.
> > All imports are made relative to the root of the project.
> >
> > e.g :
> > work/lib1/sublib1/a.proto
> > work/lib1/sublib1/b.proto
> >
> > with a.proto having a link to b.proto like this "import
> > lib1/sublib1/b.proto"
> >
> > If I compile this with an unchanged FindProtobuf.cmake, I do this :
> >
> > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
> > add_library(...)
> >
> > the problem being that it looks like the "namespaces" generated by protoc
> > in b.proto do not match the one used in a.proto : it does not compile.
>
> do you mean protoc fails, or that the C++ compiler fails when compiling the
> generated file ?
> I'm also using proto files with imports between them and don't have problems
> with finding them.
> Are you setting the PROTOBUF_IMPORT_DIRS variable ?
>
> What I do have a problem is rerunning protoc automatically on proto-files 
> which
> import proto files that have been modified.
> How do you handle this ?
>
> > Is there a way to make this work ?
> >
> > Otherwise, I made the patch below which solves my problem. Do you think it
> > could be included in cmake ?
> > it defines a new option PROTO_PATH, so the decl above becomes
> > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR}
> > a.proto b.proto)
> >
> > With regards
> >
> > David
> >
> > $ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig
> > share/cmake-3.10/Modules/FindProtobuf.cmake
>
> can you please use diff -bup ?
> This makes the patch easier to read.
>
> Thanks
> Alex
>
> --
>
> Powered by www.kitware.com
>
> Please keep messag

[CMake] protobuf and imports relative to root (and --proto_path)

2018-08-23 Thread David Jobet

Hello,

I'm trying to port an existing project from premake to cmake.
I'm trying to avoid modifying the source files while doing so.

Right now, we have several libraries (read in different directories) using
proto files with imports between them.
All imports are made relative to the root of the project.

e.g :
work/lib1/sublib1/a.proto
work/lib1/sublib1/b.proto

with a.proto having a link to b.proto like this "import
lib1/sublib1/b.proto"

If I compile this with an unchanged FindProtobuf.cmake, I do this :

protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
add_library(...)

the problem being that it looks like the "namespaces" generated by protoc
in b.proto do not match the one used in a.proto : it does not compile.

Is there a way to make this work ?

Otherwise, I made the patch below which solves my problem. Do you think it
could be included in cmake ?
it defines a new option PROTO_PATH, so the decl above becomes
protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR}
a.proto b.proto)

With regards

David

$ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig
share/cmake-3.10/Modules/FindProtobuf.cmake
123c123
<   cmake_parse_arguments(protobuf "" "EXPORT_MACRO;DESCRIPTORS" "" ${ARGN})
---
>   cmake_parse_arguments(protobuf "" "PROTO_PATH;EXPORT_MACRO;DESCRIPTORS"
"" ${ARGN})
130a131,139
>   set(EXTRA_ARGS "")
>   set(OUT_PATH ${CMAKE_CURRENT_BINARY_DIR})
>   if(protobuf_PROTO_PATH)
> get_filename_component(ABS_PROTO_PATH ${protobuf_PROTO_PATH} ABSOLUTE)
> set(EXTRA_ARGS "--proto_path=${ABS_PROTO_PATH}")
> file(RELATIVE_PATH PROTO_REL_PATH ${CMAKE_SOURCE_DIR}
${ABS_PROTO_PATH})
> set(OUT_PATH ${CMAKE_BINARY_DIR}/${PROTO_REL_PATH})
>   endif()
>
198c207,208
<"--cpp_out=${DLL_EXPORT_DECL}${CMAKE_CURRENT_BINARY_DIR}"
---
>${EXTRA_ARGS}
>"--cpp_out=${DLL_EXPORT_DECL}${OUT_PATH}"
-- 

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

[CMake] (no subject)

2018-06-24 Thread David Henderson via CMake


http://practice.deloresmontez.com
David Henderson

-- 

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

[CMake] (no subject)

2018-05-31 Thread David Henderson via CMake

http://moreover.singlepotatoes.com
David Henderson




-- 

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

[CMake] Unresolved symbol VerifyFortran with clang C compiler and xlf_r Fortran compiler

2018-05-24 Thread David Wootton



I'm trying to build the lapack library I obtained from
http://www.netlib.org/lapack/lapack-3.8.0.tar.gz.  using the clang C
compiler and the xlf Fortran compiler with cmake 3.11. I'm using a Power 9
Linux system running Red Hat 7

The default behavior for the xlf compiler is to mangle Fortran so the
external symbol name is folded to all lower case with no trailing '_', In
this case, VerifyFortran should be mangled tp verifyfortran.

When I attempt to build it, my build system issues these error messages
 99 CMakeFiles/VerifyFortranC.dir/main.c.o: In function `main':
  >>
100/nfshome/drw/spack/spack/opt/spack/linux-rhel7-ppc64le/gcc-4.8.5/cm

ake-3.11.1-rcn6qgw6pldsuuk2gkijnn4dalajl4wr/share/cmake-3.11/Module
s/FortranCInterface/Verify/main.c:(.text+0x24): undefined
reference
 to `VerifyFortran'
  >> 101clang-3.8: error: linker command failed with exit code 1
(use -
v to see invocation)
  >> 102gmake[3]: *** [VerifyFortranC] Error 1
 103gmake[3]: Leaving directory
`/tmp/drw/spack-staging/spack-stage

/spack-stage-h3S7X1/lapack-3.8.0/spack-build-static/CMakeFiles/Fort
ranCInterface/VerifyC'

where cmake is attempting to verify Fortran/C compatibility for this pair
of compilers.

I tried to track this down by extracting this tar file in a scratch
directory. The build process requires cmake to be invoked in a separate
drectory from the source code so I created a 'build' directory in the
parent directory where my lapack-3.8.0 source resided, cd to that directory
and ran the command 'cmake ../lapack-3.8.0 -DCBLAS=ON' I get these messages
cd /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC
&& /nfshome/drw/cmake/bin/cmake -E cmake_depends "Unix
Makefiles" /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify 
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify 
/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC 
/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC 
/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortranC.dir/DependInfo.cmake
Scanning dependencies of target VerifyFortranC
gmake[3]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
/bin/gmake -f CMakeFiles/VerifyFortranC.dir/build.make
CMakeFiles/VerifyFortranC.dir/build
gmake[3]: Entering directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
[ 60%] Building C object CMakeFiles/VerifyFortranC.dir/main.c.o
/opt/clang-coral/bin/clang
-I/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC  -O3
-DNDEBUG   -o CMakeFiles/VerifyFortranC.dir/main.c.o
-c /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/main.c
[ 80%] Building C object CMakeFiles/VerifyFortranC.dir/VerifyC.c.o
/opt/clang-coral/bin/clang
-I/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC  -O3
-DNDEBUG   -o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o
-c 
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/VerifyC.c
[100%] Linking C executable VerifyFortranC
/nfshome/drw/cmake/bin/cmake -E cmake_link_script
CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1
/opt/clang-coral/bin/clang -O3 -DNDEBUG
CMakeFiles/VerifyFortranC.dir/main.c.o
CMakeFiles/VerifyFortranC.dir/VerifyC.c.o  -o VerifyFortranC
-L/opt/ibm/xlsmp/5.1.0/lib  -L/opt/ibm/xlmass/9.1.0/lib
-L/opt/ibm/xlf/16.1.0/lib libVerifyFortran.a -lxlf90_r -lxlopt -lxlomp_ser
-lxl -lxlfmath -ldl -lrt -lpthread -lm
CMakeFiles/VerifyFortranC.dir/main.c.o: In function `main':

/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/main.c:(.text
+0x24): undefined reference to `VerifyFortran'
clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)
gmake[3]: *** [VerifyFortranC] Error 1
gmake[3]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
gmake[2]: *** [CMakeFiles/VerifyFortranC.dir/all] Error 2
gmake[2]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
gmake[1]: *** [CMakeFiles/VerifyFortranC.dir/rule] Error 2
gmake[1]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
gmake: *** [VerifyFortranC] Error 2

I tried to figure out what's happening by running cmake with the
--trace-expand flag.

When I backtrack thru the log, I see these error messages related to
VerifyFortranC.

/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(24):  unset(FortranCInterface_VERIFIED_C CACHE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(25):  unset(FortranCInterface_VERIFIED_CXX CACHE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(27):  set(_result )
/nfshome/drw/cmake/share/cmake-3.11/Modules/

Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream

2018-05-23 Thread David Demelier

On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
> Hi,
> 
> I've been recently trying to update/add Find-modules to CMake:
> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
> 
> Discussion during review of the FindLZ4 [1] ended with some
> surprising
> conclusions which I, as someone who relies on CMake and occacionally
> contributes to CMake, don't necessarily agree with.
> I'd like to share some of my thoughts.
> 
> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4
> 12640
> 
> A bit of a extract from the brief discussion [1]:
> 
> The FindLZ4 discussion basically ended with suggestion from Brad
> that,
> instead of adding Find-module to CMake, I should approach LZ4 project
> and add Config-file to the library itself.

Yes, that's the way to go. It's not the CMake role to add find module
for every single library that exist on earth.

Packages configuration file are not that hard to write and Find
packages are not necessarily easier to write too. You need to create
imported target, check versions, check components and such. All of this
is managed by configuration files automatically when using appropriate
install+export features.

> I understand CMake maintainers try to shift the responsibility of
> recognising
> "every project in the world" away from the CMake itself as not
> scalable.

If you look at pkg-config from Linux world, when you install pkg-config 
you just have the tool that inspects .pc files, it does not come with
all libraries implemented in the world. That exactly what should happen
with CMake too.

> Good approach to avoid need to scale up the maintenance efforts,
> but that is a bad news for CMake users.
> 
> As a CMake user, I expect to be able to install CMake and get my
> dependencies
> recognised by CMake as CMake's responsibility
> I do not want to care if library A which I depend on is actually
> CMake-ignorant or not.
> I do not want to learn why library A does not support CMake, as often
> that is
> philosopical reason and asking about it ends up with a rough
> responses.
> (Imagine, there are libraries on GitHub which maintainers do not
> accept
> addition of ***non-intrusive*** single .travis.yml file, because they
> don't trust it.)
> If a library is strictly GNU Autoconf, I'm on lost position trying to
> convince
> maitnainers to accept CMake stuff and even if they do, they won't be
> willing to
> maintain it - broken Config-files may be deployed with new packages.
> That puts users of CMake and such library on lost position:
> CMake says no to Find-module, the library does not care either.
> 
> As CMake user I don't want to be left to the discretion of package
> maintainers.
> Packages may ignore CMake Config-file existence.

Try to convince them to incorporate a patch, or if they won't I usually
keep a custom FindModule in my own repo and reuse it if required.

> Packages of libraries which provide CMake and alternative build
> configurations
> may not deploy Config-files or Find-modules.
> 
> IMHO, CMake should encourage contributions of new Find-modules.

No.

What if CMake 3.12 has a FindFooBar module shipped in your package
manager. But upstream decided to break everything? Change component
name, change library name? We won't have time to inspect all find
modules and update them *because* upstream decided to change.

> I want to contribute Find-module into a **central place** where I can
> easily
> access it as well as monitor its state and submit fixes if necessary.
> From a contributor POV, that is much more effective than jumping
> between
> variety of issue trackers, creating new accounts for one time use or
> even
> sending patches via e-mails to maitnainers - not everything lives in
> GitHub yet.
> 
> Since CMake is still de-facto a standard for building C++ software,
> from end-user POV the current situation feels almost like vendor
> lock-in.
> 
> I call CMake to accept *any* Find-module, filtering only based on
> quality of CMake
> idiomatic scripting.
> 
> If CMake does not want Find-* modules within the source tree, then
> - set up https://gitlab.kitware.com/cmake/find-modules
> - move all existing Find-modules in there
> - relax maintenance rules to accept *any* Find-module, provided
> --- CMake scripting is decent quality (e.g no community downvotes or
> rejecting
>  reviews for period of quarantine)
> --- CI passing tests
> - finally, include the complete find-modules archive in the installer
> so it is deployed
>aside of CMake itself

This sounds like more of a reasonable proposal. CMake should by itself
not propose any Find* package anymore. A user-managed repository where
everyone

Re: [CMake] Experiments in CMake support for Clang (header & standard) modules

2018-05-06 Thread David Blaikie

On Mon, Apr 30, 2018 at 3:30 PM Stephen Kelly  wrote:

> On 04/20/2018 01:39 AM, David Blaikie wrote:
>
> Hi there,
>
> I'm experimenting with creating examples (& potential changes to CMake
> itself, if needed/useful) of building clang modules (currently using the
> semi-backwards compatible "header modules", with the intent of also/moving
> towards supporting pre-standard C++ modules in development in Clang).
>
>
> Great! Thanks for reaching out. Sorry it has taken me a while to respond.
>

No worries - thanks for getting back to me!


> Have you had other response off-list?
>

Nah - chatted a little with coworkers (fellow Clang/LLVM developers -
mostly Richard Smith & Chandler Carruth) off-list, but nothing much more.

> The basic commands required are:
>
>   clang++ -fmodules -xc++ -Xclang -emit-module -Xclang -fmodules-codegen
> -fmodule-name=foo foo.modulemap -o foo.pcm
>   clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp
>   clang++ -c foo.pcm
>   clang++ foo.o use.o -o a.out
>
>
> Ok. Fundamentally, I am suspicious of having to have a
> -fmodule-file=foo.pcm for every 'import foo' in each cpp file. I shouldn't
> have to manually add that each time I add a new import to my cpp file. Even
> if it can be automated (eg by CMake), I shouldn't have to have my
> buildsystem be regenerated each time I add an import to my cpp file either.
>
> That's something I mentioned in the google groups post I made which you
> linked to. How will that work when using Qt or any other library?
>

- My understanding/feeling is that this would be similar to how a user has
to change their link command when they pick up a new dependency.

Nope, scratch that ^ I had thought that was the case, but talking more with
Richard Smith it seems there's an expectation that modules will be
somewhere between header and library granularity (obviously some small
libraries today have one or only a few headers, some (like Qt) have many -
maybe those on the Qt end might have slightly fewer modules than the have
headers - but still several modules to one library most likely, by the
sounds of it)


Now, admittedly, external dependencies are a little more complicated than
internal (within a single project consisting of multiple libraries) - which
is why I'd like to focus a bit on the simpler internal case first.


> Today, a beginner can find a random C++ book, type in a code example from
> chapter one and put `g++ -I/opt/book_examples prog1.cpp` into a terminal
> and get something compiling and running. With modules, they'll potentially
> have to pass a whole list of module files too.
>

Yeah, there's some talk of supporting a mode that doesn't explicitly
build/use modules in the filesystem, but only in memory for the purpose of
preserving the isolation semantics of modules. This would be used in simple
direct-compilation cases like this. Such a library might need a
configuration file or similar the compiler can parse to discover the
parameters (warning flags, define flags, whatever else) needed to build the
BMI.


> Lots of people manually maintain Makefile-based buildsystems today, and
> most other companies I've been inside of have their own custom tool or
> bunch of python scripts, or both. Manually changing such buildsystems to
> add -fmodule-file or -fmodule-map-file each time an import is added is a
> significant barrier.
>
> Will my project have to compile the modules files for all of my
> dependencies?
>

Yes - and that's where the external dependencies get complicated.


> Even more complication for my buildsystem. Do I have to wait for my
> dependencies to modularize bottom-up before I can benefit from modules?
>

There are some ideas about how to handle that ('legacy headers'/modules in
Richard's work/proposed amendment to the TS), but I'm trying to focus on a
few of the simpler cases first.


> If my dependency does add 'module foo' to their header files, or whatever
> the current syntax is, can I continue to #include  or is that a source
> incompatible change?
>

I believe it'd be a source incompatible change. You could continue to
provide a header for your module separately. They'd likely have different
extensions anyway.


> I raised some of these issues a few years ago regarding the clang
> implementation with files named exactly module.modulemap:
>
>
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html
>
>
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html
>
> Interestingly, GCC is taking a directory-centric approach in the driver
> (-fmodule-path=) as opposed to the 'add a file to your compile line
> for ea

[CMake] Experiments in CMake support for Clang (header & standard) modules

2018-04-19 Thread David Blaikie

Hi there,

I'm experimenting with creating examples (& potential changes to CMake
itself, if needed/useful) of building clang modules (currently using the
semi-backwards compatible "header modules", with the intent of also/moving
towards supporting pre-standard C++ modules in development in Clang).

The basic commands required are:

  clang++ -fmodules -xc++ -Xclang -emit-module -Xclang -fmodules-codegen
-fmodule-name=foo foo.modulemap -o foo.pcm
  clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp
  clang++ -c foo.pcm
  clang++ foo.o use.o -o a.out

My current very simplistic prototype, to build a module file, its
respective module object file, and include those in the library/link for
anything that depends on this library:

  add_custom_command(
  COMMAND ${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -xc++ -c -Xclang
-emit-module -fmodules -fmodule-name=Hello
${CMAKE_CURRENT_SOURCE_DIR}/module.modulemap -o
${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm -Xclang -fmodules-codegen
  DEPENDS module.modulemap hello.h
  OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm
  COMMENT "Generating hello_module.pcm"
  )
  add_library (Hello hello.cxx ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)
  target_include_directories(Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
  target_compile_options(Hello PUBLIC -fmodules -Xclang
-fmodule-file=${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)

(this is based on the example in the CMake docs using Hello/Demo)

This also required one modification to CMake itself to classify a pcm file
as a C++ file that needs to be compiled (to execute the 3rd line in the
basic command list shown above).

But this isn't ideal - I don't /think/ I've got the dependencies quite
right & things might not be rebuilding at the right times.
Also it involves hardcoding a bunch of things like the pcm file names,
header files, etc.

Ideally, at least for a simplistic build, I wouldn't mind generating a
modulemap from all the .h files (& have those headers listed in the
add_library command - perhaps splitting public and private headers in some
way, only including the public headers in the module file, likely).
Eventually for the standards-proposal version, it's expected that there
won't be any modulemap file, but maybe all headers are included in the
module compilation (just pass the headers directly to the compiler).

This also doesn't start to approach the issue of how to build modules for
external libraries - which I'm happy to discuss/prototype too, though
interested in working to streamline the inter-library but intra-project
(not inter-project) case first.

Stephen - I saw you were asking some questions about this here (
https://groups.google.com/a/isocpp.org/forum/#!topic/modules/sDIYoU8Uljw &
https://github.com/steveire/ModulesExperiments - didn't really understand
how this example applied/worked, though - I guess maybe it's a prototype
syntax proposal?)

Basically: What do folks think about supporting these sort of features in
CMake C++ Builds? Any pointers on how I might best implement this with or
without changes to CMake?

Thanks a bunch,
- Dave
-- 

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] Recommandations for public custom macro/functions installation

2018-04-17 Thread David Demelier

On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote:
> Just replying to this topic of your message: you may want to
> reconsider. The 
> cmake gui allows you to group options automatically by prefix. This
> de-clutters 
> the options considerably.

I didn't know that! Nice catch. I'll reconsider using prefix then. I've
usually named my options WITH_FOO, do you recommend to use
PROJECT_WITH_FOO or WITH_PROJECT_FOO then?

-- 
David
-- 

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

[CMake] Recommandations for public custom macro/functions installation

2018-04-17 Thread David Demelier

Hello,

In my application I have some custom functions that help the process of
creating executable, libraries, plugins and such.

They don't do magic things but they mostly build, provide installation
to specific place and optionally build the documentation and install
them as well. This happens in my project. Since the project is
extensible, I want to install the libraries **and** those macros so
users will be able to use them so their plugins get installed in the
correct place alongside the documentation without much effort.

Example, the user will just write:

irccd_define_plugin(
SOURCES main.cpp
DOCS myplugin.md
)

The problem with that macro, is that it has a conditional to build the
documentation depending on an option. This is fine in my project since
the user may build or not build the documentation by setting WITH_DOCS
to Off.

Now I wonder how I should handle this option when the macro is
publicliy installed. The most problematic question is that variables do
not have namespaces so if the user of my macro also have an option
WITH_DOCS in its own CMakeLists.txt, this will interfer with the
installed macro.

What are your recommandations over this?

I personally do not want to prefix all my options in my project with
the project name prefix, I think that would be a bit ugly, and I do
want this macro to build and install the documentation.

Any advice/comment is welcome.

Regards,

-- 
David
-- 

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] Can't find Boost with Visual Studio 2017

2018-03-19 Thread David Demelier

On Sat, 2018-03-17 at 23:15 +0100, Volker Enderlein wrote:
> Hi David,
> 
> Boost changed its naming scheme starting from version 1.66. So its
> not 
> your fault but the FindBoost.cmake does not know how to handle the
> new 
> scheme. Try to use one of the 3.11.0-rc[1-3] versions that has the 
> proper naming scheme handling of 1.66 or use the 1.65.1 that is the
> last 
> version with the old naming scheme.
> 

Hello,

Indeed, it works with CMake 3.11, thanks a lot :)

-- 
David
-- 

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

[CMake] Can't find Boost with Visual Studio 2017

2018-03-17 Thread David Demelier


Hello all,

I've built Booost 1.66 on Windows with Visual Studio 2017 using the 
following invocation:


.\b2
link=shared
runtime-link=shared
threading=multi
toolset=msvc
variant=debug
address-model=64
install --prefix=C:/env/vs/amd64d

Then, the C:/env/vs/amd64d tree is filled like this:

  - lib/boost_timer-vc141-mt-gd-x64-1_66.lib (and so on)
  - include/boost-1_66/boost/{asio/assign,...}

I create a sample CMake project:

cmake_minimum_required(VERSION 3.5)
project(foo)
find_package(Boost REQUIRED COMPONENTS timer)

I set CMAKE_PREFIX_PATH and run CMake

set CMAKE_PREFIX_PATH=C:/env/vs/amd64d/
cmake . -G "Visual Studio 15 2017 Win64"

[...]
-- Detecting CXX compile features - done
CMake Warning at C:/Program 
Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:567 (message):
  Imported targets and dependency information not available for Boost 
version

  (all versions older than 1.33)
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:907 
(_Boost_COMPONENT_DEPENDENCIES)
  C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1542 
(_Boost_MISSING_DEPENDENCIES)

  CMakeLists.txt:3 (find_package)


CMake Error at C:/Program 
Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1928 (message):

  Unable to find the requested Boost libraries.

  Unable to find the Boost header files.  Please set BOOST_ROOT to the 
root
  directory containing Boost or BOOST_INCLUDEDIR to the directory 
containing

  Boost's headers.
Call Stack (most recent call first):
  CMakeLists.txt:3 (find_package)


-- Configuring incomplete, errors occurred!
See also "C:/Users/markand/Documents/test/CMakeFiles/CMakeOutput.log".

I can't understand what I am missing because it's not the first time I 
use boost on Windows though. I've tried set BOOST_ROOT to the same value 
as CMAKE_PREFIX_PATH with no results.


--
David Demelier
--

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

[CMake] reminder: free VTK, ParaView and CMake training at Kitware New York in two weeks.

2018-02-27 Thread David E DeMarle

Read all about it in this blog post:
https://blog.kitware.com/events/march2018-free-vtk-paraview-and-cmake-training-courses-kitware

There are a few  seats available in case you can make it up to visit us.
https://goo.gl/forms/M3WmJcV9W6qKTK8x2

Thanks and hope to see you here.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-- 

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] Ignore installation failure

2018-02-20 Thread David Adam

On Sun, 18 Feb 2018, David Adam wrote:
> Our project installs an empty directory for other programs to drop files 
> in, the location of which is overrideable with a cache variable. Some 
> environments set the location of this directory outside the writeable 
> area and create it themselves, so I'd like to set up CMake so that it 
> tries to create the directory but skips over it if there is a failure.
> 
> At the moment we use:
> 
> SET(extra_completionsdir
> ${rel_datadir}/fish/vendor_completions.d
> CACHE STRING "Path for extra completions")
> INSTALL(DIRECTORY DESTINATION ${extra_completionsdir})
> 
> but that fails if the destination is not writeable.
> 
> Is there an idiomatic way of ignoring a failed installation step? At the 
> moment, I'm trying various install(script code execute_process(... 
> incantations, but I'm aware there's lots of corner cases with DESTDIR and 
> so on.

For the record, I ended up implementing just enough to make our use case 
work:

FUNCTION(FISH_TRY_CREATE_DIRS)
  FOREACH(dir ${ARGV})
IF(NOT IS_ABSOLUTE ${dir})
  SET(abs_dir "\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${dir}")
ELSE()
  SET(abs_dir "\$ENV{DESTDIR}${dir}")
ENDIF()
INSTALL(SCRIPT CODE "EXECUTE_PROCESS(COMMAND mkdir -p ${abs_dir} 
OUTPUT_QUIET ERROR_QUIET)
 EXECUTE_PROCESS(COMMAND chmod 755 ${abs_dir} 
OUTPUT_QUIET ERROR_QUIET)
")
  ENDFOREACH()
ENDFUNCTION(FISH_TRY_CREATE_DIRS)

Perhaps that will help someone in a similar situation in the future.

David Adam
zanc...@ucc.gu.uwa.edu.au

-- 

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

[CMake] Ignore installation failure

2018-02-17 Thread David Adam

Hi there,

Our project installs an empty directory for other programs to drop files 
in, the location of which is overrideable with a cache variable. Some 
environments set the location of this directory outside the writeable 
area and create it themselves, so I'd like to set up CMake so that it 
tries to create the directory but skips over it if there is a failure.

At the moment we use:

SET(extra_completionsdir
${rel_datadir}/fish/vendor_completions.d
CACHE STRING "Path for extra completions")
INSTALL(DIRECTORY DESTINATION ${extra_completionsdir})

but that fails if the destination is not writeable.

Is there an idiomatic way of ignoring a failed installation step? At the 
moment, I'm trying various install(script code execute_process(... 
incantations, but I'm aware there's lots of corner cases with DESTDIR and 
so on.

Thanks

David Adam
zanc...@ucc.gu.uwa.edu.au
-- 

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] announce: free VTK, ParaView and CMake training at Kitware New York next month

2018-02-05 Thread David E DeMarle

Hi Alan,

Unfortunately no, not for this run through. For this first run through of
the new material we want it to be local only. This way we can keep it
highly interactive (it is harder to assist everyone well in an online
group).

The VTK and ParaView slides at least will be posted online, I'm not
entirely certain yet, but I think the CMake slides will be too.
In the next run through we will very likely open it up and at least post
videos after the fact.

thanks


David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Feb 1, 2018 at 3:49 PM, Alan W. Irwin 
wrote:

> On 2018-02-01 15:16-0500 David E DeMarle wrote:
>
> Kitware is going to present three free, one day training courses next month
>> at our Albany NY headquarters. The outline for each day follows.
>>
>
> For those of who would prefer not to make such a long trip but who are
> extremely interested in those training courses, would you be willing
> to record a video of those training sessions and make that video
> freely accessible on the web?
>
> I (and presumably many others here since this is the CMake mailing
> list after all) would be particularly interested in watching the last-day
> session
>
> March 15'th "CMake and Friends"
>> all day: w/ Bill Hoffman
>>
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
-- 

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

[CMake] Support for fortran interoperability with C within CMake

2018-02-04 Thread David Vowles

Hello,

As you may be aware recent Fortran standards have introduced the notion of 
standardised interoperability of Fortran with C. To enable practical 
implementation of standardised interoperability the Fortran standard has the 
notion of the Fortran compiler having a "companion C processor" - read 
compatible C compiler. Each Fortran implementation is free to choose which C is 
its companion or companions. The question therefore arises as to whether CMake 
is yet smart enough to correctly choose compatible combinations of C and 
Fortran compilers.

An example might be as follows.

A system has C compilers C1, C2 and C3 and Fortran compilers F1 and F2 
installed. Compiler C1 is not interoperable with F1 or F2, C2 is interoperable 
with F1 but not F2 and C3 is interoperable with both F1 and F2. It would be 
highly desirable for CMake to:

(i)Inform the user (e.g. by a fatal error) that if they choose 
C1 as their C compiler then there is no compatible Fortran compiler available 
on their system;

(ii)  If the user does not specify either a C or Fortran compiler 
that a compatible pair be chosen by CMake. In the example given it might be 
preferable (all other things being equal) for C3 to be chosen as the C compiler 
since it maximizes the number of Fortran compilers with which the software can 
be built.

Does CMake current offer any support in this area? Are there any plans to 
implement / extend such support?

Many thanks,
David.

-- 

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

[CMake] announce: free VTK, ParaView and CMake training at Kitware New York next month

2018-02-01 Thread David E DeMarle

Hi folks,

Kitware is going to present three free, one day training courses next month
at our Albany NY headquarters. The outline for each day follows.

March 13'th "Introductory and applied VTK"

morning:

Dave DeMarle / Lisa Avila - "A hands on introduction to VTK"

afternoon:

Aashish Chaudhary - "VTK and Geosciences"

Berk Geveci - "Flow Visualization"

Ken Martin - "Realistic Rendering"

Sankesh Jhaveri - “A workflow for Medical Visualization”

March 14'th "Introductory and applied ParaView"

morning:

Dan Lipsa / Utkarsh Ayachit - "A hands on introduction to ParaView"

afternoon:

Andy Bauer - "CFD analysis"

T.J. Corona - "Simulation Debugging"

Utkarsh Ayachit - "Quantitative Analysis"

Bob O'Bara - "Point Cloud Processing"

March 15'th "CMake and Friends"
all day: w/ Bill Hoffman

To reserve a seat for the course, please fill out this google form and
we'll get back to you to confirm your reservation.

https://goo.gl/forms/M3WmJcV9W6qKTK8x2

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-- 

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] [cmake-developers] Debugging find_package() search behavior?

2017-10-01 Thread David Cole via CMake

No, I was already promptly corrected by Brad, too. I was not
accounting for the fact that the other find_* calls used inside of
find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to
find a project's config file from the find_package config mode.

I stand corrected. Again. ;-)

However, I stand by my assertion that find modules do what they want.
It's still a bit of a wild wild west, and people make their own find
modules that live inside their own project's source trees.

Config files should be the preferred/primary mechanism for
find_package calls (going on something like 5 or 6 years now...), but
still people write new find modules.

Thanks,
David C.

On Sun, Oct 1, 2017 at 11:52 AM, Alexander Neundorf
 wrote:
> On 2017 M08 29, Tue 11:33:15 CEST David Cole via cmake-developers wrote:
>> That's correct:
>>
>> find modules do what they want, and most do not pay attention to
>> CMAKE_PREFIX_PATH.
>
> are you sure ?
> As long as NO_DEFAULT_PATH is not used in the find_*() calls, 
> CMAKE_PREFIX_PATH
> is used automatically by them.
>
> Alex
>
-- 

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] rebuild externalprojects

2017-09-21 Thread David Cole via CMake

By manually deleting (or touching) the stamp file associated with the
earliest step you need to re-run.

ExternalProject is not for auto-detecting changes to stuff and
minimally re-running build steps. It's for static stuff that doesn't
change much.

Find the "-build" stamp file that's associated with the project
containing the source you changed and delete it.

Then run the build from the top and that one and everything that
depends on it afterwards should rebuild.

HTH,
David C.

On Thu, Sep 21, 2017 at 7:09 AM, J Decker  wrote:
> how do I make sure that externalprojects get built if I change a source in
> one?
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

Sorry for the mis-statement. I stand corrected.

However, it is true that there are many find modules with some
differences in approach, and if you are using one, you need to read up
on the individual documentation of that particular find module.
Especially if you need to know how to tell it how to find the exact
one you already know you have...

On Tue, Aug 29, 2017 at 11:49 AM, Brad King  wrote:
> On 08/29/2017 11:33 AM, David Cole wrote:
>> That's correct:
>>
>> find modules do what they want, and most do not pay attention to
>> CMAKE_PREFIX_PATH.
>
> CMAKE_PREFIX_PATH *is* used by find modules.
>
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
> See the documentation of find_library, find_path, etc. for details.
> Each command searches an appropriate `/` where ``
> is based on the kind of command doing the searching.
>
> -Brad
-- 

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] Debugging find_package() search behavior?

That's correct:

find modules do what they want, and most do not pay attention to
CMAKE_PREFIX_PATH.

It's better to use a config file, but when you have to use a find
module, you have to dig in and figure out the right way to use each
one.



On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
 wrote:
> I think the discrepancy here might be config vs module find mode. The
> documentation I linked seems to be for config mode only, however I'm
> utilizing the CMake-shipped FindZLIB.cmake module to find this
> particular library. Does this offer no guarantees on how
> CMAKE_PREFIX_PATH is used?
>
> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
>  wrote:
>> What I'm hoping for is that find_package() follows the rules it
>> documents here:
>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>
>> Specifically, it states it searches these paths (and that  is
>> treated case-insensitive):
>>
>> /   (W)
>> /(cmake|CMake)/ (W)
>> /*/   (W)
>> /*/(cmake|CMake)/ (W)
>> /(lib/|lib|share)/cmake/*/  (U)
>> /(lib/|lib|share)/*/(U)
>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>
>> If this is true, then the 3rd one from the top should be a match,
>> because  is set to:
>>
>> E:/code/frontend/msvc_2015/third_party/installed
>>
>> And  is set to ZLIB in find_package() first argument, so it
>> should be adding that to the end.
>>
>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>> ("installed") because I have other libraries that get installed in
>> that directory, each with their own directory to contain their
>> installation files. If find_package() is appending  to 
>> like it says it should, it should find each one of them without
>> switching the value of CMAKE_PREFIX_PATH.
>>
>> Am I misunderstanding something?
>>
>>
>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole  wrote:
>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>
>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>>  wrote:
>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King  wrote:
>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>
>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>>> drive letters on Windows.
>>>>>
>>>>> Oops, sent too soon.
>>>>>
>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>>> cross-compiling
>>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>>
>>>>> -Brad
>>>>
>>>> Ok but even if I remove that, find_package() still isn't working..
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at: 
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For more 
>>>> information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at 
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

Is there a ZLIBConfig.cmake file which find_package is searching for?
(i.e. -- somewhere under that directory does that file exist?) On
Windows the case won't matter, but on Linux, a find_package(ZLIB will
expect a case-sensitive match on a ZLIBConfig.cmake file.

If ZLIBConfig.cmake exists, it needs to exist in one of the locations
on that find_package documentation snippet you sent. If it's not
directly in the "zlib" folder, or one of the other folders listed,
then it won't be found. The directory it is in, or something matching
one of those in the list needs to be included in your
CMAKE_PREFIX_PATH.


If that file does not exist, then the CMake FindZLIB.cmake module will
be used in an attempt to find your zlib... And the help for that
speaks of setting a ZLIB_ROOT var if you want to direct it to find a
given zlib. See the "HINTS" section here:

https://cmake.org/cmake/help/v3.6/module/FindZLIB.html#hints


One more hint regarding CMAKE_PREFIX_PATH : despite its name, it is a
**list** of paths, and you can use multiple semi-colon separated
values if necessary. So, if appending "/zlib" works, then you could
always find zlib and all your other stuff too by using two directories
as your CMAKE_PREFIX_PATH value.


HTH,
David C.



On Tue, Aug 29, 2017 at 11:11 AM, Robert Dailey
 wrote:
> What I'm hoping for is that find_package() follows the rules it
> documents here:
> https://cmake.org/cmake/help/v3.6/command/find_package.html
>
> Specifically, it states it searches these paths (and that  is
> treated case-insensitive):
>
> /   (W)
> /(cmake|CMake)/ (W)
> /*/   (W)
> /*/(cmake|CMake)/ (W)
> /(lib/|lib|share)/cmake/*/  (U)
> /(lib/|lib|share)/*/(U)
> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>
> If this is true, then the 3rd one from the top should be a match,
> because  is set to:
>
> E:/code/frontend/msvc_2015/third_party/installed
>
> And  is set to ZLIB in find_package() first argument, so it
> should be adding that to the end.
>
> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
> ("installed") because I have other libraries that get installed in
> that directory, each with their own directory to contain their
> installation files. If find_package() is appending  to 
> like it says it should, it should find each one of them without
> switching the value of CMAKE_PREFIX_PATH.
>
> Am I misunderstanding something?
>
>
> On Tue, Aug 29, 2017 at 10:06 AM, David Cole  wrote:
>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>
>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>  wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King  wrote:
>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>
>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>> drive letters on Windows.
>>>>
>>>> Oops, sent too soon.
>>>>
>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>> cross-compiling
>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>
>>>> -Brad
>>>
>>> Ok but even if I remove that, find_package() still isn't working..
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: 
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more 
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at 
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?