Re: [CMake] find_package and get_target_property

[Saad Khattak]

Thanks Marc. I assume you mean the library does not export its targets
properly? Something like this:

# https://cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets
install(TARGETS generator DESTINATION lib/myproj/generators EXPORT
myproj-targets)
install(EXPORT myproj-targets DESTINATION lib/myproj)

On Fri, Apr 13, 2018 at 3:05 AM CHEVRIER, Marc <marc.chevr...@sap.com>
wrote:

> The creation of “imported” target is the responsibility of the package.
> May be the package “LibA” does not create a such target.
>
> In this case, you have to rely on variables (like LibA_LIBRARIES and so
> on…). The documentation of the package, if any, generally describe how to
> use the package.
>
>
>
>
>
> *From: *CMake <cmake-boun...@cmake.org> on behalf of Saad Khattak <
> saadrus...@gmail.com>
> *Date: *Friday 13 April 2018 at 05:29
> *To: *Cmake Mailing List <cmake@cmake.org>
> *Subject: *[CMake] find_package and get_target_property
>
>
>
> Hi,
>
>
>
> I am successfully able to find a package using find_package(LibA) but I
> cannot do a get_target_property on the package as I get the error:
>
>
>
> get_target_property() called with non-existent target "LibA"
>
>
>
> How do I go about the target properties for a package?
>
>
>
> - Saad
>
-- 

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] find_package and get_target_property

[Saad Khattak]

Hi,

I am successfully able to find a package using find_package(LibA) but I
cannot do a get_target_property on the package as I get the error:

get_target_property() called with non-existent target "LibA"

How do I go about the target properties for a package?

- Saad
-- 

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] FetchContent and multiple CMake projects

[Saad Khattak]

Hi,

I have many independent CMake projects and most projects have external
dependencies. Most of the projects have the same dependency e.g. Catch
testing library.

Each library uses FetchContent so that it can be built independently by
simply cloning its github repository, configuring and generating through
CMake and then building. However, I would also like the ability for these
projects to share the same dependency to save disk space (and compile time)
if they detect that another project already has done FetchContent on a
particular dependency.

Again, note that all projects are independent where their own repositories.

-- EXAMPLE
--
To illustrate the setup: I have LibA, LibB, LibC, LibD, LibE etc. where
each may have a dependency that is found to be the same. So, when LibA is
the only one that is cloned, it uses FetchContent to clone the
dependencies, build them, install them and the test executable linked to
the dependencies properly.

Now LibB is cloned and it has some dependencies that LibA doesn't have but
other dependencies that LibA 'does' use. Assuming LibA is already built
successfully, I would like LibB to rely on LibA's dependencies, if found,
otherwise LibB clones, generates and builds its own dependencies.

It is also possible that LibA was never cloned/built and thus LibB must
clone/generate/build all dependencies.
-- END EXAMPLE
--

To solve this issue, I am using a combination of find_package(...) and
FetchContent, however the whole setup is starting to show cracks, is
fragile and difficult to test and maintain. So now I am wondering whether
there is a better way to about solving the issue.

Thank you,
Saad
-- 

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] FetchContent and find_package

[Saad Khattak]

Thank you Craig.

>> Imported targets are definitely more preferable though

Can you please elaborate on this?

On Tue, Apr 10, 2018 at 10:23 AM Craig Scott <craig.sc...@crascit.com>
wrote:

>
> On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Hi,
>>
>> My project is setup in such a way that I perform a FetchContent 'only if'
>> my find_package fails.
>>
>> This works very well until I start building different configurations.
>> Let's say I generate and build Debug for my project. My project tries to
>> find_package(LibA QUIET) and cannot find it. So, it performs a
>> FetchContent(...) step, builds the dependency and my library and installs
>> everything. This works flawlessly.
>>
>> Now I start building a Release version with different build and install
>> folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries
>> and does not perform a FetchContent(...) step and in turn doesn't build the
>> Release version of the dependent library. Consequently, the linking step
>> fails.
>>
>> Is there an easy way around this issue?
>>
>> I say 'easy' because I could write some CMake scripts to search for the
>> libraries after a successful find_package(...) and if it only finds
>> libraries for Debug when it really wants Release, it performs a
>> FetchContent(...). However, this could be quite fragile.
>>
>> It would be nice if CMake has a way of knowing if an installed library,
>> found through find_package(...) is Debug, Release, RelWithDebInfo etc.
>>
>
> If the package found by find_package() is picking up a config file
> generated by CMake, then you can check the IMPORTED_CONFIGURATIONS property
> of its imported target(s). This will give you a list of configurations the
> package provides. Ideally, a single package should cover all relevant build
> types, not one package per build type. This is up to the project itself
> though and how it builds/installs its package. If the found package only
> provides variables instead of imported targets, then you'll have to work
> harder and go through whatever variables it provides to see if you can work
> out what the package can give you. Imported targets are definitely more
> preferable though.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-- 

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] FetchContent and find_package

[Saad Khattak]

Hi,

My project is setup in such a way that I perform a FetchContent 'only if'
my find_package fails.

This works very well until I start building different configurations. Let's
say I generate and build Debug for my project. My project tries to
find_package(LibA QUIET) and cannot find it. So, it performs a
FetchContent(...) step, builds the dependency and my library and installs
everything. This works flawlessly.

Now I start building a Release version with different build and install
folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries
and does not perform a FetchContent(...) step and in turn doesn't build the
Release version of the dependent library. Consequently, the linking step
fails.

Is there an easy way around this issue?

I say 'easy' because I could write some CMake scripts to search for the
libraries after a successful find_package(...) and if it only finds
libraries for Debug when it really wants Release, it performs a
FetchContent(...). However, this could be quite fragile.

It would be nice if CMake has a way of knowing if an installed library,
found through find_package(...) is Debug, Release, RelWithDebInfo etc.

- Saad
-- 

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 find_package(...) distinguish between debug and release installs?

[Saad Khattak]

Thanks Bo.

I have added the suffix to my libraries already, however with some 3rd
party libraries that I am getting with FetchContent, I have no control over
how they name their libraries.

Now, their Config.cmake files have release targets that are
globbed by one of the CMake config files (which is part of the install
process). So CMake 'can' figure out which configuration has been installed
and I was hoping that there was a built-in way to distinguish that rather
than me writing some custom scripts for it (where the scripts will search
for the debug/release target files).

On Mon, Apr 9, 2018 at 11:03 PM Bo Zhou <bo.schwarzst...@gmail.com> wrote:

> Hi,
>
> Generally speaking, no, you might have to use the suffix or special name
> to distinguish the different library, such as with the "_d" suffix.
>
> The Boost module of CMake is a considerable example, since it could
> generate different names for Debug and Release libraries on Windows.
>
> At POSIX(UNIX, OSX, Linux), sometimes user mixes the library, it still
> works well. On Windows, it's dangerous or even won't work with mixed
> libraries which were built by different Visual Studios with different
> runtime libraries.
>
> Cheers.
>
> On Tue, Apr 10, 2018 at 10:56 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Hi,
>>
>> When find_package(LibA) sets the LibA_FOUND variable, is it possible to
>> know if the package found is the Debug or Release build (or both)? I have a
>> fairly complex build setup where I need to be able to distinguish if
>> find_package(LibA) found a Debug or Release build.
>>
>> - Saad
>>
>> --
>>
>> 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] Can find_package(...) distinguish between debug and release installs?

[Saad Khattak]

Hi,

When find_package(LibA) sets the LibA_FOUND variable, is it possible to
know if the package found is the Debug or Release build (or both)? I have a
fairly complex build setup where I need to be able to distinguish if
find_package(LibA) found a Debug or Release build.

- Saad
-- 

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] Why isn't target_link_libraries not enough in some cases?

[Saad Khattak]

Hi,

I am fetching and building SDL2 using FetchContent and then using
target_link_libraries(MyExe SDL2) in the hopes that the required include
directories and libraries will be added populated properly. The example
project can be found here:

https://github.com/samaursa/cmake_fetch_content_SDL2

Unfortunately, it seems that I have to manually specify the include
directories. Although target_link_directories(...) does take care of the
linking against the correct libraries. When it comes to my own CMake
enabled libraries, I do not have to specify the include directories.

This is problematic when installing my libraries or executables that depend
on SDL2 because the include directory for SDL is absolute (
https://cmake.org/Bug/view.php?id=15788).

Is SDL2 setup incorrectly or is there something I am overlooking?

Here is the CMakeLists.txt in the above mentioned example:
->

cmake_minimum_required(VERSION 3.11)

project(testProj)

include(FetchContent)

FetchContent_Declare(
  SDL2
  GIT_REPOSITORY "https://github.com/spurious/SDL-mirror;
  )

FetchContent_GetProperties(SDL2)
if(NOT sdl2_POPULATED)
  FetchContent_Populate(SDL2)
  message(STATUS "Catch source dir: ${sdl2_SOURCE_DIR}")
  message(STATUS "Catch binary dir: ${sdl2_BINARY_DIR}")
  add_subdirectory(${sdl2_SOURCE_DIR} ${sdl2_BINARY_DIR})
endif()

add_executable(testExe
  main.cpp
  )

message(STATUS "Catch include dir: ${sdl2_SOURCE_DIR}/include")

target_link_libraries(testExe SDL2)

# the following line is necessary, target_link_libraries for SDL2
# does not automatically set the correct include directories
target_include_directories(testExe PUBLIC ${sdl2_SOURCE_DIR}/include)

<-

Regards,
Saad
-- 

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] Listing all the include directories

[Saad Khattak]

Thanks Robert. Too bad that this something I cannot inspect. A list of
include directories would be useful even with unexpanded generator
expressions.

CMake-server mode sounds like an interesting option.

On Tue, Mar 27, 2018 at 10:47 AM Robert Maynard <robert.mayn...@kitware.com>
wrote:

> In general your options are to look at the command line or use
> cmake-server mode to query the code model. The full set of include
> directories is not known while configuring due to generator
> expressions expanding after the configure step.
>
> On Mon, Mar 26, 2018 at 9:45 PM, Saad Khattak <saadrus...@gmail.com>
> wrote:
> > Hi,
> >
> > I have many libraries and packages that are being linked using
> > target_link_libraries(...) where CMake takes care of the include
> > directories. There are cases where I get compile errors because I don't
> know
> > the exact include directories.
> >
> > I thought perhaps I could get the include directories of my target by
> doing
> > the following:
> >
> > get_target_property(INCLUDE_DIRS MyExeThatLinksToManyLibs
> > INCLUDE_DIRECTORIES)
> > message(STATUS ${INCLUDE_DIRS}) # hoped that this would print all the
> > include directories
> >
> > Unfortunately, that did not work as expected. It was missing directories
> > that I know are added to the include directories of the target (because
> the
> > compiler is able to find the headers properly).
> >
> > Apart from sifting through the compile commands, is there a nice way to
> > debug the include directories of a target?
> >
> > Thank you,
> > Saad
> >
> > --
> >
> > 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] Listing all the include directories

[Saad Khattak]

Hi,

I have many libraries and packages that are being linked using
target_link_libraries(...) where CMake takes care of the include
directories. There are cases where I get compile errors because I don't
know the exact include directories.

I thought perhaps I could get the include directories of my target by doing
the following:

get_target_property(INCLUDE_DIRS MyExeThatLinksToManyLibs
INCLUDE_DIRECTORIES)
message(STATUS ${INCLUDE_DIRS}) # hoped that this would print all the
include directories

Unfortunately, that did not work as expected. It was missing directories
that I know are added to the include directories of the target (because the
compiler is able to find the headers properly).

Apart from sifting through the compile commands, is there a nice way to
debug the include directories of a target?

Thank you,
Saad
-- 

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] Generator Expressions and FetchContent

[Saad Khattak]

I do use target_link_libraries when it comes to C++ projects and it works
wonderfully for them. However, in this case, my base project has a bunch of
helper files with CMake functionality that help me work with and build my
library of projects (which you can see here
https://github.com/2LoC/tl_base_ci).

Of course, these helper .cmake files (with the functionality I want) are in
the tl_base_ci project which can be either (1) cloned separately, built,
(2) Installed without building, or (3) cloned through ExternalProject_Add
(which I am trying to convert to FetchContent). In all cases, the include
directories might differ, which is why I use rely on the generator
expressions expanding.

In projects depending on tl_base_ci (e.g.
https://github.com/2LoC/tl_proj_template), I have CMake includes like this:

include("${tl_base_ci_INCLUDE_DIRECTORY}/tl_base_ci/tl_common.cmake") # in
the actual project, it's slightly different as it searches for the file in
a list of directories returned by
get_target_property(... INTERFACE_INCLUDE_DIRECTORIES)

Where the tl_base_ci_INCLUDE_DIRECTORY might differ. So ultimately I was
hoping for a way to reliably include the helper .cmake files (i.e. figure
out tl_base_ci's include directory path). I did that with
get_target_property(...) which worked great for ExternalProject_Add, but
did not work so well for FetchContent because the generator expressions did
not expand.

Hopefully I was able to explain the problem well. If there is any
confusion, please let me know.



On Mon, Mar 19, 2018 at 7:11 AM Craig Scott <craig.sc...@crascit.com> wrote:

> On Mon, Mar 19, 2018 at 8:25 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Thank you for the clarification Craig.
>>
>> >> If you made your main target link against LibA, you'd see that CMake
>> automatically expands out the generator expressions when it constructs the
>> link command line for main, so the example as it stands doesn't actually
>> have any error.
>>
>> In my actual project, a library like LibA has .cmake files that can be
>> included by dependent projects to reuse. Of course, CMake `include` does
>> not get affected by target_link_libraries.
>>
>> I would like dependent projects to have the ability to use an existing
>> clone of LibA, if found (e.g. using find_package), otherwise clone locally
>> for using ExternalProject_Add which I am now trying to refactor to
>> FetchContent. Another option open to dependent projects is to force the
>> FetchContent on all repositories regardless of what find_package returns
>> (this is great for testing locally to ensure I have no uncommitted,
>> unpushed changes).
>>
>> Using existing clones is a way to ensure that every project dependent on
>> LibA doesn't clone it's own copy (unless forced to do so).
>>
>> To allow the possibility for any dependent project to include the .cmake
>> files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property
>> (using get_target_property) for LibA and then include the .cmake utility
>> files like this:
>>
>> include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake)
>>
>> Perhaps I am approaching the problem incorrectly? Essentially, I would
>> like a way to reliably include .cmake files found in LibA's include folder
>> regardless of how LibA was acquired (e.g. cloned and built and/or installed
>> separately or acquired using FetchContent). In my case, I could only think
>> of the above as a reliable way to include the files.
>>
>
> Rather than focusing on including files, I would choose to base things
> around targets. If the rest of your project simply links against the
> required target name, the target itself should bring with it any transitive
> dependencies such as required header search paths, dependent libraries that
> must also be linked, etc. These are the INTERFACE_... properties that can
> be set on a target, usually by commands such as
> target_include_directories(foo INTERFACE ...), target_link_libraries(foo
> INTERFACE ...), etc. When building directly from your source tree, the
> targets will be directly available. When using find_package(), the package
> should provide import targets. The rest of your project shouldn't really
> need to care which one of the two it is dealing with. This is the
> recommended way to structure a situation like this. You shouldn't need to
> also pull in a secondary .cmake file in most circumstances, but maybe I'm
> missing something about your particular situation.
>
>
>
>>
>> On Sun, Mar 18, 2018 at 4:22 PM Craig Scott <craig.sc...@crascit.com>
>> wrote:
>>
>>> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak <saadrus...@gmail.com>
>>> wrote

Re: [CMake] Generator Expressions and FetchContent

[Saad Khattak]

Thank you for the clarification Craig.

>> If you made your main target link against LibA, you'd see that CMake
automatically expands out the generator expressions when it constructs the
link command line for main, so the example as it stands doesn't actually
have any error.

In my actual project, a library like LibA has .cmake files that can be
included by dependent projects to reuse. Of course, CMake `include` does
not get affected by target_link_libraries.

I would like dependent projects to have the ability to use an existing
clone of LibA, if found (e.g. using find_package), otherwise clone locally
for using ExternalProject_Add which I am now trying to refactor to
FetchContent. Another option open to dependent projects is to force the
FetchContent on all repositories regardless of what find_package returns
(this is great for testing locally to ensure I have no uncommitted,
unpushed changes).

Using existing clones is a way to ensure that every project dependent on
LibA doesn't clone it's own copy (unless forced to do so).

To allow the possibility for any dependent project to include the .cmake
files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property
(using get_target_property) for LibA and then include the .cmake utility
files like this:

include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake)

Perhaps I am approaching the problem incorrectly? Essentially, I would like
a way to reliably include .cmake files found in LibA's include folder
regardless of how LibA was acquired (e.g. cloned and built and/or installed
separately or acquired using FetchContent). In my case, I could only think
of the above as a reliable way to include the files.



On Sun, Mar 18, 2018 at 4:22 PM Craig Scott <craig.sc...@crascit.com> wrote:

> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Absolutely. Please find the example project here:
>> https://github.com/samaursa/cmake_fetch_content_and_generator_expressions
>>
>>
>> The repository README also includes the output from running `./setup.sh`.
>>
>
>
> Okay that's much clearer, thanks. The example is doing what I'd expect and
> the generator expressions are also expected to be visible at the point your
> example is printing them. If you made your main target link against LibA,
> you'd see that CMake automatically expands out the generator expressions
> when it constructs the link command line for main, so the example as it
> stands doesn't actually have any error.
>
> Generator expressions are not expanded when CMake is processing the files
> (called the *configure* stage), they are expanded only when writing out
> the Makefiles during the *generation* stage. When running cmake from the
> command line, one doesn't tend to think of these two phases as being
> distinct, but you can see it at the end of the cmake log with these two
> messages:
>
> -- Configuring done
> -- Generating done
>
> It is clearer when using the CMake GUI application because you get two
> different buttons, one for Configure and another for Generate, so you have
> to trigger both phases manually. So if you look at the contents of various
> properties and variables with CMake commands like message(...), you are
> doing that during the configure stage and therefore will see unexpanded
> generator expressions.
>
>
>
>
>>
>> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott <craig.sc...@crascit.com>
>> wrote:
>>
>>> Can you provide a small project example that can be used to demonstrate
>>> your problem? The specifics of how you are doing things may be important.
>>>
>>>
>>> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak <saadrus...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> ExternalProject_Add builds, generates and installs and thus any
>>>> generator expressions used will be expanded by the time another library
>>>> uses it.
>>>>
>>>> For example, if I add a library LibA using ExternalProject_Add, I can
>>>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the
>>>> include directory for the library:
>>>>
>>>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA
>>>>   INTERFACE_INCLUDE_DIRECTORIES
>>>>   )
>>>>
>>>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my
>>>> CMake include(...) statements. However, with FetchContent, this is no
>>>> longer possible.
>>>>
>>>> The reason I would like to query a variable is because at project
>>>> generation time, I invoke FetchContent only if LibA is not found by
>>>> find_

Re: [CMake] Generator Expressions and FetchContent

[Saad Khattak]

Absolutely. Please find the example project here:
https://github.com/samaursa/cmake_fetch_content_and_generator_expressions

The repository README also includes the output from running `./setup.sh`.

On Sat, Mar 17, 2018 at 6:47 PM Craig Scott <craig.sc...@crascit.com> wrote:

> Can you provide a small project example that can be used to demonstrate
> your problem? The specifics of how you are doing things may be important.
>
>
> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Hi,
>>
>> ExternalProject_Add builds, generates and installs and thus any generator
>> expressions used will be expanded by the time another library uses it.
>>
>> For example, if I add a library LibA using ExternalProject_Add, I can
>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the
>> include directory for the library:
>>
>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA
>>   INTERFACE_INCLUDE_DIRECTORIES
>>   )
>>
>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my
>> CMake include(...) statements. However, with FetchContent, this is no
>> longer possible.
>>
>> The reason I would like to query a variable is because at project
>> generation time, I invoke FetchContent only if LibA is not found by
>> find_package(LibA).
>>
>> Thus, the include directory for LibA may be in the current build
>> directory (through FetchContent) OR it may be found in the folder where
>> LibA is cloned by the user and generated/built OR an INSTALL of LibA.
>>
>> Perhaps I should not be using `get_target_property` to get the a
>> library's include directory? Either way, would like some guidance in
>> solving this issue.
>>
>> Thank you,
>> Saad
>>
>>
>> --
>>
>> 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
>>
>>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-- 

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] Generator Expressions and FetchContent

[Saad Khattak]

Hi,

ExternalProject_Add builds, generates and installs and thus any generator
expressions used will be expanded by the time another library uses it.

For example, if I add a library LibA using ExternalProject_Add, I can then
query the target property INTERFACE_INCLUDE_DIRECTORIES and get the include
directory for the library:

get_target_property(LibA_INCLUDE_DIRECTORIES LibA
  INTERFACE_INCLUDE_DIRECTORIES
  )

This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my
CMake include(...) statements. However, with FetchContent, this is no
longer possible.

The reason I would like to query a variable is because at project
generation time, I invoke FetchContent only if LibA is not found by
find_package(LibA).

Thus, the include directory for LibA may be in the current build directory
(through FetchContent) OR it may be found in the folder where LibA is
cloned by the user and generated/built OR an INSTALL of LibA.

Perhaps I should not be using `get_target_property` to get the a library's
include directory? Either way, would like some guidance in solving this
issue.

Thank you,
Saad
-- 

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 link against projects added through FetchContent

[Saad Khattak]

Thank you for the clarifications Craig! The confusion mainly stemmed from
${Catch2_SOURCE_DIR} where 'Catch2' should have been lowercase. I had
originally started with the name 'catch' (which would explain why I
accidentally left it unchanged in the _GetProperties function) but when
that didn't work, I started assuming that perhaps it was conflicting with
the actual library. It was all downhill from there :)

After your suggestions, I was successfully able to get it to work. For
future reference for anyone stumbling on this answer, here's a minimum
example of a working version:
https://github.com/samaursa/cmake_fetch_content

>> I'm a little surprised CMake didn't complain about that, it does for me
when I tested this just now

CMake did not warn me about it. I am on CMake Version 3.11.0-rc3. It would
be great if this warning could be emphasized by CMake as without it, it is
difficult to tell what went wrong since `target_link_libraries` also fails
and I simply get compile errors for missing headers.

On Sun, Mar 11, 2018 at 8:55 PM Craig Scott <craig.sc...@crascit.com> wrote:

> Thanks for trying out the new FetchContent module. Comments on your
> question interspersed below.
>
>
> On Mon, Mar 12, 2018 at 11:02 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I would like to know how to use the FetchContent properly so that I can
>> link against downloaded (CMake enabled) projects. I have looked at the
>> CMake docs, which although are quite thorough, almost always fail to list a
>> complete example which is incredibly crucial to get up and running quickly.
>>
>> With ExternalProject_Add, we use add_dependencies(...) but that doesn't
>> seem to be the case for FetchContent. Since I can immediately call
>> add_subdirectory(...), I assumed that I can simply link to the library. But
>> that doesn't seem to do anything.
>>
>
> This is indeed how it should work. After you've called add_subdirectory(),
> the targets defined by the project being added should be immediately
> available just like any other target your own project would define.
>
>
>
>>
>> Here's my CMakeLists.txt
>> ``
>> cmake_minimum_required(VERSION 3.5)
>>
>
> Your minimum CMake version will be 3.11 if you want to use FetchContent,
> so consider specifying that as the minimum version here.
>
>
>
>
>> project(testProj)
>>
>> include(FetchContent)
>>
>> FetchContent_Declare(
>>   Catch2
>>   GIT_REPOSITORY "https://github.com/catchorg/Catch2;
>>   TEST_COMMAND ""
>>   )
>>
>
> As stated in the docs, TEST_COMMAND will be ignored, so don't set it here.
> FetchContent only downloads, it doesn't build (you're in control of that,
> see further comments below). The ExternalProject_Add() docs also recommend
> you set GIT_TAG to the specific git hash you want to use (apart from being
> more robust, it saves having to contact the remote each time CMake is run
> after it has been cloned). FetchContent delegates all downloading to
> ExternalProject, so the comments apply here as well.
>
>
>
>>
>> FetchContent_GetProperties(catch)
>>
>
> This needs to be the same as the first argument to FetchContent_Declare()
> above, i.e. Catch2
>
>
>> if(NOT Catch2_POPULATED)
>>   FetchContent_Populate(Catch2)
>>   add_subdirectory(${Catch2_SOURCE_DIR} ${Catch2_BINARY_DIR})
>>
>
> The documentation for the FetchContent_Populate() function state that the
> variable names use lowercased names of the content name (i.e.
> catch2_SOURCE_DIR rather than Catch2_SOURCE_DIR), so both of these
> variables used here will be empty. I'm a little surprised CMake didn't
> complain about that, it does for me when I tested this just now. Same for
> the variable name used in the if test (i.e. use catch2_POPULATED rather
> than Catch2_POPULATED).
>
> The reason for the lowercasing is that it was found during the 2 years or
> so when we were dog-fooding this module that while people usually got the
> name right, there would be variations in upper/lowercase which made things
> less reliable.
>
>
>
>> endif()
>>
>> add_executable(testExe main.cpp)
>>
>> target_link_libraries(testExe Catch2)
>>
>
> If the Catch2 project defines a library called Catch2, then this line
> should work fine once you fix the above problems. I think you want Catch
> rather than Catch2 though.
>
>
>
>
>> ``
>>
>> CMake populates Catch2 with Catch2-NOTFOUND.
>>
>> So, my question is, how do I link agains

Re: [CMake] How to link against projects added through FetchContent

[Saad Khattak]

I managed to find a solution myself:

``
cmake_minimum_required(VERSION 3.11)

project(testProj)

include(FetchContent)

FetchContent_Declare(
  Catch2
  GIT_REPOSITORY "https://github.com/catchorg/Catch2;
  )

FetchContent_GetProperties(Catch2) #mispelled name in original post
if(NOT Catch2_POPULATED)
  FetchContent_Populate(Catch2)
  message(STATUS "Catch source dir: ${catch2_SOURCE_DIR}")
  message(STATUS "Catch binary dir: ${catch2_BINARY_DIR}")
  add_subdirectory(${catch2_SOURCE_DIR} ${catch2_BINARY_DIR}) #can be case
insensitive
endif()

add_executable(testExe
  main.cpp
  )

message(STATUS "Catch include dir: ${catch2_SOURCE_DIR}/include")

target_link_libraries(testExe Catch) #name of library to link is case
sensitive!
``

On Sun, Mar 11, 2018 at 8:02 PM Saad Khattak <saadrus...@gmail.com> wrote:

> Hi,
>
> I would like to know how to use the FetchContent properly so that I can
> link against downloaded (CMake enabled) projects. I have looked at the
> CMake docs, which although are quite thorough, almost always fail to list a
> complete example which is incredibly crucial to get up and running quickly.
>
> With ExternalProject_Add, we use add_dependencies(...) but that doesn't
> seem to be the case for FetchContent. Since I can immediately call
> add_subdirectory(...), I assumed that I can simply link to the library. But
> that doesn't seem to do anything.
>
> Here's my CMakeLists.txt
> ``
> cmake_minimum_required(VERSION 3.5)
> project(testProj)
>
> include(FetchContent)
>
> FetchContent_Declare(
>   Catch2
>   GIT_REPOSITORY "https://github.com/catchorg/Catch2;
>   TEST_COMMAND ""
>   )
>
> FetchContent_GetProperties(catch)
> if(NOT Catch2_POPULATED)
>   FetchContent_Populate(Catch2)
>   add_subdirectory(${Catch2_SOURCE_DIR} ${Catch2_BINARY_DIR})
> endif()
>
> add_executable(testExe main.cpp)
>
> target_link_libraries(testExe Catch2)
> ``
>
> CMake populates Catch2 with Catch2-NOTFOUND.
>
> So, my question is, how do I link against projects added through
> FetchContent?
>
> - Saad
>
-- 

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 link against projects added through FetchContent

[Saad Khattak]

Hi,

I would like to know how to use the FetchContent properly so that I can
link against downloaded (CMake enabled) projects. I have looked at the
CMake docs, which although are quite thorough, almost always fail to list a
complete example which is incredibly crucial to get up and running quickly.

With ExternalProject_Add, we use add_dependencies(...) but that doesn't
seem to be the case for FetchContent. Since I can immediately call
add_subdirectory(...), I assumed that I can simply link to the library. But
that doesn't seem to do anything.

Here's my CMakeLists.txt
``
cmake_minimum_required(VERSION 3.5)
project(testProj)

include(FetchContent)

FetchContent_Declare(
  Catch2
  GIT_REPOSITORY "https://github.com/catchorg/Catch2;
  TEST_COMMAND ""
  )

FetchContent_GetProperties(catch)
if(NOT Catch2_POPULATED)
  FetchContent_Populate(Catch2)
  add_subdirectory(${Catch2_SOURCE_DIR} ${Catch2_BINARY_DIR})
endif()

add_executable(testExe main.cpp)

target_link_libraries(testExe Catch2)
``

CMake populates Catch2 with Catch2-NOTFOUND.

So, my question is, how do I link against projects added through
FetchContent?

- Saad
-- 

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] Update and build child projects if a parent (dependency) is updated

[Saad Khattak]

Hi,

I have a lot of projects with many dependencies. Support ProjE depends on
ProjD which in turn depends on ProjB and ProjC where ProjB depends on ProjA.

If ProjA, is updated, I would like some way to trigger the generate/build
(or just build, assuming the projects are already generated) ProjB, ProjD
and ProjE (not ProjC as it did not depend on ProjA).

I realize this is not possible without ProjA somehow knowing about its
dependent projects. And so I don't mind if it's a new master project or
super build. What I would like however is for CMake to generate this master
project for me (as it already knows the dependency hierarchy). Then, it'll
just be a matter of building this 'superbuild' which in turn detects that
ProjA has been updated, and updates/builds all its dependents.

I can do this manually by ExternalProject_Add, but that is just error prone
and not at all automated. If the projects go into the double or triple
digit range, you can see why manually preparing the superbuild project is
not a good solution.

Thanks,
Saad
-- 

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] Relaying all command line arguments from SuperBuild to ExternalProject_Add

[Saad Khattak]

Thank you Don, that was it. Querying and storing the args before a call to
'project' and your loop and your conditional were the key.

On Wed, Jan 31, 2018 at 10:14 PM Don Hinton <hinto...@gmail.com> wrote:

> Hi Saad:
>
> On Wed, Jan 31, 2018 at 6:47 PM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Thanks J. I could use that to add preprocessor definitions.
>>
>> However, my question was how I could forward 'all' the command line
>> options that the user uses to generate the SuperBuild project. Suppose I
>> somehow managed to capture all the command line arguments which can include
>> variables specific to CMake and/or projects (i.e. nothing to do with
>> preprocessor definitions) in a variable called CL_CMAKE_ARGS.
>>
>
> The example you are using is close, but not quite correct.
>
> You need to harvest the comandline arguments before calling `project()`,
> just note that it won't work if CMakeCache.txt already exists.
>
> Some CMAKE variables will still have HELPSTRINGS, even if passed via the
> command line, and users can also set a random or blank HELPSTRING if they
> use a cache file.  To overcome these issues, just harvest all cache
> variables and exclude the invariant ones, e.g., CMAKE_COMMAND, etc., e.g.:
>
> $ cat ../CMakeLists.txt
> cmake_minimum_required(VERSION 3.5)
>
> message(STATUS "*** All CACHE_VARIABLES ***")
> get_cmake_property(vars CACHE_VARIABLES)
> foreach(var ${vars})
>   get_property(currentHelpString CACHE "${var}" PROPERTY HELPSTRING)
> message("${var} = [${${var}}]  --  ${currentHelpString}")
> endforeach()
>
> project(xxx)
> message(STATUS "project() called.")
>
> message(STATUS "*** Only CACHE_VARIABLES with HELPSTRING empty or matching
> \"No help,...\" ***")
> get_cmake_property(vars CACHE_VARIABLES)
> foreach(var ${vars})
>   get_property(currentHelpString CACHE "${var}" PROPERTY HELPSTRING)
> if("${currentHelpString}" MATCHES "No help, variable specified on
> the command line." OR "${currentHelpString}" STREQUAL "")
> message("${var} = [${${var}}]  --  ${currentHelpString}")
> endif()
> endforeach()
>
> $ rm -rf * && cmake -DFOO=1 -DCMAKE_BUILD_TYPE=Release -GNinja ..
> -- *** All CACHE_VARIABLES ***
> CMAKE_BUILD_TYPE = [Release]  --  No help, variable specified on the
> command line.
> CMAKE_COMMAND = [/opt/local/bin/cmake]  --  Path to CMake executable.
> CMAKE_CPACK_COMMAND = [/opt/local/bin/cpack]  --  Path to cpack program
> executable.
> CMAKE_CTEST_COMMAND = [/opt/local/bin/ctest]  --  Path to ctest program
> executable.
> CMAKE_EXTRA_GENERATOR = []  --  Name of external makefile project
> generator.
> CMAKE_GENERATOR = [Ninja]  --  Name of generator.
> CMAKE_GENERATOR_PLATFORM = []  --  Name of generator platform.
> CMAKE_GENERATOR_TOOLSET = []  --  Name of generator toolset.
> CMAKE_HOME_DIRECTORY = [/Users/dhinton/cmake_test]  --  Source directory
> with the top level CMakeLists.txt file for this project
> CMAKE_ROOT = [/opt/local/share/cmake-3.10]  --  Path to CMake installation.
> FOO = [1]  --  No help, variable specified on the command line.
> -- The C compiler identification is AppleClang 9.0.0.939
> -- The CXX compiler identification is AppleClang 9.0.0.939
> -- Check for working C compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> -- Check for working C compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -- Check for working CXX compiler:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- project() called.
> -- *** Only CACHE_VARIABLES with HELPSTRING empty or matching "No
> help,..." ***
> FOO = [1]  --  No help, variable specified on the command line.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/dhinton/cmake_test/build
>
> hth...
> don
>
>
>> If I do message(${CL_CMAKE_ARGS}) I get:
>>
>>  -DMY_OPTION_ONE=ON -DMY_OPTION_TWO=OFF -DSOME_VAR_1="Foo"
>>
>>

Re: [CMake] Relaying all command line arguments from SuperBuild to ExternalProject_Add

[Saad Khattak]

Thanks J. I could use that to add preprocessor definitions.

However, my question was how I could forward 'all' the command line options
that the user uses to generate the SuperBuild project. Suppose I somehow
managed to capture all the command line arguments which can include
variables specific to CMake and/or projects (i.e. nothing to do with
preprocessor definitions) in a variable called CL_CMAKE_ARGS.

If I do message(${CL_CMAKE_ARGS}) I get:

 -DMY_OPTION_ONE=ON -DMY_OPTION_TWO=OFF -DSOME_VAR_1="Foo"

Now, when I try something like this:

ExternalProject_Add(target
...
CMAKE_ARGS ${CL_CMAKE_ARGS}
...
)

One would expect CL_CMAKE_ARGS to be expanded and the arguments passed to
the ExternalProject_Add function, but that is not the case. I also tried:

ExternalProject_Add(target
...
CMAKE_ARGS "${CL_CMAKE_ARGS}"
...
)

Neither works. It seems like a bug in CMake but I wanted to confirm that I
am not missing something.

On Wed, Jan 31, 2018 at 3:27 PM J Decker <d3c...@gmail.com> wrote:

>
> (platfrom defines is a variable suitable for like ADD_DEFINITIONS(
> ${PLATFORM_DEFINES} )
>
>
>   string( REPLACE ";" " " PLATFORM_DEFINES_ARG "${PLATFORM_DEFINES}" )
>   ExternalProject_Add( target
> 
> CMAKE_ARGS -DPLATFORM_DEFINES=${PLATFORM_DEFINES_ARG}
> ..
>  )
>
>
> and in the target cmakelists to use the argument
>
>
> STRING( REPLACE " " ";" PLATFORM_DEFINES ${PLATFORM_DEFINES} )
>
> add_definitions( ${PLATFORM_DEFINES} )
>
>
>
> On Wed, Jan 31, 2018 at 9:36 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> I have the following setup:
>> Superbuild
>>- ExternalProject_Add(a...)
>>- ExternalProject_Add(b...)
>>- ExternalProject_Add(c...)
>>- ExternalProject_Add(d...)
>>
>> The SuperBuild is built from command line with some options e.g.
>> -DMY_OPTION=TRUE. I would like all these options to be passed to each of
>> the ExternalProject_Add CMAKE_ARGS.
>>
>> I tried to capture the arguments using the solution posted here:
>> https://stackoverflow.com/a/10218582/368599
>>
>> The arguments are captured properly (i.e. I printed them out to make sure
>> they are correct) but relaying them to ExternalProject_Add appears to be
>> problematic. I tried the following ways to forward the arguments (as
>> outlined in the stackoverflow solution):
>>
>> ExternalProject_Add(...
>>   CMAKE_ARGS ${CMAKE_ARGS}
>>   )
>>
>> ExternalProject_Add(...
>>   CMAKE_ARGS "${CMAKE_ARGS}" # quotes
>>   )
>>
>> ExternalProject_Add(...
>>   CMAKE_ARGS "${MY_CMAKE_ARGS}" # changed the variable name in case it
>> conflicts
>>   )
>>
>> None of that seems to work. CMake appears to ignore the commands
>> forwarded.
>>
>> Is there something I am missing?
>>
>> Thanks,
>> Saad
>>
>>
>> --
>>
>> 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] Relaying all command line arguments from SuperBuild to ExternalProject_Add

[Saad Khattak]

I have the following setup:
Superbuild
   - ExternalProject_Add(a...)
   - ExternalProject_Add(b...)
   - ExternalProject_Add(c...)
   - ExternalProject_Add(d...)

The SuperBuild is built from command line with some options e.g.
-DMY_OPTION=TRUE. I would like all these options to be passed to each of
the ExternalProject_Add CMAKE_ARGS.

I tried to capture the arguments using the solution posted here:
https://stackoverflow.com/a/10218582/368599

The arguments are captured properly (i.e. I printed them out to make sure
they are correct) but relaying them to ExternalProject_Add appears to be
problematic. I tried the following ways to forward the arguments (as
outlined in the stackoverflow solution):

ExternalProject_Add(...
  CMAKE_ARGS ${CMAKE_ARGS}
  )

ExternalProject_Add(...
  CMAKE_ARGS "${CMAKE_ARGS}" # quotes
  )

ExternalProject_Add(...
  CMAKE_ARGS "${MY_CMAKE_ARGS}" # changed the variable name in case it
conflicts
  )

None of that seems to work. CMake appears to ignore the commands forwarded.

Is there something I am missing?

Thanks,
Saad
-- 

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] Querying CMake variables of external CMake projects

[Saad Khattak]

Thank you Konstantin. get_target_properties(...) works very well.

On Sat, Jan 13, 2018 at 12:06 PM Konstantin Tokarev <annu...@yandex.ru>
wrote:

>
>
> 13.01.2018, 06:26, "Saad Khattak" <saadrus...@gmail.com>:
> > Hi,
> >
> > Say I find LibA using find_package(LibA) and I now have access to
> LibA_DIR, which is the build folder of LibA. Is there a way I can query
> additional variables, such as LibA's source directory, install directory
> etc. i.e. variables that are defined by CMake when LibA was being
> generated/built by CMake?
>
> If  find_package(LibA) provides you target "LibA" (i.e., cmake code under
> "if (TARGET LibA)"
> condition is being executed), you can query various properties from it and
> expect them to
> have sane values. See documentation on cmake properties.
>
> If there is no LibA target, it probably means that find_package(LibA) is
> implemented via
> FindLibA.cmake module, and you can only use variables that it sets
> (usually documented in
> the beginning of module)
>
> >
> > Thanks,
> > Saad
> > ,--
> >
> > 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
>
>
> --
> Regards,
> Konstantin
>
-- 

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] Making sure dependent projects are up-to-date

[Saad Khattak]

Thanks J.

That requires me to use ExternalProject_Add. However, in my case, I have
all Libraries generated/built independently. Should I just start using
ExternalProject_Add for dependencies? If yes, what is the best way to do
that in conjunction with 'find_package(...)'?

On Sat, Jan 13, 2018 at 10:28 AM J Decker <d3c...@gmail.com> wrote:

> maybehttps://cmake.org/cmake/help/v3.2/module/ExternalProject.html
>
> BUILD_ALWAYS 1No stamp file, build step always runs
>
> On Fri, Jan 12, 2018 at 7:41 PM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Let's say I have several CMake enabled libraries that have their own
>> respective build directories and have been installed:
>>
>> LibA
>> LibB (depends on A)
>> LibC
>> LibD (depends on LibC and LibA)
>>
>> I then create a new executable project ProjExe that depends on LibD. Now,
>> I am working on LibA, LibB, LibC, LibD and ProjExe simultaneously (e.g.
>> building up functionality in the libraries that the executable uses, fixing
>> bugs etc.).
>>
>> What I would like, is a way to ensure that when ProjExe is built, it
>> first checks whether LibD is up-to-date (i.e. does it have any out of
>> source build files?), if not, it builds LibD first. But LibD depends on
>> LibC and LibA, and then LibD ensures that LibC and LibA are up-to-date
>> before building itself.
>>
>> Is something like this possible in CMake? This is  similar to the
>> 'solution' concept in Visual C++ where a 'solution' can have several
>> projects. ProjExe in the solution can be dependent on external libraries
>> (like the above) and they are part of the 'solution' and are checked to be
>> up-to-date before ProjExe is compiled/linked.
>>
>> Thanks,
>> Saad
>>
>> --
>>
>> 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] Making sure dependent projects are up-to-date

[Saad Khattak]

Hi,

Let's say I have several CMake enabled libraries that have their own
respective build directories and have been installed:

LibA
LibB (depends on A)
LibC
LibD (depends on LibC and LibA)

I then create a new executable project ProjExe that depends on LibD. Now, I
am working on LibA, LibB, LibC, LibD and ProjExe simultaneously (e.g.
building up functionality in the libraries that the executable uses, fixing
bugs etc.).

What I would like, is a way to ensure that when ProjExe is built, it first
checks whether LibD is up-to-date (i.e. does it have any out of source
build files?), if not, it builds LibD first. But LibD depends on LibC and
LibA, and then LibD ensures that LibC and LibA are up-to-date before
building itself.

Is something like this possible in CMake? This is  similar to the
'solution' concept in Visual C++ where a 'solution' can have several
projects. ProjExe in the solution can be dependent on external libraries
(like the above) and they are part of the 'solution' and are checked to be
up-to-date before ProjExe is compiled/linked.

Thanks,
Saad
-- 

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] Querying CMake variables of external CMake projects

[Saad Khattak]

Hi,

Say I find LibA using find_package(LibA) and I now have access to LibA_DIR,
which is the build folder of LibA. Is there a way I can query additional
variables, such as LibA's source directory, install directory etc. i.e.
variables that are defined by CMake when LibA was being generated/built by
CMake?

Thanks,
Saad
-- 

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] Get find_package to choose INSTALLed libraries instead of libraries in the build folder

[Saad Khattak]

Thank you Marc.

That's interesting, I was not aware that they were relinked. I thought they
were just copied.

I guess I'll have to provide the install directory to pick the libraries
found in the install directory instead of the build directory?

Regards,
Saad

On Fri, Jan 12, 2018 at 2:57 AM CHEVRIER, Marc <marc.chevr...@sap.com>
wrote:

> Hi,
>
>
>
> During install step, installed libraries and executables are relinked to
> generate binaries without absolute paths so installed artifacts are
> independent from your build tree.
>
>
>
> During build step, build binaries are used as well as absolute paths so
> produced binaries can be used during build step (i.e. launching an
> executable produced) without requirements regarding paths settings (i.e.
> PATH or LD_LIBRARY_PATH).
>
>
>
>
>
> *From: *CMake <cmake-boun...@cmake.org> on behalf of Saad Khattak <
> saadrus...@gmail.com>
> *Date: *Thursday 11 January 2018 at 19:44
> *To: *Cmake Mailing List <cmake@cmake.org>
> *Subject: *[CMake] Get find_package to choose INSTALLed libraries instead
> of libraries in the build folder
>
>
>
> Hi,
>
>
>
> I would like find_package(MyLib) to link find the libraries found in the
> INSTALL folder instead of the build folder.
>
>
>
> Currently, when I do a find_package(MyLib) and then
> target_link_libraries(target MyLib) the paths all point to MyLib's build
> folder and not the folder where MyLib's library/headers were installed.
>
>
>
> Thank you,
>
> Saad
>
-- 

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] Get find_package to choose INSTALLed libraries instead of libraries in the build folder

[Saad Khattak]

Hi,

I would like find_package(MyLib) to link find the libraries found in the
INSTALL folder instead of the build folder.

Currently, when I do a find_package(MyLib) and then
target_link_libraries(target MyLib) the paths all point to MyLib's build
folder and not the folder where MyLib's library/headers were installed.

Thank you,
Saad
-- 

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] CTest not searching for the correct executable

[Saad Khattak]

That was it, thanks Nils!

For future reference, after adding the test like Nils suggested, calling
"ctest" wouldn't work as it now needs your configuration:

ctest -C Debug

On Fri, Jan 5, 2018 at 11:16 AM Nils Gladitz <nilsglad...@gmail.com> wrote:

> On 05.01.2018 17:11, Saad Khattak wrote:
>
> Hi,
>
> Suppose I have something like this:
>
> add_executable(MyTest main.cpp)
> set_target_properties(MyTest
>   PROPERTIES
>   DEBUG_POSTFIX _d
>   RELEASE_POSTFIX _r
>   )
> add_test(RunTests MyTest) # where MyTest is the 
>
> I expect CMake to recognize that "MyTest" has executables that are named
> "MyTest_d" and "MyTest_r" and NOT MyTest. I expect this because in the
> CMake documentation the  can be an executable target where CMake
> then replaces it with the location of the executable.
>
> However, what I get is errors when running "ctest" where it complains that
> it cannot find "MyTest" when it should really be searching for "MyTest_d"
> and "MyTest_r".
>
> Am I doing something wrong or is this a bug in CMake?
>
>
> You are using the old signature (without NAME|COMMAND) for which the
> documentation states [1]:
> "Unlike the above NAME signature no transformation is performed on
> the command-line to support target names or generator expressions."
>
> Use the new signature instead e.g.:
> add_test(NAME RunTests COMMAND MyTest)
>
> Nils
>
> [1] https://cmake.org/cmake/help/latest/command/add_test.html
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CTest not searching for the correct executable

[Saad Khattak]

Hi,

Suppose I have something like this:

add_executable(MyTest main.cpp)
set_target_properties(MyTest
  PROPERTIES
  DEBUG_POSTFIX _d
  RELEASE_POSTFIX _r
  )
add_test(RunTests MyTest) # where MyTest is the 

I expect CMake to recognize that "MyTest" has executables that are named
"MyTest_d" and "MyTest_r" and NOT MyTest. I expect this because in the
CMake documentation the  can be an executable target where CMake
then replaces it with the location of the executable.

However, what I get is errors when running "ctest" where it complains that
it cannot find "MyTest" when it should really be searching for "MyTest_d"
and "MyTest_r".

Am I doing something wrong or is this a bug in CMake?

Regards,
Saad
-- 

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] Include directories of IMPORTED libraries not propagating

[Saad Khattak]

Hi,

I have the following setup:

ImportedLib (sets location of library files and public include directories)
LibA (publicly includes ImporteLib with
target_link_libraries(...))
Exe  (finds LibA and links against it)

Where ImportedLib uses "set_target_properties(ImportedLib PROPERTIES
IMPORTED_LOCATION_DEBUG ... INTERFACE_INCLUDE_DIRECTORIES ...)" to set its
include directories and prebuilt libraries for linking.

LibA uses "target_link_libraries(LibA PUBLIC ImportedLib)". CMake correctly
generates the project such that LibA now has the include directories of the
ImportedLib. LibA then uses the "install(...)" feature so that "Exe" can
find LibA.

With Exe, I find LibA using "find_package(LibA REQUIRED)" and then
"target_link_libraries(Exe LibA)". Exe inherits LibA's include directories
and links against it. Exe is also able to link against ImportedLib.
However, what Exe does not inherit is the public include directories
specified by ImportedLib. This seems like a bug because it is able to know
about and is able to link against ImportLib prebuilt library files.

If it's not a bug, how do I make sure ImportedLib include directories are
propagated properly?

Regards,
Saad
-- 

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] Installing and exporting multiple configurations of the same library

[Saad Khattak]

Thank you Domen for the workaround. With the workaround I'll have to pick
the correct CMake config file by directory. I was hoping for one
${LIB_NAME}Config.cmake file for all configurations.

I did indeed set the postfix, however our current build requirements (since
we have a mix of CMake and non-CMake enabled projects) dictate the specific
folder structure. Otherwise, I would be fine with the configuration postfix.

The main reason for the directory structure is to allow existing projects
to work while getting the newer projects to rely on CMake.

On Sat, Dec 16, 2017 at 2:56 PM Domen Vrankar <domen.vran...@gmail.com>
wrote:

> 2017-12-16 0:18 GMT+01:00 Saad Khattak <saadrus...@gmail.com>:
>
>> Hi,
>>
>> I have 4 configurations (2 for Debug and 2 for Release) and I would like
>> to install the libraries such that they are installed in the correct
>> directories.
>>
>> Installing without worrying about configurations looks like this:
>>
>> install(TARGETS ${LIB_NAME}
>> EXPORT ${LIB_NAME}Config
>> PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>> LIBRARY DESTINATION "bin/${LIB_NAME}/"
>> ARCHIVE DESTINATION "lib/${LIB_NAME}/"
>> )
>>
>> However, different configurations overwrite the binaries. So instead, I
>> did something like this (I'm going over all my configurations in a foreach):
>>
>> install(TARGETS ${LIB_NAME}
>> CONFIGURATIONS DEBUG
>> EXPORT ${LIB_NAME}Config
>> PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>> LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
>> ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
>> )
>>
>> install(TARGETS ${LIB_NAME}
>> CONFIGURATIONS RELEASE
>> EXPORT ${LIB_NAME}Config
>> PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
>> LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
>> ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
>> )
>>
>> however, that results in the error:
>> CMake Error: INSTALL(EXPORT ...) includes target "MyLibrary" more than
>> once in the export set.
>>
>> The error makes sense, in that I cannot have multiple exports in the same
>> export set, in this case ${LIB_NAME}Config. However, I would like CMake to
>> choose a different directory based on the configuration.
>>
>
> A simple solution would be to write
>
> install(TARGETS ${LIB_NAME}
> CONFIGURATIONS DEBUG
> EXPORT ${LIB_NAME}Config-d
> PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
> LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
> ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
> )
> install(TARGETS ${LIB_NAME}
> CONFIGURATIONS RELEASE
> EXPORT ${LIB_NAME}Config
> PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
> LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
> ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
> )
>
> and then use FILE parameter for install(EXPORT ... FILE
> ${LIB_NAME}Config.cmake ...) command to rename the file from
> ${LIB_NAME}Config-d.cmake to ${LIB_NAME}Config.cmake.
>
> See here for details:
> https://cmake.org/cmake/help/latest/command/install.html#installing-exports
> .
>
> Also one thing that you can do is set:
>
> set(CMAKE_DEBUG_POSTFIX "-debug")
>
> so that your libraries when built in Debug mode will automatically get
> -debug suffix (example: my_lib.so for Release and my_lib-debug.so for
> debug). This way you don't need to install the library in two separate sub
> directories (named debug/ and release/ in your case).
>
>
>> Now there is a workaround... sort of. I could name the binaries based on
>> the configuration but that doesn't work with our existing build systems. We
>> want the following:
>>
>> lib/${LIB_NAME}/${CONFIG}/libname
>>
>> Any way to get CMake to install the libraries this way?
>>
>
> Not certain what the intended way of doing this debug/releas export on
> Linux is as you can only build one build type at a time but the
> install(EXPORT ...) command already generates:
> ${LIB_NAME}Config.cmake and ${LIB_NAME}Config-debug.cmake or
> ${LIB_NAME}Config-release.cmake
>
> If you install the files in two separate directories and diff them you'll
> notice that ${LIB_NAME}Config.cmake files (and Version files if you
> generate one) are the same and -debug.cmake and -release.cmake differ so
> possibly 

[CMake] CMake skip unnecessary compiler checks

[Saad Khattak]

Hi,

We have about a hundred projects that use CMake to do the compilation. Each
night, we do a clean build and CMake performs unnecessary compiler checks
for every single project:

-- The C compiler identification is MSVC 17.0.61030.0
-- The CXX compiler identification is MSVC 17.0.61030.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 11.0/VC/bin/x86_amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 11.0/VC/bin/x86_amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 11.0/VC/bin/x86_amd64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 11.0/VC/bin/x86_amd64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: x

Now I can understand if CMake needs to do it once, but when it does this
100 times, the build slows down a few seconds per project for no reason
especially when we know, after the first project generation, that things
are working.

Using the workaround "project(myProj NONE)" is not good because it has
other side effects. I would like CMake to cache the result of the above
checks somehow for subsequent projects.

Also, just as an FYI for anyone on Linux, CMake's compiler identification
and checking for a working compiler works almost instantaneously on Linux
(e.g. trying the same on Linux will start the generation process pretty
much instantaneously). On Windows this takes a while (about 8 seconds). Not
sure why there is a big discrepancy in the way the compilers are identified
and checked.

Thank you,
Saad
-- 

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] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

[Saad Khattak]

Thank you Marc. I found that the following also works:

target_link_libraries(LibD INTERFACE LibA LibB)

However, my guess is that in the future the above may break as it is
assuming LibD is an INTERFACE instead of an IMPORTED library. I'll switch
to your version instead as it seems to be more correct.

On Thu, Dec 14, 2017 at 3:40 AM CHEVRIER, Marc <marc.chevr...@sap.com>
wrote:

> I think you can fill a bug about erroneous behaviour when a list is
> specified with command set_target_properties for property
> IMPORTED_LINK_INTERFACE_LIBRARIES.
>
>
>
> Another way to specify the property is to use command set_property which
> supports multiple values for a property:
>
> set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA
> LibB)
>
>
>
>
>
> *From: *CMake <cmake-boun...@cmake.org> on behalf of Saad Khattak <
> saadrus...@gmail.com>
> *Date: *Thursday 14 December 2017 at 03:20
> *To: *Craig Scott <craig.sc...@crascit.com>
> *Cc: *Cmake Mailing List <cmake@cmake.org>
> *Subject: *Re: [CMake] Using SET_TARGET_PROPERTIES and
> IMPORTED_LINK_INTERFACE_LIBRARIES
>
>
>
> Thanks Craig for your reply.
>
>
>
> The issue is that both "LibA" and "LibB" have been set using
> "add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
> both have some properties that are being set.
>
>
>
> Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
> they have their own include and link directories and other library
> dependencies.
>
>
>
> The nice thing about using LibA directly is then LibD inherits all the
> include and link directories of LibA and LibB which then get inherited by
> any library or executable that includes LibD (and ultimately, the whole
> point of modern CMake):
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
> IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
> IMPORTED CMake libraries
>
> )
>
>
>
> If I use "LibA;LibB" then first, I have to manually extract the library
> names of the imported CMake libraries LibA and LibB. Then, I have to call
> "target_include_directories" and "target_link_libraries" for all
> dependencies of LibA and LibB, even though these dependencies were defined
> in their own respective CMake files when calling "add_library(LibA STATIC
> IMPORTED)"
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
> IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
> recognizes LibA and LibB as IMPORTED CMake libraries
>
> )
>
>
>
> Regards,
>
> Saad
>
>
>
> On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.sc...@crascit.com>
> wrote:
>
> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
> Hi,
>
>
>
> I have several imported libraries:
>
>
>
> LibA
>
> LibB
>
> LibC
>
>
>
> Where each imported library has been populated by (where ${LIB_NAME} is
> either LibA, LibB or LibC):
>
>
>
> add_library(${LIB_NAME} STATIC IMPORTED)
>
>
>
> And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
> properly:
>
>
>
> set_target_properties(${LIB_NAME}
>
> PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>
>"location/of/library.lib"
>
> )
>
>
>
> Now let's say I have another imported library LibD that depends on LibA
> and LibB such that any executable that uses LibD must also link with LibA
> and LibB. To do that, I use:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
> IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>
>   )
>
>
>
> You probably want this instead:
>
>
>
> set_target_properties(LibD
>
>   PROPERTIES
>
> IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
>
> )
>
>
>
> Note that if the property value is a list, you have to provide it as a
> single string (i.e. "LibA;LibB" rather than LibA LibB)
>
>
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
-- 

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] Installing and exporting multiple configurations of the same library

[Saad Khattak]

Hi,

I have 4 configurations (2 for Debug and 2 for Release) and I would like to
install the libraries such that they are installed in the correct
directories.

Installing without worrying about configurations looks like this:

install(TARGETS ${LIB_NAME}
EXPORT ${LIB_NAME}Config
PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
LIBRARY DESTINATION "bin/${LIB_NAME}/"
ARCHIVE DESTINATION "lib/${LIB_NAME}/"
)

However, different configurations overwrite the binaries. So instead, I did
something like this (I'm going over all my configurations in a foreach):

install(TARGETS ${LIB_NAME}
CONFIGURATIONS DEBUG
EXPORT ${LIB_NAME}Config
PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
LIBRARY DESTINATION "bin/${LIB_NAME}/debug/"
ARCHIVE DESTINATION "lib/${LIB_NAME}/debug"
)

install(TARGETS ${LIB_NAME}
CONFIGURATIONS RELEASE
EXPORT ${LIB_NAME}Config
PUBLIC_HEADER DESTINATION "include/${LIB_NAME}"
LIBRARY DESTINATION "bin/${LIB_NAME}/release/"
ARCHIVE DESTINATION "lib/${LIB_NAME}/release/"
)

however, that results in the error:
CMake Error: INSTALL(EXPORT ...) includes target "MyLibrary" more than once
in the export set.

The error makes sense, in that I cannot have multiple exports in the same
export set, in this case ${LIB_NAME}Config. However, I would like CMake to
choose a different directory based on the configuration.

Now there is a workaround... sort of. I could name the binaries based on
the configuration but that doesn't work with our existing build systems. We
want the following:

lib/${LIB_NAME}/${CONFIG}/libname

Any way to get CMake to install the libraries this way?

Thank you,
Saad
-- 

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] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

[Saad Khattak]

Thanks Craig for your reply.

The issue is that both "LibA" and "LibB" have been set using
"add_library(LibA STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and
both have some properties that are being set.

Ultimately, CMake recognizes LibA and LibB as CMake library projects, and
they have their own include and link directories and other library
dependencies.

The nice thing about using LibA directly is then LibD inherits all the
include and link directories of LibA and LibB which then get inherited by
any library or executable that includes LibD (and ultimately, the whole
point of modern CMake):

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as
IMPORTED CMake libraries
)

If I use "LibA;LibB" then first, I have to manually extract the library
names of the imported CMake libraries LibA and LibB. Then, I have to call
"target_include_directories" and "target_link_libraries" for all
dependencies of LibA and LibB, even though these dependencies were defined
in their own respective CMake files when calling "add_library(LibA STATIC
IMPORTED)"

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer
recognizes LibA and LibB as IMPORTED CMake libraries
)

Regards,
Saad

On Wed, Dec 13, 2017 at 4:32 PM Craig Scott <craig.sc...@crascit.com> wrote:

> On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I have several imported libraries:
>>
>> LibA
>> LibB
>> LibC
>>
>> Where each imported library has been populated by (where ${LIB_NAME} is
>> either LibA, LibB or LibC):
>>
>> add_library(${LIB_NAME} STATIC IMPORTED)
>>
>> And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
>> properly:
>>
>> set_target_properties(${LIB_NAME}
>> PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
>>"location/of/library.lib"
>> )
>>
>> Now let's say I have another imported library LibD that depends on LibA
>> and LibB such that any executable that uses LibD must also link with LibA
>> and LibB. To do that, I use:
>>
>> set_target_properties(LibD
>>   PROPERTIES
>> IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
>>   )
>>
>
> You probably want this instead:
>
> set_target_properties(LibD
>   PROPERTIES
> IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
> )
>
>
> Note that if the property value is a list, you have to provide it as a
> single string (i.e. "LibA;LibB" rather than LibA LibB)
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

[Saad Khattak]

Hi,

I have several imported libraries:

LibA
LibB
LibC

Where each imported library has been populated by (where ${LIB_NAME} is
either LibA, LibB or LibC):

add_library(${LIB_NAME} STATIC IMPORTED)

And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set
properly:

set_target_properties(${LIB_NAME}
PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
   "location/of/library.lib"
)

Now let's say I have another imported library LibD that depends on LibA and
LibB such that any executable that uses LibD must also link with LibA and
LibB. To do that, I use:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
  )

However, the above syntax is incorrect and CMake complains that
SET_TARGET_PROPERTIES was called with incorrect number of arguments.

So I thought maybe the following will work:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA
IMPORTED_LINK_INTERFACE_LIBRARIES LibB
  )

Although this time CMake doesn't complaint, only LibB's libraries are
linked ultimately, LibA is overwritten. Doing the following, of course,
doesn't work because LibA is now an imported library and not exactly a
variable that can be used directly:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "${LibA};${LibB}" # not correct
because LibA and LibB are CMake imported libraries, not direct paths to
libraries
  )

Is there any way to specify, for an imported target, multiple dependencies
on other libraries (and/or dependencies on other imported libraries).

Thanks,
Saad
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Using CMake include does not seem to work intuatively

[Saad Khattak]

Hi,

Let's say I have the following directory structure:
~/Repos/MyRepo/CMakeLists.txt
~/CMakeFiles/Foo.cmake
~/CMakeFiles/Bar.cmake

In the CMakeLists.txt I have the following command:

include(~/CMakeFiles/Foo.cmake)

And in Foo.cmake I have the following command:

include(Bar.cmake)

Turns out that he `include(Bar.cmake)` from `Foo.cmake` fails. This is
counter to what I would expect (e.g. how #include works in C).

Is this a bug or is this behavior expected? If it's expected, what is the
workaround? We have a lot of common cmake files which in turn include files
relative to each other and not the calling CMakeLists.txt.

Thank you,
Saad
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] INTERFACE libraries and -config.cmake files

[Saad Khattak]

Hi,

I have an interface library and I am not sure how I would get CMake to
generate the usual -config.cmake file for the library so that I can
then use "find_package" on the interface library from an external project.

I am adding (and installing) the library like this:

add_library(myLib INTERFACE)
target_include_directories(myLib INTERFACE
$
$
)

and then installing like this:

install(TARGETS myLib EXPORT myLib_targets INCLUDES DESTINATION include)
install(EXPORT myLib_targets DESTINATION "lib/cmake")
install(FILES ${MY_HEADERS} DESTINATION "include/")

Obviously, I am doing it wrong or missing some steps as I do not see the
myLib-config.cmake file anywhere in the install folder (or the build
directory for that matter) that is usually generated when using install
commands.

Ultimately, I would like to use the "find_package" command on the interface
library from another CMake project.

Thank you,
Saad
-- 

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] ExternalProject_Add

[Saad Khattak]

That is a good point. I found that a side effect of the superbuild is that
my project can be built independently and I can distribute it without the
superbuild parent project. Thanks Nicholas!

On Sun, Jan 22, 2017 at 10:33 PM Nicholas Braden <nicholas11bra...@gmail.com>
wrote:

> Yes, that is what I do in my superbuilds. Generally I make is such that my
> project could be built without the superbuild, and the superbuild is just a
> convenience.
>
> On Sat, Jan 21, 2017 at 12:17 PM, Saad Khattak <saadrus...@gmail.com>
> wrote:
>
> >> One possibility is the often mentioned superbuild
>
> That is a tempting and I started to go down that route - however, I ran
> into a problem where my project (which is now also built using
> ExternalProject_Add) does not have access to the CMake variables. Is the
> only solution to pass them through the CMAKE_ARGS variable in
> ExternalProject_Add?
>
> On Mon, Jan 9, 2017 at 12:07 AM Hendrik Sattler <p...@hendrik-sattler.de>
> wrote:
>
> One possibility is the often mentioned superbuild, another is not using
> find_library() but setting the variables with the library file paths
> manually (that's static info anyway).
>
>
> Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak <saadrus...@gmail.com
> >:
> >Hello,
> >
> >I have an external project glfw that I added to my project like this:
> >
> >==
> >include(ExternalProject)
> >ExternalProject_Add(glfw
> >  GIT_REPOSITORY "https://github.com/glfw/glfw.git;
> >  GIT_TAG "master"
> >
> >  SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw"
> >  CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF
> >-DGLFW_BUILD_EXAMPLES=OFF
> >-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/
> >-DCMAKE_DEBUG_POSTFIX=_d
> >
> >  TEST_COMMAND ""
> >  )
> >set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/")
> >set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/")
> >==
> >
> >Then I include it in my project like so:
> >
> >==
> >find_library(GLFW_LIB_D  glfw3_d ${GLFW_LIBRARY_DIR})
> >find_library(GLFW_LIBglfw3   ${GLFW_LIBRARY_DIR})
> >
> >include_directories(${GLFW_INCLUDE_DIR})
> >
> >add_executable(vk_test
> >  src/vulkan_test.cpp
> >  )
> >target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized
> >${GLFW_LIB})
> >add_dependencies(vk_test glfw)
> >==
> >
> >As you can see, I depend on the libraries compiled by the external
> >project
> >glfw. Unfortunately, when I first configure the project, CMake
> >complains
> >that it cannot find the libraries specified by ${GLFW_LIB_D} and
> >${GLFW_LIB} variables.
> >
> >Of course, this is because CMake did not begin cloning, configuring and
> >building the glfw project. That only happens AFTER my project has been
> >configured and starts building. This becomes a chicken and the egg
> >problem.
> >
> >Currently, my solution is to add dummy .lib files so that I can at
> >least
> >configure and generate my project. My question is, am I approaching
> >this
> >problem in the wrong way? If yes, what is the correct way to add a
> >dependency to an external project and have it clone/configure/build
> >BEFORE
> >the "find_library" call?
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>
> --
>
> 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] ExternalProject_Add

[Saad Khattak]

>> One possibility is the often mentioned superbuild

That is a tempting and I started to go down that route - however, I ran
into a problem where my project (which is now also built using
ExternalProject_Add) does not have access to the CMake variables. Is the
only solution to pass them through the CMAKE_ARGS variable in
ExternalProject_Add?

On Mon, Jan 9, 2017 at 12:07 AM Hendrik Sattler <p...@hendrik-sattler.de>
wrote:

One possibility is the often mentioned superbuild, another is not using
find_library() but setting the variables with the library file paths
manually (that's static info anyway).


Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak <saadrus...@gmail.com>:
>Hello,
>
>I have an external project glfw that I added to my project like this:
>
>==
>include(ExternalProject)
>ExternalProject_Add(glfw
>  GIT_REPOSITORY "https://github.com/glfw/glfw.git;
>  GIT_TAG "master"
>
>  SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw"
>  CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF
>-DGLFW_BUILD_EXAMPLES=OFF
>-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/
>-DCMAKE_DEBUG_POSTFIX=_d
>
>  TEST_COMMAND ""
>  )
>set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/")
>set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/")
>==
>
>Then I include it in my project like so:
>
>==
>find_library(GLFW_LIB_D  glfw3_d ${GLFW_LIBRARY_DIR})
>find_library(GLFW_LIBglfw3   ${GLFW_LIBRARY_DIR})
>
>include_directories(${GLFW_INCLUDE_DIR})
>
>add_executable(vk_test
>  src/vulkan_test.cpp
>  )
>target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized
>${GLFW_LIB})
>add_dependencies(vk_test glfw)
>==
>
>As you can see, I depend on the libraries compiled by the external
>project
>glfw. Unfortunately, when I first configure the project, CMake
>complains
>that it cannot find the libraries specified by ${GLFW_LIB_D} and
>${GLFW_LIB} variables.
>
>Of course, this is because CMake did not begin cloning, configuring and
>building the glfw project. That only happens AFTER my project has been
>configured and starts building. This becomes a chicken and the egg
>problem.
>
>Currently, my solution is to add dummy .lib files so that I can at
>least
>configure and generate my project. My question is, am I approaching
>this
>problem in the wrong way? If yes, what is the correct way to add a
>dependency to an external project and have it clone/configure/build
>BEFORE
>the "find_library" call?

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] Find Vulkan on 32 bit builds

[Saad Khattak]

That makes sense! Removing the variable from PATH does indeed fix the issue.

It is not a blocking issue for me.

I agree that this is a Vulkan packaging issue. However, since you are
looking for $ENV{VULKAN_SDK} in the find module and assuming it exists,
then it 'should' override the other path? I do see what you are saying in
that this now becomes a special case just because Vulkan SDK didn't package
the libs properly.

Thanks Matthäus and Andreas for your help!

On Tue, Jan 10, 2017 at 10:38 AM Matthäus G. Chajdas <cm...@anteru.net>
wrote:

Hi,

the problem here is that the Vulkan SDK helpfully adds
D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
PATH, and because the libraries for both architectures are named the
same, it will pick up the one from /Bin first (as the search order for
find_library is system paths first, and PATHS/HINTS variable second).

There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different architectures.)

For now the easiest workaround is to remove the path to the Vulkan SDK
from PATH; and I'll try to report this with the LunarG SDK and see how
far I get there. If this doesn't work out, I'll guess I'll have to
special-case the find_library call to ignore default paths on Windows &
32-bit only.

If this is a blocker for you, please file an issue and I'll fix it on
the CMake end before even starting the discussion with LunarG.

Cheers,
  Matthäus

Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
> Hello,
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>> Hello,
>>
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>> variables both point to the "Bin" folder for the Vulkan installation
>> instead of the "Bin32" folder.
>>
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>> mistake setting up. The message does indeed print confirming that my
>> pointer size is 4 and thus the current toolchain selected is 32 bit.
>>
>> What's perplexing is that when I do a MESSAGE(STATUS
>> ${Vulkan_LIBRARY}) the path is:
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib <http://1.0.37.0/Bin/vulkan-1.lib>
>>
>>
>> instead of
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>> <http://1.0.37.0/Bin32/vulkan-1.lib>
>>
>>
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
>> ignoring 32?
>>
> You should think the other way around: Why should cmake look in a
> special directory, when it finds a library with an appropriate name
> before this one?
> This decision should be in the corresponding FindVulkan.cmake, i.e. the
> corresponding find_library call should be constrained to
> ${VULKAN_DIR}/Bin32 in the 32bit case.
>>
>>
>
> Regards,
> Andreas
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] ExternalProject_Add

[Saad Khattak]

Hello,

I have an external project glfw that I added to my project like this:

==
include(ExternalProject)
ExternalProject_Add(glfw
  GIT_REPOSITORY "https://github.com/glfw/glfw.git;
  GIT_TAG "master"

  SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw"
  CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF
-DGLFW_BUILD_EXAMPLES=OFF
-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/
-DCMAKE_DEBUG_POSTFIX=_d

  TEST_COMMAND ""
  )
set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/")
set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/")
==

Then I include it in my project like so:

==
find_library(GLFW_LIB_D  glfw3_d ${GLFW_LIBRARY_DIR})
find_library(GLFW_LIBglfw3   ${GLFW_LIBRARY_DIR})

include_directories(${GLFW_INCLUDE_DIR})

add_executable(vk_test
  src/vulkan_test.cpp
  )
target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized ${GLFW_LIB})
add_dependencies(vk_test glfw)
==

As you can see, I depend on the libraries compiled by the external project
glfw. Unfortunately, when I first configure the project, CMake complains
that it cannot find the libraries specified by ${GLFW_LIB_D} and
${GLFW_LIB} variables.

Of course, this is because CMake did not begin cloning, configuring and
building the glfw project. That only happens AFTER my project has been
configured and starts building. This becomes a chicken and the egg problem.

Currently, my solution is to add dummy .lib files so that I can at least
configure and generate my project. My question is, am I approaching this
problem in the wrong way? If yes, what is the correct way to add a
dependency to an external project and have it clone/configure/build BEFORE
the "find_library" call?
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Find Vulkan on 32 bit builds

[Saad Khattak]

Hello,

When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio 2015
32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} variables
both point to the "Bin" folder for the Vulkan installation instead of the
"Bin32" folder.

I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS ...) on
the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a mistake
setting up. The message does indeed print confirming that my pointer size
is 4 and thus the current toolchain selected is 32 bit.

What's perplexing is that when I do a MESSAGE(STATUS ${Vulkan_LIBRARY}) the
path is:


D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib


instead of


D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib


It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
ignoring 32?
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] target_link_libraries is using relative path of library

[Saad Khattak]

Hello,

This is a very strange behavior I am encountering. I am using CMake 3.7.1
with Visual Studio 2015. I have the following as part of a CMakeLists file:

find_library(glfw_LIB_D  glfw3_d ${glfw_LIBRARIES})
find_library(glfw_LIBglfw3   ${glfw_LIBRARIES})

When I do "message(STATUS ${glfw_LIB_D})" I get the full absolute path.
However, when I add an executable that depends on the library:

add_executable(vk_test  src/vulkan_test.cpp  )
target_link_libraries(vk_test ${glfw_LIB_D})

CMake puts the relative path when I look at my project's project properties:

..\install\glfw\lib\glfw_d.lib

I also tried the following:

target_link_libraries(vk_test
"${CMAKE_SOURCE_DIR}/install/glfw/lib/glfw_d.lib")

And it's still a relative path. Because of this issue, my project will not
compile as Visual Studio is looking for the library in the incorrect folder.

I even set the following, thinking that somehow relative paths got set:

set(${CMAKE_USE_RELATIVE_PATHS} FALSE FORCE)

I still got the same relative path. What is going on?
-- 

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] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe

[Saad Khattak]

Hmm, maybe...? I'm not sure. Customize may be the wrong word. What I'm
asking in the question is similar to someone asking "how do I customize the
output path for the binaries in CMake?". My hope was it was going to be a
simple set variable for the utilities.

On Wed, Nov 9, 2016, 7:56 AM Jakob van Bethlehem <jsvanbethle...@gmail.com>
wrote:

> Hej,
>
> On Mon, Nov 7, 2016 at 4:48 PM, Saad Khattak <saadrus...@gmail.com> wrote:
>
> I am working on a plugin for Maya and it uses a customized version of Qt.
> Maya's SDK comes with everything to build Qt (headers, libraries and
> customized Qt tools such as moc.exe).
>
> I have the following issues:
>
> (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point
> CMake to pick Maya's version of moc.exe (and other Qt utils). The result is
> that I get linking errors since the moc did not run - which I expected.
>
> (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to
> get that version from Autodesk. So I downloaded the official Qt 5.6.1
> distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed.
> However, it is using the official Qt moc utilities and NOT Maya's
> customized moc. The headers and libraries being used were still from Maya's
> custom Qt.
>
> The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)"
> after installing the official version of Qt 5.6.1. However, I did NOT use
> the official Qt headers or libraries - instead, I used Maya's custom
> version of Qt 5.6.1.
>
> Using solution (2) I successfully compile and link my Qt enabled Maya
> plugin and load it in Maya. Things go smoothly until I either (a) unload
> the plugin or (b) delete any widget. I looked at the simplest code that is
> causing a heap corruption debug assertion:
>
> m_button = new QPushButton("MyButton"); // where m_button is a QPointer
> 
> delete m_button; // causes heap corruption debug assertion to fire
>
> A few other people have gone through similar issues but since they didn't
> use CMake, they simply ran Maya's moc utilities in a build step. I would
> like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version.
>
> Thanks.
>
>
> I see quite a lot usage of the word 'customized'. to me it sounds like
> you may be asking on the wrong user list?
>
> Sincerely,
> Jakob
>
>
>
-- 

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] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe

[Saad Khattak]

I did try that, unfortunately the Qt distribution that comes with Maya does
not have the find_package CMake modules for it's version of Qt. They didn't
exactly follow the folder structure of the official Qt release and they
don't have any of the CMake modules.

On Mon, Nov 7, 2016 at 10:54 AM Konstantin Tokarev <annu...@yandex.ru>
wrote:

>
>
> 07.11.2016, 18:49, "Saad Khattak" <saadrus...@gmail.com>:
> > I am working on a plugin for Maya and it uses a customized version of
> Qt. Maya's SDK comes with everything to build Qt (headers, libraries and
> customized Qt tools such as moc.exe).
> >
> > I have the following issues:
> >
> > (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point
> CMake to pick Maya's version of moc.exe (and other Qt utils). The result is
> that I get linking errors since the moc did not run - which I expected.
>
> You should be able to use custom Qt installation by setting
> CMAKE_PREFIX_PATH to your Qt prefix
>
> >
> > (2) Maya uses a modified version of Qt 5.6.1. There is currently no way
> to get that version from Autodesk. So I downloaded the official Qt 5.6.1
> distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed.
> However, it is using the official Qt moc utilities and NOT Maya's
> customized moc. The headers and libraries being used were still from Maya's
> custom Qt.
> >
> > The reason (2) worked is because I put "find_package(Qt5Widgets
> REQUIRED)" after installing the official version of Qt 5.6.1. However, I
> did NOT use the official Qt headers or libraries - instead, I used Maya's
> custom version of Qt 5.6.1.
> >
> > Using solution (2) I successfully compile and link my Qt enabled Maya
> plugin and load it in Maya. Things go smoothly until I either (a) unload
> the plugin or (b) delete any widget. I looked at the simplest code that is
> causing a heap corruption debug assertion:
> >
> > m_button = new QPushButton("MyButton"); // where m_button is a
> QPointer
> > delete m_button; // causes heap corruption debug assertion to fire
> >
> > A few other people have gone through similar issues but since they
> didn't use CMake, they simply ran Maya's moc utilities in a build step. I
> would like a solution where I can get CMAKE_AUTOMOC to run the custom Qt
> version.
> >
> > Thanks.
> >
> > ,--
> >
> > 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
>
>
> --
> Regards,
> Konstantin
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe

[Saad Khattak]

I am working on a plugin for Maya and it uses a customized version of Qt.
Maya's SDK comes with everything to build Qt (headers, libraries and
customized Qt tools such as moc.exe).

I have the following issues:

(1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point
CMake to pick Maya's version of moc.exe (and other Qt utils). The result is
that I get linking errors since the moc did not run - which I expected.

(2) Maya uses a modified version of Qt 5.6.1. There is currently no way to
get that version from Autodesk. So I downloaded the official Qt 5.6.1
distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed.
However, it is using the official Qt moc utilities and NOT Maya's
customized moc. The headers and libraries being used were still from Maya's
custom Qt.

The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)"
after installing the official version of Qt 5.6.1. However, I did NOT use
the official Qt headers or libraries - instead, I used Maya's custom
version of Qt 5.6.1.

Using solution (2) I successfully compile and link my Qt enabled Maya
plugin and load it in Maya. Things go smoothly until I either (a) unload
the plugin or (b) delete any widget. I looked at the simplest code that is
causing a heap corruption debug assertion:

m_button = new QPushButton("MyButton"); // where m_button is a QPointer

delete m_button; // causes heap corruption debug assertion to fire

A few other people have gone through similar issues but since they didn't
use CMake, they simply ran Maya's moc utilities in a build step. I would
like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version.

Thanks.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Linking with an external project also built with CMake

[Saad Khattak]

Hello,

I have a project *ExternalLib* that uses CMake to build its libraries. I
then have my own project (separate from the external library) that needs to
include ExternalLib's headers and link with its libraries. ExternalLib does
not have a find_package module.

Since ExternalLib is also built using CMake, is there no 'automatic' way to
have CMake figure out where the source files and library files are (since
CMake built them in the first place)? That is, I want to avoid writing a
find_package module for ExternalLib and since I have to build it using
CMake anyway, I was hoping there would be some way to automatically fill in
the correct paths for the libraries and source file directories in
MyProject which also uses CMake.

Thanks,
Saad
-- 

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] Extracting the configure and generate command

[Saad Khattak]

Thanks David. That at least makes it easier to write the scripts for
generating the projects. It would be great if the GUI has an option to show
the full CMake command.

On Sun Nov 02 2014 at 10:13:24 AM David Cole dlrd...@aol.com wrote:

 The Show My Changes menu item in the Tools menu gives you the -D command
 line options for the things you've touched in the cmake-gui program...

 HTH,
 David C.


 On Sat, Nov 1, 2014 at 12:16 PM, Saad Khattak saadrus...@gmail.com
 wrote:

 Once I have configured and generated a CMake project, is there a way to
 extract that into a command? So, let's say I have configured and generated
 a project using the CMake GUI. I am then able to extract
 (somehow) the full configure/generate command which looks like this:

 cmake -DOPTION_1=ON -DOPTION_2=OFF -G Visual Studio 10 1010 ../

 --

 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

[CMake] Extracting the configure and generate command

[Saad Khattak]

Once I have configured and generated a CMake project, is there a way to
extract that into a command? So, let's say I have configured and generated
a project using the CMake GUI. I am then able to extract
(somehow) the full configure/generate command which looks like this:

cmake -DOPTION_1=ON -DOPTION_2=OFF -G Visual Studio 10 1010 ../
-- 

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] Visual Studio 2013 warning MSB8028

[Saad Khattak]

For future reference:

The solution is to delete your build folder and generate the projects
again. Not sure what is changed by CMake in 3.0 but VS does not like it
unless the build folder is cleaned.


On Wed, Sep 3, 2014 at 6:09 PM, Saad Khattak saadrus...@gmail.com wrote:

 I have a solution with multiple projects including a CMake INSTALL project
 for installing the binaries. With CMake Version 3.0 I am receiving the
 following warning for each of my projects in the solution:
 warning MSB8028: The intermediate directory (myProject.dir\Debug\)
 contains files shared from another project (myProject.vcxproj). This can
 lead to incorrect clean and rebuild behavior.

 where myProject is replaced by the name of each of the projects in the
 solution.

 Previous cmake versions did not produce this warning with VS 2013. I am
 not sure how to resolve this warning as the recommended fix is to ensure
 that the Intermediate Directory variable for each project is unique. As
 far as I can tell, it is indeed unique.

 I could not find any topics with respect to this warning and CMake.
 Appreciate any help regarding this behaviour. If it is deemed a bug, then I
 will file a bug report.

 - Saad

-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Visual Studio 2013 warning MSB8028

[Saad Khattak]

I have a solution with multiple projects including a CMake INSTALL project
for installing the binaries. With CMake Version 3.0 I am receiving the
following warning for each of my projects in the solution:
warning MSB8028: The intermediate directory (myProject.dir\Debug\)
contains files shared from another project (myProject.vcxproj). This can
lead to incorrect clean and rebuild behavior.

where myProject is replaced by the name of each of the projects in the
solution.

Previous cmake versions did not produce this warning with VS 2013. I am not
sure how to resolve this warning as the recommended fix is to ensure that
the Intermediate Directory variable for each project is unique. As far as
I can tell, it is indeed unique.

I could not find any topics with respect to this warning and CMake.
Appreciate any help regarding this behaviour. If it is deemed a bug, then I
will file a bug report.

- Saad
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Get CMake to unset/remove a property in the Xcode project

[Saad Khattak]

Hello,

I would like CMake to not set the following property in the project at all:

ARCHS = $(ARCHS_STANDARD)

That is, I would like this property to not even show up in the
*pbxproj*file (which can be found inside the generated
*xcodeproj* bundle. In fact, I would like it to be removed by CMake. This
will allow Xcode to set it automatically. Otherwise, Xcode issues a warning
which must be fixed by either manually resetting all the properties of all
the targets OR allowing Xcode to fix it. The issue with allowing Xcode to
fix it is that not only is it an extra step, but it also changes other
unrelated properties which causes issues in our build.

Some more details

   - Using Xcode 5
   - Build is for iOS
   - The above mentioned property is controlled by (as far as I can tell)
   by CMAKE_OSX_ARCHITECTURE variable. I tried unsetting it, setting it to
   $(ARCHS_STANDARD) and various other options but none of them worked. Xcode
   always complained.

Thanks,
Saad
-- 

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Can CMake target different platforms for sub-projects?

[Saad Khattak]

Hi,

I currently have a CMake project with multiple sub-projects where
the sub-projects are libraries and executables. The project works on
windows and iOS (via XCode). One such sub-project is an executable that can
only be run on OSX and must be run after every build. This executable makes
a few changes to a couple of source files automatically (mainly for
tracking build related information which is automatically generated). To
ensure that it runs after every build, a custom target is built which
simply runs the previously mentioned exectuable.

Currently, for building iOS libraries and executables, I have the following
set in the root CMakeLists

set(CMAKE_OSX_SYSROOT iphoneos)

With the above line, in XCode I get the iOS targets. What I would like to
know is if CMake will be able to mix iOS and OSX targets? I am aware that I
create a new CMake project just for this, but then the executable will not
be automatically run each time the main project is built.

A little hierarchy to make things easier to understand

MainProject
  +- Library1 (compiles on iOS)
  +- Library2 (compiles on iOS)
  +- Executable1 (compiles on iOS but does not run on iOS - it must be run
automatically when MainProject is built)
  +- Executable2 (compiles/runs on iOS)
  +- ToolExecutable1 (runs the executable built by Executable1 - again,
Executable1 must be built for OSX only)

From the diagram, I would like XCode to build Library1, Library2 and
Exectuable2 for iOS but Executable1 should have OSX as the target platform.
As it stands, I cannot switch CMAKE_OSX_SYSROOT midway. Either all
sub-projects are targetted for iOS or all are targetted for OSX. I cannot
mix the two.

Mixing platform targets is possible when manually creating/manipulating
XCode projects. So I am wondering whether it is possible to get CMake to
build MainProject such that I can control the target for each library and
executable.

Thanks,
Saad
--

Powered by www.kitware.com

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

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

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

[CMake] Trigger a build with CMake

[Saad Khattak]

Hi,

Now that I have a project up and running with CMake generated native
project files, can I trigger a build with CMake as well? That is, a
cross-platform way to trigger a build on the project without the need for
me to call 'msbuild' on windows for example?

- Saad
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Trigger a build with CMake

[Saad Khattak]

Perfect. Thanks Leif!


On Tue, Apr 16, 2013 at 11:23 AM, Leif Walsh leif.wa...@gmail.com wrote:

 cmake --build /path/to/build/dir [--target target name]

 I usually go to the build directory and type `cmake --build .`  You can
 pass extra options to the underlying build system by adding `--`
 afterwards, so if you are using, for example, the Makefile generator, you
 can build in parallel with `cmake --build . -- -j5`


 On Tue, Apr 16, 2013 at 11:18 AM, Saad Khattak saadrus...@gmail.comwrote:

 Hi,

 Now that I have a project up and running with CMake generated native
 project files, can I trigger a build with CMake as well? That is, a
 cross-platform way to trigger a build on the project without the need for
 me to call 'msbuild' on windows for example?

 - Saad

 --

 Powered by www.kitware.com

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

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

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




 --
 Cheers,
 Leif

--

Powered by www.kitware.com

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

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

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

Re: [CMake] Installing and Exporting for multiple configurations

[Saad Khattak]

Thanks for the solution. I will try this but perhaps you are right and I
should instead go with different builds for each configuration.


On Thu, Apr 4, 2013 at 3:54 AM, J Decker d3c...@gmail.com wrote:

 there is a variable that can be used...

 if( SUPPORTS_PARALLEL_BUILD_TYPE )
 INSTALL(   lib/${CMAKE_INSTALL_CONFIG_TYPE} )
 would install into

 # used as install_mode_dest( target_names )
 macro( install_mode_dest )
 install( TARGETS ${ARGV}
  RUNTIME DESTINATION bin/\${CMAKE_INSTALL_CONFIG_NAME} LIBRARY DESTINATION
 bin/\${CMAKE_INSTALL_CONFIG_NAME} ARCHIVE DESTINATION
 lib/\${CMAKE_INSTALL_CONFIG_NAME} ) endmacro( install_mode_dest )

 because it's in a macro, had to escape the $ until the macro is called (or
 for some point)...



 but; from an automaton standpoint, might consider just buildling one mode
 at a time, and using a different build for other mdoes...
 .../build/vs10/debug/   ../build/vs10/release/   sorta... and just target
 bin lib  etc. it's just simpler


 On Wed, Apr 3, 2013 at 7:06 PM, Saad Khattak saadrus...@gmail.com wrote:

 Hi,

 I am trying my best to understand CMake's install and export commands so
 that separate projects are able to find libraries easily.

 I am having a tremendously hard time understand what CMake is doing.
 After 'add_library()' where the library is called 'myLib' I called the
 following:

 install(TARGETS myLib
 DESTINATION ${PROJECT_BINARY_DIR}/lib/
 EXPORT repoA-targets
 )

 Then in the top-level CMakeLists I added:

 install(EXPORT repoA-targets
 DESTINATION ${PROJECT_BINARY_DIR}/lib/
 )

 When I build my project (in Visual Studio on Windows) it dumps libraries
 from all configurations in the same folder which is:

 ${PROJECT_BINARY_DIR}/lib

 and over-writes the previous library file from a different configuration
 because they are named the same. At the same time, it actually generates a
 repoA-targets-debug.cmake file, but points to the now over-written library
 file which is of a different configuration. Why would CMake do this? Makes
 no sense.

 That is only part of the problem. Now in RepoB, I want to import the
 libraries. CMake documentation here:
 http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets

 states that I can do something like this:
 include(${PATH_OF_REPO_A_BUILD}/repoA-targets.cmake)

 target_link_libraries(repoBExecutable myLib)

 and CMake should be able to find myLib and correctly add it to the
 linker's properties. This does not appear to be working. CMake simply adds
 myLib to the linker instead of ${FULL_PATH_OF_MYLIB}/myLib.

 I hope that somebody can explain what I am doing wrong and how to install
 and export libraries properly with CMake and then successfully import and
 use them in another project.

 Thank you,
 Saad





 --

 Powered by www.kitware.com

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

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

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



--

Powered by www.kitware.com

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

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

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

Re: [CMake] Explanation of the CMake INSTALL and EXPORT Commands

[Saad Khattak]

Thanks for the very valuable info Matthew.

If Project A is installed (to a standard location), then it is available
 system wide, yes. However you should still use find_package(A) rather
 than relying on e.g. target_link_libraries(B A)


I tried to use find_package(A) but CMake would display a warning:

By not providing FindA.cmake in CMAKE_MODULE_PATH this project has asked
CMake to find a package configuration file provided by A, but CMake did
not find one

Obviously I am not installing it correctly. When do I know my
libraries/package is installed correctly (apart from the fact that
find_package will be able to find it)? Is there a specific folder that I
can check to make sure the installation took place properly and that CMake
will be able to find the libraries/packages? Am I correct in assuming that
if I do the install correctly, I do not have to write a package
configuration file and that it will be provided by CMake automatically?

Any tips that first time users like me should watch out for when installing
their libraries would be great.

Generally speaking, you should either have two separate builds of A in
 32- and 64-bit mode that can be installed in parallel


I will follow your advice here and split up the configurations.

Thank you,
Saad

Message: 2
 Date: Wed, 03 Apr 2013 17:12:43 -0400
 From: Matthew Woehlke matthew.woeh...@kitware.com
 Subject: Re: [CMake] Explanation of the CMake INSTALL and EXPORT
 Commands
 To: cmake@cmake.org
 Message-ID: kji607$pe$1...@ger.gmane.org
 Content-Type: text/plain; charset=UTF-8; format=flowed
 On 2013-04-03 16:16, Saad Khattak wrote:
  I am having a hard time understanding some commands in CMake which by the
  looks of it are vital for proper project deployment. One of the commands
 is
  INSTALL and the other is EXPORT.
 There are two forms of EXPORT, and I am not certain which one you are
 referring to. There is the command EXPORT, and there is the EXPORT named
 argument to the INSTALL command. They are similar in that they both deal
 with generating target export files, but the command version is used to
 generate such for build trees, while the named argument version applies
 to install trees.
 If you never use your software downstream from a build directory, you
 can safely ignore the command version.
  1) Why do I need to install my library/executable? When I build my
  libraries and they are put in their library output paths, what is the
 point
  of INSTALL?
 INSTALL is used to implement 'make install' (or equivalent), and also
 packaging. If you are only ever using your software from a source build,
 you can probably ignore it. If you ever want to deploy your software,
 however, I would strongly encourage having an install process.
 Installing makes a software package generally available to users of the
 system, by installing its components into a well-known prefix (e.g.
 /usr, /usr/local, /opt/MySoft). It is often much more convenient to use
 an installed software package rather than stuff in a build directory, as
 installed binaries tend to be in e.g. PATH, whereas build directories
 may not be readable by all users.
 Please don't teach your build to write its build objects directly into
 e.g. /usr/local/bin :-).
  2) Once I do install targets and/or programs, are they available to other
  projects that are not in the same CMakeLists build?
 Yes. They are available just from build directories also, but you will
 need to manually tell CMake where to find build directories. (Per above,
 installed packages can be found automatically if they are installed to
 standard (well known) locations... keeping in mind that you can choose
 to install to any location you like, e.g. in your home directory.)
 (If you are using exported targets - and you should - then you will need
 to use the EXPORT command to create a build-directory exported targets
 file. Getting this right is a little more complicated than install
 exports, but saves needing to install the package every time your
 downstream needs an updated version.)
  3) Suppose I have 2 completely separate projects (i.e. they have
 completely
  separate CMakeLists that are not 'talking' to each other) - Project A
  builds some libraries which Project B now needs to use. Does Project A
  'install' the libraries and are now those libraries are available system
  wide?
 If Project A is installed (to a standard location), then it is available
 system wide, yes. However you should still use find_package(A) rather
 than relying on e.g. target_link_libraries(B A) so that your build will
 work for users that do not have A in a standard location.
 If A is built by CMake, your install should generate exports so that
 users of A do not need a find module. (Also, then you *can* - and should
 - do target_link_libraries(B A), because 'A' will be an imported target,
 i.e. will 'look like' it was build as part of B.)
  4) Project A can build 32 bit and 64 bit libraries. How does INSTALL (or
  EXPORT? Like I said

Re: [CMake] CMake extracting tar via execute_process does not allow extraction in subdirectories

[Saad Khattak]

I am using version 2.8.8. I am running Windows 7 and do not use cygwin,
only native CMake.

cd Z:/engine/src/mySDK
 cmake -E tar xvf ../mySDK.tar.gz


That works. The tar is successfully extracted to the mySDK folder. As
before, it appears it can only extract to the current directory.

- Saad


On Wed, Apr 3, 2013 at 2:08 AM, Eric Noulard eric.noul...@gmail.com wrote:




 2013/4/3 Saad Khattak saadrus...@gmail.com

 That prints the directory in the console:

 Z:/engine/src/mySDK

 But did not extract to it. Note that mySDK exists, and the tar is in the
 'src' folder and I am able to extract in the 'src' folder properly.


 Ok this is weird.

 Which version of CMake are you using? (try cmake --version)
 You seem to be running on a Windows host,
 do you use native CMake or some combination of cygwin and cygwin cmake?

 Which cmake generator are you using? (Visual Studio xxx, MinGW, ...)

 Is cmake able to untar manually i.e. could you try that:

 cd Z:/engine/src/mySDK
 cmake -E tar xvf ../mySDK.tar.gz




--

Powered by www.kitware.com

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

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

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

Re: [CMake] How do I search for personal libraries?

[Saad Khattak]

Thanks Michael. The link is very helpful (although very hard to digest
[probably because I am new to CMake] - I have gone over it multiple times
now and don't fully understand everything). I will experiment with those
commands in my projects.

- Saad


On Wed, Apr 3, 2013 at 2:52 AM, Michael Wild them...@gmail.com wrote:

 You should find this interesting:
 http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file

 In short:
 * In project A create a AConfig.cmake file and export your targets
 * In project B call find_package(A REQUIRED)

 HTH

 Michael



  On Wed, Apr 3, 2013 at 7:44 AM, Saad Khattak saadrus...@gmail.comwrote:

  Hi,

 Suppose I have two personal repositories: A and B. Repository B has a
 dependency on repository A i.e. repository A builds multiple libraries and
 repository B builds multiple libraries and executables. I can build 32-bit
 and 64-bit libraries/executables for both by having a 'build' and
 'buildx64' projects generated by CMake. The libraries and executables are
 put in the default folders (e.g. repoA/build/src/libraryName/Debug and
 repoA/buildx64/src/library/Debug).

 Repo B's executables depend on repo A's libraries and libraries in B.
 Linking with libraries within B is straightforward as CMake is able to
 figure out the necessary paths for the libraries B is building which B's
 executables depend on.

 Repo B also depends on Repo A's libraries and all executables in B have
 to search for them. How do I go about this? Currently I am searching for
 each library by specifying its path:

 # I have a CACHE variable for the path to Repo A's build folder that the
 user must provide
 target_link_libraries(myProject
 repoAPath/build/src/LibName/${CMAKE_CFG_INTDIR})

 which feels like a very wrong way to go about linking with other
 libraries considering CMake is supposed to make the finding libraries part
 easier. I would appreciate clarification of the workflow in this case.

 Thanks,
 Saad



 --

 Powered by www.kitware.com

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

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

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



--

Powered by www.kitware.com

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

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

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

[CMake] Explanation of the CMake INSTALL and EXPORT Commands

[Saad Khattak]

Hi,

I am having a hard time understanding some commands in CMake which by the
looks of it are vital for proper project deployment. One of the commands is
INSTALL and the other is EXPORT.

I have read the following page many times:
http://www.cmake.org/Wiki/CMake:Install_Commands. The article states CMake
has an elaborate install process that simplifies installation of programs,
libraries, and other files. but does not go into any further detail on how
it simplifies the process.

But it seems like the article is meant for CMake veterans and not
newcomers. It simply explains the usage of the command but not what it
does, its end result and its usage. I have the following questions:

1) Why do I need to install my library/executable? When I build my
libraries and they are put in their library output paths, what is the point
of INSTALL?
2) Once I do install targets and/or programs, are they available to other
projects that are not in the same CMakeLists build?
3) Suppose I have 2 completely separate projects (i.e. they have completely
separate CMakeLists that are not 'talking' to each other) - Project A
builds some libraries which Project B now needs to use. Does Project A
'install' the libraries and are now those libraries are available system
wide? Or do I still have to give the path of Project A to Project B for
linking? Perhaps I am not making any sense whatsoever. I apologize, but I
have spent the past week trying to wrap my head around INSTALL and EXPORT
but they make no sense to me because their end-usage is not described
anywhere.
4) Project A can build 32 bit and 64 bit libraries. How does INSTALL (or
EXPORT? Like I said earlier, I am very confused here...) know which library
it is 'installing'? And then how does Project B 32 bit know to link with
Project A 32 bit libraries and same with 64-bit?

Thank you for any help,
Saad
--

Powered by www.kitware.com

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

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

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

[CMake] Installing and Exporting for multiple configurations

[Saad Khattak]

Hi,

I am trying my best to understand CMake's install and export commands so
that separate projects are able to find libraries easily.

I am having a tremendously hard time understand what CMake is doing. After
'add_library()' where the library is called 'myLib' I called the following:

install(TARGETS myLib
DESTINATION ${PROJECT_BINARY_DIR}/lib/
EXPORT repoA-targets
)

Then in the top-level CMakeLists I added:

install(EXPORT repoA-targets
DESTINATION ${PROJECT_BINARY_DIR}/lib/
)

When I build my project (in Visual Studio on Windows) it dumps libraries
from all configurations in the same folder which is:

${PROJECT_BINARY_DIR}/lib

and over-writes the previous library file from a different configuration
because they are named the same. At the same time, it actually generates a
repoA-targets-debug.cmake file, but points to the now over-written library
file which is of a different configuration. Why would CMake do this? Makes
no sense.

That is only part of the problem. Now in RepoB, I want to import the
libraries. CMake documentation here:
http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets

states that I can do something like this:
include(${PATH_OF_REPO_A_BUILD}/repoA-targets.cmake)

target_link_libraries(repoBExecutable myLib)

and CMake should be able to find myLib and correctly add it to the linker's
properties. This does not appear to be working. CMake simply adds myLib
to the linker instead of ${FULL_PATH_OF_MYLIB}/myLib.

I hope that somebody can explain what I am doing wrong and how to install
and export libraries properly with CMake and then successfully import and
use them in another project.

Thank you,
Saad
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake extracting tar via execute_process does not allow extraction in subdirectories

[Saad Khattak]

Hi Eric,

I created the folder manually, but it still did not extract to that folder.
It appears to only be able to extract to the current folder. It 'is' able
to create folders that are in the tar as expected.

- Saad


On Tue, Apr 2, 2013 at 1:50 AM, Eric Noulard eric.noul...@gmail.com wrote:




 2013/4/2 Saad Khattak saadrus...@gmail.com

 Hi,

 If I have the following command:

   execute_process(
 COMMAND ${CMAKE_COMMAND} -E tar xzf mySDK.tar.gz
 WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 )

 the extraction works and extracts the tar in the current directory. But
 this:

   execute_process(
 COMMAND ${CMAKE_COMMAND} -E tar xzf mySDK.tar.gz
 WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/someSubdirectory
 )

 fails to extract into 'someDirectory' (even if it already exists -
 although it 'should' create the directory for me).


 No it shouldn't.


  Am I misunderstanding some commands?


 Yes I think you misunderstand WORKING_DIRECTORY argument of
 execute_process command.
 The WORKING_DIRECTORY MUST exists beforehand and it is NOT the job of
 execute_process
 to create it.

 A WORKING_DIRECTORY is **always** supposed to exists when used
 by the cmake command providing this option like:
 add_custom_command, add_test or execute_process.

 If you need to create a directory you can cmake -E make_directory
 or file(MAKE_DIRECTORY ...)

 That said cmake -E tar xzf mySDK.tar.gz will create any directory found
 in the archive as expected.
 working directory for untar and [possibly] top-level directory created
 nby untar are not the same.


 --
 Erk
 Le gouvernement représentatif n'est pas la démocratie --
 http://www.le-message.org

--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake extracting tar via execute_process does not allow extraction in subdirectories

[Saad Khattak]

That prints the directory in the console:

Z:/engine/src/mySDK

But did not extract to it. Note that mySDK exists, and the tar is in the
'src' folder and I am able to extract in the 'src' folder properly.

- Saad

On Tue, Apr 2, 2013 at 1:58 AM, Eric Noulard eric.noul...@gmail.com wrote:

 COMMAND ${CMAKE_COMMAND} -E echo WD  = ${CMAKE_CURRENT_SOURCE_DIR}/
 someSubdirectory

--

Powered by www.kitware.com

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

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

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

[CMake] How do I search for personal libraries?

[Saad Khattak]

Hi,

Suppose I have two personal repositories: A and B. Repository B has a
dependency on repository A i.e. repository A builds multiple libraries and
repository B builds multiple libraries and executables. I can build 32-bit
and 64-bit libraries/executables for both by having a 'build' and
'buildx64' projects generated by CMake. The libraries and executables are
put in the default folders (e.g. repoA/build/src/libraryName/Debug and
repoA/buildx64/src/library/Debug).

Repo B's executables depend on repo A's libraries and libraries in B.
Linking with libraries within B is straightforward as CMake is able to
figure out the necessary paths for the libraries B is building which B's
executables depend on.

Repo B also depends on Repo A's libraries and all executables in B have to
search for them. How do I go about this? Currently I am searching for each
library by specifying its path:

# I have a CACHE variable for the path to Repo A's build folder that the
user must provide
target_link_libraries(myProject
repoAPath/build/src/LibName/${CMAKE_CFG_INTDIR})

which feels like a very wrong way to go about linking with other libraries
considering CMake is supposed to make the finding libraries part easier. I
would appreciate clarification of the workflow in this case.

Thanks,
Saad
--

Powered by www.kitware.com

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

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

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

[CMake] Multiple platform targets (iOS and OSX)

[Saad Khattak]

Hi,

I am using CMake to build a solution consisting of several projects (using
Visual Studio lingo here) where some of them are libraries, some
executables. Some executables can run only on the OS (i.e. OSX and Windows)
and will not work correctly on iOS.

We have one such executable that manipulates a version file in the
repository each time there is a build. This executable must be part of the
same XCode project, otherwise it will not run. I am aware that I can
separate this out into a new project and have CMake run the file but that
requires more maintainance (as the user now has to not only create/build
the main project via CMake but also the above mentioned project).

In CMake for iOS builds, I set CMAKE_OSX_SYSROOT in the root CMakeLists.txt
file to iphoneos. It turns out I cannot change it again (for the above
mentioned project). XCode is capable of allowing targets to be a mixture of
iOS and OSX. Is that possible with CMake?

Thanks,
Saad
--

Powered by www.kitware.com

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

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

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

[CMake] iOS library out path

[Saad Khattak]

Hi,

If I set the LIBRARY_OUTPUT_PATH for iOS projects like this:

someDir/lib/

then the final directory for the library outputs is:

someDir/lib/debug

assuming I am building the debug configuration. But if I now specify the
directories for linking:

link_directories(someDir/lib)

in Xcode the path becomes:

someDir/lib/debug-iphonesimulator

If I do not set LIBRARY_OUTPUT_PATH then CMake correct sets the output
directory to

build/src/debug-iphonesimulator

So it appears that CMake does not add -iphonesimulator (or doesn't let
Xcode add it - not sure as my knowledge of CMake is limited) for custom
library output paths.

Is this a bug? If not, what am I doing wrong?

Thanks,
Saad
--

Powered by www.kitware.com

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

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

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

[CMake] CMake extracting tar via execute_process does not allow extraction in subdirectories

[Saad Khattak]

Hi,

If I have the following command:

  execute_process(
COMMAND ${CMAKE_COMMAND} -E tar xzf mySDK.tar.gz
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)

the extraction works and extracts the tar in the current directory. But
this:

  execute_process(
COMMAND ${CMAKE_COMMAND} -E tar xzf mySDK.tar.gz
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/someSubdirectory
)

fails to extract into 'someDirectory' (even if it already exists - although
it 'should' create the directory for me).

Am I misunderstanding some commands?

Thanks,
Saad
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake extracting tar via execute_process does not allow extraction in subdirectories

[Saad Khattak]

As far as I can tell, it does not extract at all.

The return code when it is able to extract is 0, when it is not able to
extract, it is 1

- Saad


On Mon, Apr 1, 2013 at 6:12 PM, David Cole dlrd...@aol.com wrote:

 Where does the extraction end up?

 Or does it fail regardless of the WORKING_DIRECTORY argument?

 Use :

execute_process(... RESULT_VARIABLE rv)
message(rv='${rv}')

 to see what the return value of CMake is.

 Is there an error message when trying to extract the tar file?




 -Original Message-
 From: Saad Khattak saadrus...@gmail.com
 To: CMake Mailing List cmake@cmake.org
 Sent: Mon, Apr 1, 2013 6:06 pm
 Subject: [CMake] CMake extracting tar via execute_process does not allow
 extraction in subdirectories


 Hi,


 If I have the following command:



   execute_process(
 COMMAND ${CMAKE_COMMAND} -E tar xzf mySDK.tar.gz
 WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 )


 the extraction works and extracts the tar in the current directory. But
 this:



   execute_process(
 COMMAND ${CMAKE_COMMAND} -E tar xzf mySDK.tar.gz
 WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/**someSubdirectory
 )


 fails to extract into 'someDirectory' (even if it already exists -
 although it 'should' create the directory for me).


 Am I misunderstanding some commands?


 Thanks,
 Saad



 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

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

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

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