Re: [CMake] Building third party libraries along with normal targets

are the same on all our platforms (windows, linux, mac). This is an issue only if you're not using git on Windows so adding git-bash to the workflow would be an extra hassle. On Thu, Mar 30, 2017 at 3:45 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote: > On Thu, Mar 30, 2017 at 3:42

Re: [CMake] Building third party libraries along with normal targets

An alternative to the CMake superbuild: leave your actual project intact. Simply create a separate shell script which builds all the dependencies (by running cmake commands). Or, if you do like the ExternalProject stuff, create a superbuild which builds only the dependencies. Tamas On Thu, Mar

Re: [CMake] Interfacing cmake with 3rdparties package manager, and exclude them from ninja clean

Maybe executing your script in configure time (execute_process)? On Fri, Jan 20, 2017 at 4:36 PM, wrote: > Hello, > > I'm working on a project where some of our libs depend on custom build of > some external libraries. > Those external libraries are managed through a

Re: [CMake] Creating dependencies between static imported targets.

com> wrote: > That would have been ideal, however it seems to me not many packages ship > with cmake config module files.. > > On Sun, Aug 21, 2016 at 9:52 PM, Tamás Kenéz <tamas.ke...@gmail.com> > wrote: > >> Defining the dependencies of an imported target shou

Re: [CMake] Creating dependencies between static imported targets.

Defining the dependencies of an imported target should be done by the target's config-module (or a file invoked by the config-module, usually generated with install(EXPORT...) ) On Sun, Aug 21, 2016 at 4:23 PM, Yaron Cohen-Tal wrote: > Thanx! > > I think it would b nice

Re: [CMake] Private dependencies of static libraries exported as targets

Ivan, > But, if library `foo` is built as static, then its clients suddenly > become required to link to `bar` as well, and this information is not > recorded anywhere! I changed the cmake_minimum_required version in your projects from 2.8 to 3.0 which fixed the issue. (I tried it with cmake

Re: [CMake] Why is target installation done in 2 separate steps?

I believe you can install and assign multiple targets in different subdirectories to a single export: /foo/CMakeLists.txt: install(TARGETS foo EXPORT mylib-targets ...) /bar/CMakeLists.txt install(TARGETS bar EXPORT mylib-targets ...) /CMakeLists.txt install(EXPORT mylib-targets

Re: [CMake] Setting properties from within a function

Okay, I see. The problem is that the ${DEF} is quoted so it won't fall apart into separate arguments. Tamás On Wed, Apr 13, 2016 at 4:54 AM, Michael Surette <mjsure...@gmail.com> wrote: > On 2016-04-12 06:57 PM, Tamás Kenéz wrote: > >> I don't get how come the m

Re: [CMake] Setting properties from within a function

I don't get how come the macro works because `target_compile_definitions` needs at least 3 parameters. The second one must be PRIVATE|PUBLIC|INTERFACE. Tamas On Tue, Apr 12, 2016 at 7:43 AM, Michael Surette wrote: > I would like to use set target properties from within a

Re: [cmake-developers] Emit link commands to file?

For the "Unix Makefiles" generator, there's already a link.txt in /CMakeFiles/.dir Tamas -- 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

Re: [cmake-developers] -isystem suppresses warnings from user header

Thanks! I missed that property. Tamas On Thu, Apr 7, 2016 at 4:13 PM, Brad King <brad.k...@kitware.com> wrote: > On 04/07/2016 10:03 AM, Tamás Kenéz wrote: > > CMake uses "-isystem" on the compiler command line for the > > INTERFACE_INCLUDE_DIRECTORIES of impor

[cmake-developers] -isystem suppresses warnings from user header

Environment: CMake 3.5, linux, g++ CMake uses "-isystem" on the compiler command line for the INTERFACE_INCLUDE_DIRECTORIES of imported libraries. Unfortunately including a header via an isystem path suppresses warnings emitted from the header, such as warnings caused by expansions of macros

Re: [CMake] Building a tool immediately so it can be used later in same CMake run

for mycomp. - You could "install(TARGETS mycomp DESTINATION bin)" in your EARLY_BUILD then later use "find_program(mycomp_EXECUTABLE mycomp ...) later to save guessing the executable's name. Tamas On Fri, Apr 1, 2016 at 9:25 PM, Tamás Kenéz <tamas.ke...@gmail.com> wrote: &g

Re: [CMake] Building a tool immediately so it can be used later in same CMake run

Craig, My cmake-based build system in my company's CI framework works exactly that way: there's a generic cmake script[1] (invoked with cmake -P) that reads in a file which contains repo-urls and build parameters for 50+ projects and builds them for 3 platforms (linux, win, mac) 5 compilers

Re: [cmake-developers] CMake aliasing system

ete nonsense! I agree and that's why I think cmake ini files is a good idea. Tamas On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov <ruslan_bara...@yahoo.com> wrote: > On 15-Mar-16 02:42, Tamás Kenéz wrote: > > I also doubt this belongs to upstream. But you could write a sin

Re: [cmake-developers] CMake aliasing system

I also doubt this belongs to upstream. But you could write a single, generic script which forwards its arguments to cmake and also accepts and processes the additional parameters along the way. I don't think we'd lose anything: cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS This is

Re: [CMake] Help for a cmake newbie

Vadtec, > My main problem is getting cmake to use only my locally installed/compiled copies of the libs. I need those libs to live along side the binaries, and using the versions I compile is important. I'll answer the question of finding the libraries and not the building problem. We (in my

Re: [CMake] seeking advice for building and testing variants

You can build the N variants from the same CMakeLists.txt in a single directory. On Wed, Jan 27, 2016 at 3:24 PM, Vania Joloboff wrote: > Hi > > We have a library that we want to build with N different variants > in the compile flags for the same source code. > Then in

Re: [CMake] PROPERTY for list of link libraries

I think you need something like CMakeExpandImportedTargets.cmake ( https://cmake.org/cmake/help/latest/module/CMakeExpandImportedTargets.html). But that module has been deprecated for a while and does not support some newer CMake features. Instead, feel free to try out my fork:

Re: [cmake-developers] CMake Daemon blog

That's great and really does open a new world for IDEs! Tamas On Sun, Jan 24, 2016 at 11:44 PM, Stephen Kelly wrote: > Hi, > > I just made a blog and video about the advanced features and possibilities > that a daemon mode for CMake can bring: > >

Re: [CMake] Shared library for a executable

Gonzalo, Ray, I think your approaches are not in accordance with some CMake best practices (or at least what I believe they are). Please take a look at Ray's example after a heavy refactor: https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe These are the things I changed: - In your

Re: [CMake] exclude a dependency from export

The PRIVATE keyword for `target_link_libraries` has no effect on the visibility of the names. If `A` is static and `B` is shared then I think target_link_libraries(B PRIVATE A) install(TARGETS B ...) should work for you. Of course, if B static then it won't work. For that case they've

[cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug

It seems that the names of the PRIVATE dependencies of a library are not affected by either the NAMESPACE option or the EXPORT_NAME property. A minimal example: add_library(one STATIC ...) add_library(two STATIC ...) target_link_libraries(two PRIVATE one) install(TARGETS one two

Re: [cmake-developers] CMake alternative language

Looking at what kind of mistakes the newcomers make, I think it's rather the global workflow and the roles of certain key variables/properties they don't get. At first their problem is not that they can't make a for-loop or increment a variable. It's that they don't understand how the build and

Re: [cmake-developers] Using CMake as a library from Python

Charles, I'd like to comment on a minor issue: CMakeLists.txt files don't specify user-specific data like source and build dirs (for a reason) yet your POC listfile contains this line: cmake.init("Ninja", "/media/dev/src/cmaketest", "/media/dev/build/cmaketest") which sets the source and

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

Jake, I've read the older edition. Yes, I also think it could be written better and most of the information is available online. Still, it provided me with authorative information, concentrated into a single book, (as opposed to be scattered over the internet). It really helped me to lay down the

Re: [CMake] Idea: generic task-driven make-like targets with CMake

-line centered development, even when working with VS IDE. On Wed, Dec 9, 2015 at 6:43 PM, Kevin Wojniak <kain...@kainjow.com> wrote: > Looks interesting Tamas! Too bad shell scripts don’t work natively on > Windows :) > > Kevin > > > > > On 8 Dec 2015, at 16:59, Tam

Re: [CMake] Idea: generic task-driven make-like targets with CMake

Kevin, I have a shell script for such tasks, see https://gist.github.com/tamaskenez/d4509f240f4224eb9853. Feel free to use it if that's what you need. It extends the `cmake` command by executing multiple, related `cmake` calls with one command. See docs in gist. Your 'make release' example looks

Re: [CMake] 3.4.1 installer overwrites Windows PATH system var

about recovering the path see http://superuser.com/questions/523688/deleted-path-environment-variable-how-to-restore On Thursday, December 3, 2015, Brad King wrote: > On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote: > > Installing CMake on Windows (7, 64-bit)

Re: [CMake] actually using cmake alternative to convenience libraries

cache variables. On Fri, Nov 20, 2015 at 3:18 PM, Mark Stijnman <mark.stijn...@gmail.com> wrote: > On Thu, Nov 19, 2015 at 11:04 PM, Tamás Kenéz <tamas.ke...@gmail.com> > wrote: > >> > set(foobarSRCS foo.c bar.c) >> > set(foobarLIBS ${externalLibFound}) >>

Re: [CMake] actually using cmake alternative to convenience libraries

> set(foobarSRCS foo.c bar.c) > set(foobarLIBS ${externalLibFound}) > > which is what the FAQ entry seems to suggest. However, this variable is not visible to goo.c. Okay, so as an alternative, I can do this: > > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. In similar cases I create CACHE

Re: [CMake] Creating relocatable export files

You need to manually write your config module which takes care of the dependencies. Of course you will still use the generated exports, too. For now let's say `ome-common` has one dependency: `omedep` and its config-module, `omedep-config.cmake` creates the imported lib target `omedep::omedep`.

Re: [CMake] How to figure out the "type" of an imported library

There's a TYPE property which should contain what you need: https://cmake.org/cmake/help/latest/prop_tgt/TYPE.html On Thu, Oct 29, 2015 at 4:53 PM, Attila Krasznahorkay < attila.krasznahor...@gmail.com> wrote: > Dear All, > > In my code I'm trying to do something slightly tricky. I include

Re: [CMake] Asking CMake to setup compiler for c++11

this is what I do: if(NOT MSVC) if(CMAKE_VERSION VERSION_LESS 3.1) set(CMAKE_CXX_FLAGS "-std=c++11 ${CMAKE_CXX_FLAGS}") else() if(NOT DEFINED CMAKE_CXX_STANDARD OR CMAKE_CXX_STANDARD STREQUAL "98") set(CMAKE_CXX_STANDARD 11) endif()

Re: [CMake] Release and Debug build linking

CMake supports multi-config generators such as Visual Studio and Xcode for a long time. There are two flavors of config-modules (and find-modules), the legacy one which creates variables like MY_PACKAGE_LIBRARIES and the install-export kind which creates IMPORTED targets. Both kinds of modules

Re: [cmake-developers] script mode current directory

MMAND} --build) run_cmake_command(build-no-cache -- 2.2.1 On Fri, Oct 2, 2015 at 2:45 PM, Brad King <brad.k...@kitware.com> wrote: > On 10/02/2015 08:00 AM, J Decker wrote: > > On Fri, Oct 2, 2015 at 4:40 AM, Tamás Kenéz wrote: > >> In script mode it seems that all t

[cmake-developers] script mode current directory

In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR variables are set to the current working directory. Is this something we can rely on and it could be added to the documentation? Tamas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ

[CMake] ExternalProject: pass variable which contains a list

Hi, I tried to pass a variable to an ExternalProjects config step which contains a list: ExternalProject_Add(... CMAKE_ARGS "-DVAR=contains\;list" ...) I tried various number of backslashes but none of them worked. I'd be interested in a workaround if there's one. Tamas -- Powered by

Re: [CMake] ExternalProject: pass variable which contains a list

I'm sorry, I got it, LIST_SEPARATOR On Thu, Oct 1, 2015 at 4:57 PM, Tamás Kenéz <tamas.ke...@gmail.com> wrote: > Hi, > > I tried to pass a variable to an ExternalProjects config step which > contains a list: > > ExternalProject_Add(... CMAKE_ARGS "-DVAR=con

Re: [cmake-developers] CMake Find modules out of the CMake tree

> but I doubt the non-CMake ones generate SDL2Config.cmake files. neither of them generates, not even the CMake one On Wed, Sep 30, 2015 at 5:11 PM, Ben Boeckel wrote: > On Wed, Sep 30, 2015 at 10:22:47 -0400, Brad King wrote: > > With regard to SDL2, the proper way to

Re: [CMake] find_package for both debug and release with Visual Studio

1. build your own project, too, in separate build trees for debug and release 2. if all your dependencies' are prepared to provide debug and release libs simultanously (like Poco) you can build them in separate trees (however not neccessary) but set CMAKE_INSTALL_PREFIX and CMAKE_PREFIX_PATH to

Re: [CMake] "Pre-configure" step in CMake

What if you call your dependency-fetcher script with a straight macro/function call or `include` or `execute_process` instead of putting it into a custom target? I'm thinking of something like this: set(DEP_SCRIPT_OUT ${CMAKE_CURRENT_BINARY_DIR}/dep-script-out.cmake) if(NOT EXISTS

[CMake] config-module installed to '/share/cmake' - good or bad?

Note: this question was motivated by having some troubles with HDF5 but requires no familiarity with HDF5. The HDF5 source distribution installs a very nice config-module (creates imported targets unlike FindHDF5.cmake). However it installs it to `/share/cmake` which path is not searched by

Re: [CMake] Shared library from ExternalProject

Tue, 2015-09-15 at 16:32 +0200, Tamás Kenéz wrote: > > > it would be nice to know if the usage of add_library(foo SHARED > > > IMPORTED) is the way to go in this case. > > > > I wouldn't think this is the way to go. One thing we love CMake for is > that > > it

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

1. There is a (semi-)automatic way: you can export the targets of ExternalLib with install(EXPORT...) from its CMakeLists.txt. In the simplest cases you can use the generated export file as a config module: install(TARGETS ... EXPORT externallib ...) install(EXPORT externallib FILE

Re: [CMake] Libraries for a Target and/or its Dependents

I guess `Test` is also a static library. In that case this is the intended behaviour. Since `private_lib` is not compiled into `Test`'s object files, when you link the consumer of `Test` you still need to pull in `private_lib`. If `Test` were a shared lib then `private_lib` would not be listed.

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

Thank you, I was not aware of the EXPORT_NAME target property. Tamas On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly <steve...@gmail.com> wrote: > Tamás Kenéz wrote: > > >> For example, if an ALIAS can be IMPORTED, does it makes sense that it > can > > be > >

Re: [CMake] Shared library from ExternalProject

> it would be nice to know if the usage of add_library(foo SHARED > IMPORTED) is the way to go in this case. I wouldn't think this is the way to go. One thing we love CMake for is that it separates the concerns of the library and the consumer target so it's best to stick to find_package. This is

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

> For example, if an ALIAS can be IMPORTED, does it makes sense that it can be > exported with export() and install(EXPORT)? Yes: couple of months ago I was adding install(EXPORT) to an existing CMakeList. The name of the library target which I had to export was not correct as export target name

Re: [CMake] How to depend on external cmake projects?

On Mon, Aug 17, 2015 at 5:17 PM, James Johnston jam...@motionview3d.com wrote: [...] Your own CMake projects will be ExternalProjects to this high-level project and the superbuild would pass the location to your project via -Dproject_DIR=location so that find_package can locate the Config

Re: [CMake] How to depend on external cmake projects?

Robert, 1. If it's a library you are not modifying, only linking to, then you don't need its targets in your projects. You just need to clone, build and install it before running cmake for your actual project. It can be accomplished in various ways: - you can clone it as a submodule or manually

Re: [CMake] Imported libraries and cross platform target names

Anthony, instead of `find_library` I do think you should look into the config-module feature and the command `install(EXPORT ...)` which helps you generating them, as Nils Gladitz has already suggested. As you wrote, these libraries are already building from CMakeLists so you don't even need to

[CMake] on cmake supporting one arch per project (from CMake IR)

On 2015-07-30 11:51:54 GMT, Nagy-Egri Máté Ferenc via CMake wrote: how on Earth am I going to build x86/x64/ARM targets from one VS solution? [...] the way how CMake has been designed immediately rules it out from ~75% of application development going on in the world in the future (mobile app

Re: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

time where the generator expressions can be resolved. Thanks, Tamas (sorry for not replying-to-all in previous email) On Fri, Jul 17, 2015 at 5:41 PM, Brad King brad.k...@kitware.com wrote: On 07/16/2015 11:29 AM, Tamás Kenéz wrote: Well, it seems that `BundleUtilities` can't expand a single

Re: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

the `INTERFACE_LINK_LIBRARIES` property and also resolves the $CONFIG, $NOT and $0|1: generator expressions. I found no elegant way to resolve all generator expressions (`file(GENERATE ...)` can't be used since it does not output the resolved content instantly). Tamas On Wed, Jul 15, 2015 at 5:56 PM, Tamás

Re: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

I've just read the discussion at http://www.cmake.org/Bug/view.php?id=15299 about the deprecation of CMakeExpandImportedTargets. I guess it means no fixes to it. I'm checking BundleUtilities as suggested there. Tamas On Wed, Jul 15, 2015 at 5:56 PM, Tamás Kenéz tamas.ke...@gmail.com wrote

[cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

The CMakeExpandedImportedTargets module used only the deprecated IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive dependencies. Since the current `install(EXPORT ...)` command generates target files that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not working

[cmake-developers] OBJECT library on left-hand-side of target_link_libraries

The documentation states that OBJECT libraries may not be [...] used in the right hand side of target_link_libraries(). However it turns out that they can't be used on the left hand side either: add_library(objlib OBJECT ...) target_link_libraries(objlib dep-of-objlib) Result:

[cmake-developers] [PATCH] Help: fix FindMatlab section headers

Hi, FindMatlab used dash for its internal headers. This commit replaces caret-headers with double-quote-headers and replaces dash-headers with caret-headers. On top of release. Tamas 0001-Help-fix-FindMatlab-section-headers.patch Description: Binary data -- Powered by www.kitware.com

[cmake-developers] find_package config mode search path rule #5 error prone

Hi, The search path rule #5 reads: Search project build trees recently configured in a cmake-gui(1). This can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is building multiple dependent projects one after another. (This step is implemented only

Re: [cmake-developers] [CMake 0015231]: find_package: should be a simple way to alter the order of the config/module lookups

Are you interested in working on a patch for this? Yes, I'd give it a try. I signed up to Mantis, account: tamas.kenez so you can assign it to me. I guess that's the next step. Thanks, Tamas On Fri, Apr 17, 2015 at 2:01 PM, Brad King brad.k...@kitware.com wrote: On 04/16/2015 05:54 AM, Tamás

[cmake-developers] [CMake 0015231]: find_package: should be a simple way to alter the order of the config/module lookups

The https://public.kitware.com/Bug/view.php?id=15231 feature request proposes a new feature to make find_package to attempt CONFIG mode first. On 10/31/2014 01:30 PM, Brad King wrote: I think the main challenge will be how to format error messages when neither mode finds anything for a