Re: [CMake] How to run the install step of an ExternalProject when installing the whole project?

[Patrick Boettcher]

On Fri, 8 Mar 2019 15:45:50 +0100
Patrick Boettcher  wrote:

> Hi list,
> 
> I have several externalprojects in my build. Some of them have a quite
> complete install-step which I would like to have running when the
> parent-build is installed (and not during the compile build of the
> parent).
> 
> How can I achieve that?

I found a way, but is it the best one?

The external-project gets its INSTALL_COMMAND set to "".

And then I add:

  ExternalProject_Get_Property(project-ext BINARY_DIR)
  install(CODE "execute_process(COMMAND ${CMAKE_COMMAND} --build ${BINARY_DIR} 
--target install)")

--
Patrick.
-- 

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 run the install step of an ExternalProject when installing the whole project?

[Patrick Boettcher]

Hi list,

I have several externalprojects in my build. Some of them have a quite
complete install-step which I would like to have running when the
parent-build is installed (and not during the compile build of the
parent).

How can I achieve that?

(It is related to the usage of the DESTDIR-variable which is only
present during make install, but not during make)

Thanks in advance for any help,
--
Patrick.
-- 

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] .def files since CMake 3.10 in Linux

[Patrick Boettcher]

On Mon, 2 Jul 2018 12:08:16 +0200
Patrick Boettcher  wrote:

> Hi,
> 
> I (and someone else) stumbled upon a problem when using the Azure
> IOTHUB SDK for C on a Linux platform using cmake 3.10+:
> 
> https://github.com/Azure/azure-iot-sdk-c/issues/505
> 
> The problem seems to be triggered by having two .def-files as
> add_library()-source-files.
> 
> During the build cmake generates a command which does:
> 
>   cmake -E __create_def
> 
> This fails as unknown to cmake.
> 
> Is this a cmake-bug or is Azure using .def-files the wrong way?
> 
> A quick additional test show that the problem is coming from having
> 2 .def-files as sources. Having just one is OK.

The issue is no more present with CMake 3.12.0-rc1. It seems to be
fixed with

  
https://gitlab.kitware.com/cmake/cmake/commit/1ac042aa67c0e0ab531cd38977cb2f65fd96ed4b

. This bug-fix is not included in 3.11.3 .

--
Patrick.
-- 

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] .def files since CMake 3.10 in Linux

[Patrick Boettcher]

Hi,

I (and someone else) stumbled upon a problem when using the Azure IOTHUB
SDK for C on a Linux platform using cmake 3.10+:

https://github.com/Azure/azure-iot-sdk-c/issues/505

The problem seems to be triggered by having two .def-files as
add_library()-source-files.

During the build cmake generates a command which does:

  cmake -E __create_def

This fails as unknown to cmake.

Is this a cmake-bug or is Azure using .def-files the wrong way?

A quick additional test show that the problem is coming from having
2 .def-files as sources. Having just one is OK.

--
Patrick.



-- 

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] Force target to always run last?

[Patrick Boettcher]

Now that you described in more detail what you're trying to do I
realized that I had a similar problem to solve.

It's about generating packages for an arm-based linux-build
(Yocto-based). I decided against integrating my build into the
Yocto-build and instead I'm using cmake to cross-compile the
executables and libraries (C and C++).

Packaging is done with an IPK-file via a script launched by cmake
as the last step of the build process.

For each library and executable which belongs to a future ipk-package
I'm adding an install()-command which will, when the install-target
is run, place the files into a directory inside the build dir. This
directory is a dedicated one for the package:

For example:

top-level:

  set(PACKAGE_DIR ${CMAKE_BINARY_DIR}/common-exe-package)

Somewhere in the hierarchy of the project's CMakeLists.txt

  add_library(common src.cpp [..])
  install(TARGETS common
  DESTINATION ${PACKAGE_DIR}/usr/lib)

and again somewhere else

  add_executable(exe exe.cpp)
  target_link_libraries(exe PRIVATE common)
  install(TARGETS exe
  DESTINATION ${PACKAGE_DIR}/usr/bin)

Then I create a custom_target to create the package:

  add_custom_target(
ipk-common-exe
COMMAND
[..] # commands to finalize the ipk-tree and
 # tar xfz ... to make the ipk-files
COMMENT "creating common-exe IPK"
WORKING_DIRECTORY
${PACKAGE_DIR}
  )
  
  # add dependencies to a install-and-strip-target
  add_dependencies(ipk-common-exe install-and-strip)

The "install-and-strip"-target is defined at the top-level

  add_custom_target(
  install-and-strip
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} 
  --target install/strip)

the built-in install/strip-target has a dependency to all
targets use with install(TARGET ...) 

I'm using ninja and make -jX, both work in parallel. I'm build several
packages in one cmake-build. Works like a charm.

An additional bonus is that the install-target also removed RPATHs from
executables. 

HTH,
--
Patrick.




On Thu, 18 May 2017 11:16:47 -0500
Robert Dailey  wrote:

> So let me go over the problem I'm trying to solve, because it's
> possible at this point I'm over-engineering it, but it's hard to fix.
> 
> So my build process is for native shared library targets that
> eventually get included in an APK for Android. I'm using the NDK
> toolchain to build my native targets. The general flow from nothing to
> complete APK is as follows:
> 
> 1. Build all native library targets
> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
> in the android project directory (where the src, res, and other
> android directories are located)
> 3. Run custom commands that basically invoke 'ant release', and since
> I positioned the *.so files under 'libs' they get packaged with the
> APK itself.
> 
> This is how I provide support for using CMake to build native, run
> java build, and perform APK packaging.
> 
> There's a lot of setup that happens in CMake in order to make sure the
> 'ant release' command behaves as expected. I have to handle a few
> corner cases:
> 
> * Each new build of the custom target that runs the 'ant release'
> command has to only contain the *.so files that were built during that
> run
> * Various third-party libraries (pre-compiled *.so files) have to also
> be copied to libs/armeabi-v7a for only certain android projects,
> because we do not want duplicated *.so files across multiple android
> libraries (ant release will fail if there are duplicate *.so files
> across android project dependencies)
> 
> So given this, my complete pipeline is as follows:
> 
> 1. A `android_clean_libs` custom target is run which iterates all
> known native targets with mapped java projects and completely deletes
> its 'libs' directory (this is a forced clean prior to building)
> 2. A `copy_dlls` target runs next, which copies third party
> (precompiled) *.so files to a single common java project, in its
> 'libs/armeabi-v7a' directory.
> 3. Each native target now builds in parallel, as a post-build event it
> copies its output *.so file to its respective libs/armeabi-v7a
> directory for packaging.
> 4. A final 'package' custom target runs which runs 'ant release' on
> the bottom-most android project (that is not a library target by
> itself).
> 
> The part I don't like here is step #1. I don't like the clean to
> require keeping track of a global property of a list of directories to
> remove. Ideally, #1 should run as a post-build event during step 3.
> Basically each native target should delete its 'libs' directory prior
> to copying its own *.so target to that directory. However, I can't do
> this because of step #2. Step 2 must happen first, because it's the
> only way I can guarantee that it will execute regardless of which
> target I build (all, or specific target). I make `copy_dlls` a
> dependency of every other target, so it always runs. If I could force
> it 

Re: [CMake] Force target to always run last?

[Patrick Boettcher]

On Wed, 17 May 2017 10:36:59 -0500
Robert Dailey  wrote:

> I have a custom target that must meet the following requirements:
> 
> * It must always run, regardless of what subset of other targets are
> being built
> * It must always be the very last thing run. In parallelized builds,
> it must wait until all other targets are done building before
> starting, so that it is the very last target run, and should not run
> in parallel  with others.
> 
> Is this possible? I'm willing to use hackery if needed...
> 
> Running CMake 3.8.0. Thanks!

One way would be to create a super-project-like CMakeLists.txt which
will add your current project via ExternalProject_Add() .

Then you add your always-build-last-target to this super-CMakeLists.txt
as depending on the target created by this external-project in this
super-CMakeLists.txt .

regards,
--
Patrick.

-- 

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] Link order and interface multiplicity

[Patrick Boettcher]

On Wed, 17 May 2017 21:15:39 +
Etan Kissling  wrote:

> Not sure if I understand that correctly, but isn't that essential the
> same as creating a FooA and BarA that link to IA, and a FooB and BarB
> that link to IB, and linking ExeA to FooA and ExeB to FooB?
> 
> Problem with this approach is that there are more than two
> implementations of I, and way more than two Exes ^_^
 
Could you create an example repository (on github for example) which
templates what you're trying to achieve?

>From what I understood so far, I doubt that all of it can be
achieved in one cmake-build. Maybe you need to create a super-project
and work with export() and include(). 

regards,
--
Patrick.




-- 

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] RPATH for external library

[Patrick Boettcher]

On Wed, 17 May 2017 17:13:13 -0700
Pawel Veselov <pawel.vese...@gmail.com> wrote:

> On Wed, May 17, 2017 at 2:55 AM, Patrick Boettcher
> <patrick.boettcher@posteo.d>> My reason of preferring pkg-config is
> because it may have all
> >> other kind of stuff in it that the maintainer thought is necessary.
> >> I'd imagine some .pc files export a boatload of flags for all 3
> >> stages, and I rather not ignored them. It is also quite important
> >> when there are chained dependencies.  
> >
> > Understandable.
> >
> > If I understand things correctly, pkg-config does not return the
> > RPATH-arguments necessary to link with. IOW, if used in a GNU
> > Makefile you would also need to add these by yourself, right? So
> > your problem is not a cmake-problem.  
> 
> IMHO it's not fair to say - if it's not supported by GNUmake, it
> shouldn't be supported by CMake.

That was not my intention to say. But rather I thought that somewhere
this problem was already solved, as it is not a cmake-only-problem, but
a general build problem when using pkg-config on libraries which are not
in default search-pathes.
 
> In any case, the CMake documentation says that
> INSTALL_RPATH_USE_LINK_PATH "...will append directories in the linker
> search path and outside the project to the INSTALL_RPATH...", there
> is no statement that it only applies to linker search paths that were
> supplied in a certain way.

That applies only to libraries, not the linker-flags which have
been added behind the back of cmake's library-dependency mechanism. 

> [skipped]

This skipped part was trying to point out a solution based on the -l
and -L arguments returned by pkg-config and some cmake parsing. It
wouldn't be beautiful, but it'll work.

--
Patrick.
-- 

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] RPATH for external library

[Patrick Boettcher]

On Tue, 16 May 2017 12:32:11 -0700
Pawel Veselov  wrote:

> > I was once in a situation where I could have used pkg-config with a
> > custom path to have pkg-config look for the .pc-file. I then
> > switched to find_library with the custom-path slightly adapted and
> > it worked at least as good as with pkg-config, if not better. For
> > my case.  
> 
> Right. My reason of preferring pkg-config is because it may have all
> other kind of stuff in it that the maintainer thought is necessary.
> I'd imagine some .pc files export a boatload of flags for all 3
> stages, and I rather not ignored them. It is also quite important
> when there are chained dependencies. 

Understandable. 

If I understand things correctly, pkg-config does not return the
RPATH-arguments necessary to link with. IOW, if used in a GNU
Makefile you would also need to add these by yourself, right? So your
problem is not a cmake-problem.

If this is the case, what you're looking for is a macro/script which
transforms -l and -L-arguments to the fully-qualified filename. That
should be doable with a combination of string(SUBSTRING) and
find_library() - if you dare ;-) .

> AFAIU, find_library() is not
> capable of tracking down dependencies.

No, find_library only returns the (complete) filename of a library
found via its arguments.

--
Patrick.
-- 

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] RPATH for external library

[Patrick Boettcher]

On Tue, 16 May 2017 11:50:47 -0700
Pawel Veselov  wrote:

> >> I'm trying to make CMake add to the linker RPATH automatically.
> >> There is a library that is installed in a non-default location.
> >> I'm discovering the library using PkgConfig (custom
> >> CMAKE_APPBUNDLE_PATH) and add the library build options to the
> >> LINK_FLAGS (using set_property).  
> > Instead of setting the LINK_FLAGS to your external library try using
> > target_link_libraries() with the full path name to the library.
> >
> > For example this will work as expected, cmake with set an RPATH
> > to "/path/to":
> >
> >   set(LIB "/path/to/libsomething.so")
> >   target_link_libraries(test1 ${LIB})  
> 
> That doesn't really play well with FindPkgConfig then. AFAIK, there is
> no way to ask pkg-config to dish out full libraries paths, one would
> have to sift through all -l and -L and figure them out...

Could you switch from pkg-config to find_library() ?

I was once in a situation where I could have used pkg-config with a
custom path to have pkg-config look for the .pc-file. I then switched to
find_library with the custom-path slightly adapted and it worked at
least as good as with pkg-config, if not better. For my case.

regards,
--
Patrick. 
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] TargetLinkLibraries on OBJECT-libraries

[Patrick Boettcher]

On Tue, 16 May 2017 08:46:16 -0400
Robert Maynard  wrote:

> Hi,
> 
> I recommend you follow
> https://gitlab.kitware.com/vtk/vtk-m/merge_requests/741 and the
> related merge requests for the current status of adding support for
> exactly this.

Are you sure this is the right link? I'm don't see any commit message
dealing with cmake in this repository.

--
Patrick.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] TargetLinkLibraries on OBJECT-libraries

[Patrick Boettcher]

Hi,

I'd like to use target_link_libraries() on an OBJECT-library for the
following reason:

I'm creating an OBJECT-library which has quite some requirement
regarding include-dirs, compile-options and -definitions. Which is why
my CMakeLists.txt currently looks somehow like this: (runtime is an
interface-library)

  add_library(runtime-main OBJECT runtime.cpp)

  target_include_directories(runtime-main
PRIVATE 
  $)

  target_compile_features(vsora-runtime-main
PRIVATE
  $)

  target_compile_options(vsora-runtime-main
PRIVATE
  $)

  target_compile_definitions(vsora-runtime-main
PRIVATE
  $)

I think the last 4 commands could be factored in a simple call to 

  target_link_libraries(runtime-main INTERFACE runtime)

(INTERFACE would have to be used even when the to be linked
library is not an INTERFACE library)

or

  target_link_libraries(runtime-main PRIVATE runtime)

or 

  target_link_libraries(runtime-main OBJECT runtime)

I started looking into the code, except removing the check in
cmTargetLinkLibraries.cpp I didn't do much. And this does not make it
work. 

Before continuing I'd like to know whether this is a good idea to work
on or if there are good arguments to never allow "linking" an
object-library to get compile information from other libraries?

best regards,
--
Patrick.










-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Link order and interface multiplicity

[Patrick Boettcher]

Hi,

On Mon, 15 May 2017 12:30:10 +
Etan Kissling  wrote:
> I have a project with a layer consisting of interface libraries:
>   add_library(I INTERFACE)
> 
> These interface libraries are then implemented several times, to fit
> the different environments of applications: add_library(IA STATIC ...)
>   target_link_libraries(IA PUBLIC I)
> 
>   add_library(IB STATIC ...)
>   target_link_libraries(IB PUBLIC I)
> 
> There are also application independent libraries, that make use of
> the interface libraries. add_library(Foo STATIC ...)
>   target_link_libraries(Foo PUBLIC I)
> 
>   add_library(Bar STATIC ...)
>   target_link_libraries(Bar PUBLIC I)
> 
> And finally, the application defines which implementation of the
> interface library layer is being used. 
>
>   add_executable(ExeA ...)
>   target_link_libraries(ExeA Foo Bar IA)
> 
>   add_executable(ExeB ...)
>   target_link_libraries(ExeB Foo Bar IB)
> 
> 
> Luckily, this is okay, as long as IA is listed after Foo and Bar in
> the synthesized link command.
> 
> However, certain implementations of I make use of the application
> independent libraries again. On these environments, the link command
> line becomes something like this: 
>
> IA Foo Bar
> 
> While it should be
>
> Foo Bar IA Foo Bar
> 
> This make sense, because there is no explicit dependency being
> described that Foo / Bar depend on IA while compiling ExeA. In the
> simple case, we just get lucky, because it happens to be the default
> that link command line has the same order as in the
> target_link_libraries call.

I wouldn't try my luck if I were you. Always be explicit, especially
with dependencies, otherwise, at some point in time, cmake won't get it
right when generating the order of link.

What you could try is "forward" declaring a
platform/app-dependent dependencies with interface libraries:

In CMakeLists.txt

  add_library(top-level-I INTERFACE)
  target_link_libraries(top-level-I INTERFACE app-dependent-I) 
# here we forward declare app-dependent-I

  add_subdirectory(app) # app-dependent

  add_executable(test2 test2.cpp)
  target_link_libraries(test2 top-level-I) # will link with IA and IB

In app/CMakeLists.txt

  add_library(app-dependent-I INTERFACE)
  target_link_libraries(app-dependent-I INTERFACE IA IB)
# here we "implement" 

  add_library(IA ...)
  add_library(IB ...)

app-dependent-I is a forward declared libraries - cmake will evaluate
this at generation-time. This will get you the dependencies right.

I hope I correctly understood your question.

--
Patrick.
-- 

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] RPATH for external library

[Patrick Boettcher]

On Mon, 15 May 2017 13:32:15 -0700
Pawel Veselov  wrote:

> Hello.
> 
> I'm trying to make CMake add to the linker RPATH automatically.
> There is a library that is installed in a non-default location.
> I'm discovering the library using PkgConfig (custom
> CMAKE_APPBUNDLE_PATH) and add the library build options to the
> LINK_FLAGS (using set_property).

Instead of setting the LINK_FLAGS to your external library try using
target_link_libraries() with the full path name to the library.

For example this will work as expected, cmake with set an RPATH
to "/path/to":

  set(LIB "/path/to/libsomething.so")
  target_link_libraries(test1 ${LIB})

HTH,
--
Patrick.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Wrongly assuming lib/ is IsImplicitDirectory for runtime-paths

[Patrick Boettcher]

Hi list,

This is a follow-up of my problem I discussed with myself on the
cmake-mailing list: "CLANG vs GCC when linking executables".

I found the root-cause of this problem:

When constructing the rpath-arguments cmake is using an
cmOrderDirectories called OrderLinkerSearchPath to which all
the runtime-libraries via AddRuntimeLibrary() have been added.

In AddRuntimeLibrary() it checks whether the library-path is an
implicit directory.

To this list somewhere the lib/-path located next to the
compiler-bin/-path has been added.

This works well if the compiler is installed in /usr/bin
because /usr/lib is present in the system's loader-configuration.

In my case I have locally built a compiler and in the lib/-dir next to
the bin/-dir I installed other libraries. When now linking with one of
them (via an IMPORTED library), cmake does not add the rpath because it
assumes lib/ is implicitly used by the loader (or something else?).

What can I do? Is this a bug in cmake or in my setup? Why is this path
considered implicit?

best regards,
--
Patrick.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CLANG vs GCC when linking executables

[Patrick Boettcher]

On Fri, 12 May 2017 17:30:16 +0200
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:
> The problem only occurs when the compiler is coming from a custom
> build from a custom path. Running 
>   
>   CXX=clang++ cmake 
> 
> makes cmake generate the correct link options.
> 
>   CXX=/local/path/bin/clang++ cmake 
> 
> makes cmake generate wrong link options (without RPATH).
> 
> Seems to be related the compiler-ID which is wrongly determined or
> something like that. 

I continued a bit more, it turns out that the placeholder
 (using the link.txt) does not contain the
rpath-options when linking with my locally generated compiler but it
present when using system compiler.

Where is LINK_LIBRARIES filled in? What option, features makes cmake
insert -Wl,rpath or not (as in my case)

--
Patrick.
-- 

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] CLANG vs GCC when linking executables

[Patrick Boettcher]

On Fri, 12 May 2017 16:57:25 +0200
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:

> Hi list,
> 
> I'm trying to link an executable with a locally build and imported
> dynamic library. The link-code generated by CMake differs when 
> using GCC and Clang in regards to the rpath-options:
> 
> This is my cmake-code for importing the library (this code is actually
> generated by using export() )
> 
>   add_library(systemc INTERFACE IMPORTED)
>   set_target_properties(systemc PROPERTIES
> INTERFACE_COMPILE_DEFINITIONS "SC_INCLUDE_FX"
> INTERFACE_COMPILE_OPTIONS "-Wno-deprecated-declarations"
> INTERFACE_INCLUDE_DIRECTORIES "/local/path/include"
> INTERFACE_LINK_LIBRARIES "/local/path/lib/libsystemc.so")
> 
>   add_executable(testsc test.cpp)
>   target_link_libraries(testsc systemc)
> 
> When now running cmake in a build-dir which uses by default gcc the
> link-command contains:
> 
>   /usr/bin/g++ CMakeFiles/testsc.dir/test.cpp.o  -o testsc \
> -Wl,-rpath,/local/path/lib /local/path/lib/libsystemc.so
> 
> doing the same with clang++ as CXX-compiler (CXX=clang++ cmake
> ) gives me a linker command not containing the
> -rpath-option:
> 
>   clang++ CMakeFiles/testsc.dir/test.cpp.o -o testsc \
> /local/path/lib/libsystemc.so
> 
> The link-process works, but when running the executable inside the
> build-dir it is unable to find the library as neither the rpath is set
> nor is this library-path known by the dynamic loader.
> 
> Is there anything I can do? Is this behavior expected? How should the
> RPATH being handled when clang is used.

The problem only occurs when the compiler is coming from a custom build
from a custom path. Running 
  
  CXX=clang++ cmake 

makes cmake generate the correct link options.

  CXX=/local/path/bin/clang++ cmake 

makes cmake generate wrong link options (without RPATH).

Seems to be related the compiler-ID which is wrongly determined or
something like that. 

--
Patrick.
-- 

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] CLANG vs GCC when linking executables

[Patrick Boettcher]

Hi list,

I'm trying to link an executable with a locally build and imported
dynamic library. The link-code generated by CMake differs when 
using GCC and Clang in regards to the rpath-options:

This is my cmake-code for importing the library (this code is actually
generated by using export() )

  add_library(systemc INTERFACE IMPORTED)
  set_target_properties(systemc PROPERTIES
INTERFACE_COMPILE_DEFINITIONS "SC_INCLUDE_FX"
INTERFACE_COMPILE_OPTIONS "-Wno-deprecated-declarations"
INTERFACE_INCLUDE_DIRECTORIES "/local/path/include"
INTERFACE_LINK_LIBRARIES "/local/path/lib/libsystemc.so")

  add_executable(testsc test.cpp)
  target_link_libraries(testsc systemc)

When now running cmake in a build-dir which uses by default gcc the
link-command contains:

  /usr/bin/g++ CMakeFiles/testsc.dir/test.cpp.o  -o testsc \
-Wl,-rpath,/local/path/lib /local/path/lib/libsystemc.so

doing the same with clang++ as CXX-compiler (CXX=clang++ cmake
) gives me a linker command not containing the -rpath-option:

  clang++ CMakeFiles/testsc.dir/test.cpp.o -o testsc \
/local/path/lib/libsystemc.so

The link-process works, but when running the executable inside the
build-dir it is unable to find the library as neither the rpath is set
nor is this library-path known by the dynamic loader.

Is there anything I can do? Is this behavior expected? How should the
RPATH being handled when clang is used.

best regards,
--
Patrick.
-- 

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] Is it possible to run ctest outside build tree?

[Patrick Boettcher]

Hi,

Answering a little bit late: I had a similar problem I wanted to run
only parts of my tests (-R) dedicated test-reports.

As cmake is using absolute paths to the executable the only thing I
needed to copy were the CTestFiles in all sub-directories.

  # copy all ctest-files to the current dir
  rsync -avm --include='*CTestTestfile.cmake' -f 'hide,! */' \
  ${TESTING_WORKSPACE}/* .

TESTING_WORKSPACE is the build-dir. 'current dir' is a path per
test-selection.

I then can run different ctest -R  in the different paths
using on the same binaries from one build dir and having different
test-reports.

HTH,
--
Patrick.





On Fri, 24 Mar 2017 20:11:14 +0100
Eric Noulard  wrote:

> Hi David,
> Thank you for you for checking the code. Would you think adding such a
> command line option would be acceptable upstream?
> 
> Le 24 mars 2017 18:43, "David Cole"  a écrit :
> 
> This code:
> 
> https://github.com/Kitware/CMake/blob/master/Source/ctest.cxx#L139-L157
> 
> shows ctest will look for a CTestTestfile.cmake or DartTestfile.txt
> file in the current working directory as soon as it starts. Except in
> the case of processing a "--launch" directive, in which case, it
> dispatches that in the code just above there.
> 
> So. I think you have not much choice other than to propose adding a
> new command line argument for such purpose, or wrapping existing ctest
> with your own script or program of some sort.
> 
> 
> HTH,
> David C.
> 
> 
> 
> 
> On Fri, Mar 24, 2017 at 6:04 AM, Eric Noulard 
> wrote:
> > Is possible to run ctest outside the builld tree and how?
> > typical use is when I have an out of source build I may be in the
> > source tree
> > and want to run tests without manually going to build tree.
> >
> > i.e. I currently do:
> >
> > ninja -C /my/build/tree
> >
> > is there a similar way to do that with ctest (other than creating
> > my own script, shell alias etc...)?
> >
> > --
> > Eric
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For
> > more information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > 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] Policy to forbid linking with non-cmake-targets

[Patrick Boettcher]

Hi list,

is there a policy which can be enabled to forbid calling 

  target_link_libraries(foo bar)

where bar is _not_ a known cmake target?

Right now, if 'bar' is not a cmake-target cmake tries to link with
-lbar (on linux). Can I inhibit this behavior in any way?

I'd prefer cmake telling me that this target is unknown rather than
receiving a link error at the end of the build-process.

Thanks,
--
Patrick.

-- 

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] clang-format

[Patrick Boettcher]

Hi,

On Mon, 7 Nov 2016 12:06:15 -0800
Tiago Macarios  wrote:
> CMake has "built-in" support for clang_tidy and include-what-you-use.
> I was wondering why there is not support for clang_format. No one ever
> contributed, or people think this should not be part of CMake?

First thought which came to my mind when reading your mail was that no
automatic tool should change (source-)files during compilation which
are, possibly, opened in an editor.

But, it would, maybe, be nice to have a custom, optional target to run
it on demand.

If your editor supports it (mine does, even for selected code-lines, \o/
) integrate clang-format as source-code-indentation-tool. 

regards
--
Patrick.


-- 

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] object-libraries and compile-dependencies to other target

[Patrick Boettcher]

On Wed, 20 Jul 2016 13:49:52 -0400
Robert Maynard  wrote:

> Hi Patrick,
> 
> Can you provide a simple example of what you are trying to do, and
> where it is failing?

-
add_library(lib1 STATIC )
target_include_directories(lib1 PUBLIC lib1-dir)
target_compile_features(lib1 PUBLIC cxx_nonstatic_member_init)
target_compile_definitions(lib1 PUBLIC FLAG)

* lib2 and lib3 like lib1 *

# runtime needs include-dirs of lib2 and lib3
add_library(runtime OBJECT file1.cpp)
target_link_libraries(runtime INTERFACE lib2 lib3) # fails

# so I manually add them: 

target_include_directories(runtime PRIVATE
   $)
# and the same for target_compile_features and
# the INTERFACE_COMPILE_FEATURES property - for all libraries.

add_executable(exe exe1.cpp exe2.cpp $)
target_link_libraries(exe lib1 lib2 lib3)

-

You might ask, why I need to make an object-library here. This is
because of a problem I encounter on some platforms where the linking
fails when runtime is a static library. In runtime there is a function
which is required by lib2, on the problematic platforms the only way to
be sure that the linker is not throwing away this function before it has
been referenced, is by passing it as .o-file to the link-line. 

regards,
--
Patrick.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] object-libraries and compile-dependencies to other target

[Patrick Boettcher]

Hi list,

I'm using an object-library to generate a list of .o-files instead of
archives which I use to link into several executable.

Even though it is only an object-library it has compile-dependencies to
other targets - this includes include-paths, compile-definitions and
compile-features. 

I can't (or I don't know how) use target_link_libraries() with my
object-library. 

What can I do to make it work? I'm exploring generator-expressions, but
this seems redundant as I need to list all dependencies again.

best regards,
--
Patrick.

-- 

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] CTest - how to structure tests for different test jobs with a shared build-dir

[Patrick Boettcher]

Hi list,

On Wed, 6 Jul 2016 10:19:05 +0200 Patrick Boettcher
<patrick.boettc...@posteo.de> wrote:
> I have several options at hand: 
> 
> - I could install the tests into the test-job-workspace (not sure if
>   this will really work with ctest)
> - I could copy the build-dir (what about the absolute paths used)
> - I could simple rebuild my binaries for each job (very long and
>   redundant)
> 
> Ideally I could tell ctest: here is the cmake-binary-dir, here you can
> find the test-binaries, but please put the results into the job's
> workspace this dir.

I find a solution which satisfies my needs: I just copy all the
CTestTestFiles.cmake recursively while keeping the path-hierarchy.

Then running ctest at the top-level executes the tests from the
original build-dir (absolute paths) .

Copying is done like this

rsync -avm --include='*CTestTestfile.cmake' -f 'hide,! */'

This, for the moment works.

Would be nice if there was a way to tell cmake to generate ctest-files
into a separate dir.

regards,
--
Patrick.



-- 

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] Dependency on imported target with ninja-generator

[Patrick Boettcher]

On Wed, 22 Jun 2016 19:44:14 -0500
Nicholas Braden  wrote:

> If Project B depends on Project A, you should probably be using the
> ExternalProject module with a superproject structure that builds both
> projects in the proper order.
> 
> https://cmake.org/cmake/help/latest/module/ExternalProject.html
> 
> Trying to manually call CMake is not really a good idea IMO - let
> ExternalProject handle it for you.

That was it: superproject - based on CMake + ExternalProject.

Thanks a lot.

Regards,
--
Patrick.
-- 

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] Dependency on imported target with ninja-generator

[Patrick Boettcher]

Hi list,

I'm finding myself in the following situation.

- Project A generates libmain.a and export(TARGETS ... NAMESPACE ns) it
  to a file. The target is called ns::main

- Project B includes this file and has some executables link with
  libmain.a (via target_link_libraries(exe ns::main).

- Project B's CMakeLists.txt contains a add_custom_target(build ...)
  which runs cmake --build in project A's build-dir.

- the target build is a add_dependency() of ns::main.

Building it with gnu-make works like a charm - make is entering project
A's build-dir before linking.

Building it with ninja fails with not finding libmain.a - which is
normal it has not yet been built. Ninja seems to evaluate the complete
dependency-tree of files before doing anything.

Is there a way to fix this?

Thanks.

best regards,
--
Patrick.



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake generator executable variable

[Patrick Boettcher]

Hi Petr,

On Wed, 22 Jun 2016 16:52:17 +0200
Petr Kmoch  wrote:

> Hi Patrick.
> 
> If the "subproject" is also CMake-generated, as you say, the best way
> to build it would be:
> 
> add_custom_target(build-app
>   COMMAND ${CMAKE_COMMAND} --build #... other options as
> appropriate )
> 
> You might also have to set the WORKING_DIRECTORY.

Thanks. Just when your Email arrived I just found the --build-option.

It is even better than I thought it will be.

regards,
--
Patrick.
-- 

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] CMake generator executable variable

[Patrick Boettcher]

Hi list,

In my project some people use Ninja as a generator, some use GNU Make.

In a part of my projects I have a add_custom_command() which runs, for
convenience, the build of another cmake-generated project in another
dir using a different set of compilers (which is the reason for not
being a sub_directory).

  add_custom_target(build-app
  COMMAND make -C ${APP_BUILD_DIR})

This fails of course if the user decided to use ninja.

We can assume that the caller's build is always using the same generator
as the callee's one.

I know there is CMAKE_GENERATOR - I could do it with 'IF()', but is
there a variable carrying the generator-command which I can use to
replace the bare 'make'?

Thank you in advance.

regards,
--
Patrick.



-- 

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] GCC: -std=g++14 vs -std=c++14

[Patrick Boettcher]

On Wed, 15 Jun 2016 10:50:13 -0400
"Elizabeth A. Fischer"  wrote:

> Why are these extensions not turned off by default?  Normally, things
> should conform to the standards out-of-the-box; and you should have to
> explicitly enable extensions.  Following that principle would have
> avoided this entire thread.

Well, I'd not be surprised if the expected standard for gcc users is
--std=gnu++14 instead of --std=c++14 . That could be a good explanation.

regards,
--
Patrick.
-- 

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] GCC: -std=g++14 vs -std=c++14

[Patrick Boettcher]

On Mon, 13 Jun 2016 20:05:23 +0200
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:
> > You also need to correctly set the CXX_EXTENSIONS properties to get
> > a standard standard.  
> 
> Yep, 
> 
>   set(CXX_EXTENSIONS OFF)
> 
> seems to do the trick - thanks.

Well, it is 
  
  set(CMAKE_CXX_EXTENSIONS OFF)

actually. Before the target-definition (add_library or add_executable).


--
Patrick.
-- 

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] GCC: -std=g++14 vs -std=c++14

[Patrick Boettcher]

On Mon, 13 Jun 2016 18:40:59 +0200
Sylvain Joubert <joubert...@gmail.com> wrote:

> Le 13/06/2016 11:36, Patrick Boettcher a écrit :
> > Hi list,
> >
> > I'm using gcc for a c++14-based project.
> >
> > To have cmake add the corresponding -std=-flag I'm setting
> >
> >set_property(TARGET  PROPERTY CXX_STANDARD 14)
> >
> > This makes that when gcc is used cmake adds -std=gnu++14 .
> >
> > How can I make it set -std=c++14 instead?  
> 
> Hi,
> 
> You also need to correctly set the CXX_EXTENSIONS properties to get a 
> standard standard.

Yep, 

  set(CXX_EXTENSIONS OFF)

seems to do the trick - thanks.

regards,
-- 
Patrick.
-- 

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] GCC: -std=g++14 vs -std=c++14

[Patrick Boettcher]

Hi list,

I'm using gcc for a c++14-based project.

To have cmake add the corresponding -std=-flag I'm setting

  set_property(TARGET  PROPERTY CXX_STANDARD 14)

This makes that when gcc is used cmake adds -std=gnu++14 .

How can I make it set -std=c++14 instead?


Background: my problem is the complex literal 'i' . 

This literal existed in gcc as a C99 extension and the effect is kept
when -std=gnu++14 is set and deactivated when -std=c++14 is set.

The outcome is that '0.0i' is typed as '__complex__ double' and not
'std::complex' as the standard says.

regards.
--
Patrick.



-- 

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] C header file cross dependency

[Patrick Boettcher]

Hi Martin,

On Wed, 1 Jun 2016 14:58:53 +
Wagner Martin  wrote:

> > 
> > Could you provide a working, stripped down example to show the
> > problem provided via github (in an example repo).
> >   
> 
> I've added a simple test project to 
> 
> https://github.com/martinwag/test_cmake/tree/master
> 
> Note that this example does not need cross gcc for ARM. It doesn't
> implement any useful functionality!

I forked your repo and played a little bit around. 

https://github.com/pboettch/test_cmake

Here are my conclusions:

1) Due to the use of add_libary(... OBJECTS ...) you cannot link
libraries with libraries or interfaces, this is a pity - especially for
a complex project with a lot of sub-dirs. 

There is a possibility to merge STATIC-libraries to generated one big
archive using external tools (libtool). If I were you I'd try to
this way to profit from the target_*-cmake-features.

2) I created a log-dir with an interface-library - which only carries
the log.h and thus the printf-prototypes

3) Both, drivers and terminal link with this interface-library (to get
their hands on log.h)

4) In addition I added two libraries to drivers/ uart-logging1 and
uart-logging2. This shows how you could compile-configure your
printf-function depending on the hardware used. In the main CMakeLists
you just need to select one of them - depending on the option's value.

Basically I followed the idea of instantiating a print-function
'somewhere' in the project (it could also be done outside) and then
select the one you want to use at the final link.

Of course this way you could add other ways of printf'ing - logging1
and logging2 are just stupid examples.

HTH and sorry for the delay,
--
Patrick.



-- 

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] C header file cross dependency

[Patrick Boettcher]

On Mon, 23 May 2016 13:49:14 +
Wagner Martin  wrote:

> Hi @all,
> 
> I'm quite new to CMake. If I've made a mistake or something is much
> easier to solve, please tell me.
> 
> I'd like to use CMake in embedded development (Build System: Linux,
> Target: ARM Microcontroller) to get rid of complicated makefiles.

Good thing! 

> We're building multiple devices where stuff like embedded rtos and
> peripheral drivers are identical, so I'd like to separate this part
> from the user application. I've achieved that by creating an object
> library out of all source and header files, and packing those files
> using CPack. This archive is then statically linked against the user
> application.
> 
> So far this worked fine. However, now I have to use driver functions
> in the rtos source code and vice versa, resulting in
> cross-dependencies for header files:
> 
> 
> 
> #include uart.h
> #include terminal.h
> 
> function() {}
> 
> 
> 
> #include terminal.h
> #include uart.h
> 
> function() {}
> 
> How do I resolve something like this? Right now CMake evaluates the
> compiler includes in the order that subdirectories are added. This
> gives me an compilation error in uart.c that terminal.h cannot be
> found.

This is not a cmake-problem, but seems to be a code-structure-issue.

I'm guessing here: if terminal needs the uart-code shouldn't it be the
uart-code filling in a terminal-function. Interface vs. implementation?
Could you elaborate more on how terminal and uart are linked?

Regarding cmake: I suggest you stop using include_directories() and
start using target_include_directories() and
target_compile_definitions() instead of add_definitions().

Limiting yourself to this way of doing libraries and targets, cmake will
force you to structure your code in a more standard way - and will
provide you with clean visibility between different targets.

Could you provide a working, stripped down example to show the problem
provided via github (in an example repo).

More comments below.
 
> Some excerpt of my project. I've tried to keep the example as simple
> as possible.
> 
> My directory structure looks something like that:
> /
> CMakeLists.txt
> src +
> +CMakeLists.txt(1)
> +drivers+
> |   +uart.c
> |   +uart.h
> |   +...
> |   +CMakeLists.txt(2)
> +os-+
> |   +terminal.c
> |   +terminal.h
> |   +...
> |   +CMakeLists.txt(3)
> 
> 
> (1):
> 
> SET(drivers "drivers")
> SET(terminal "terminal")
> 
> SET(drivers_lib ${drivers})
> SET(terminal_lib ${terminal})
> 
> SET(ARCHIVE_INSTALL_DIR lib)
> SET(INCLUDE_INSTALL_DIR include)
> 
> SET(headers_private "_headers_private") # internal headers
> SET(headers_public "_headers_public")   # public headers go into
> package
> 
> ADD_SUBDIRECTORY(${drivers})
> ADD_SUBDIRECTORY(${terminal})

I think it is common practice now to use lower-case for cmake-commands
now. 

> ## drivers
> 
> ##  Sources
> ---
> SET(sources "uart.c"
> )
> 
> ##  Header includes
> ---
> SET(headers "${CMAKE_CURRENT_SOURCE_DIR}/" 
> )
> SET(${drivers}${headers_public} ${headers} PARENT_SCOPE)
> 
> INCLUDE_DIRECTORIES(${headers} 
> ${${terminal}${headers_public}}
> )

While the ${${var}${var2}} (seems to) work, it is error-prone, IMHO.

Standard cmake-commands can work with relative paths and are evaluating
them correctly taking into account ${CMAKE_CURRENT_SOURCE_DIR} (most of
the time. So you could use ../uart in terminal/ - but it would be
better if it comes indirectly via target_include_directories() and
target_link_libraries()

>[..]
> 
> And finally this creates the package in root directory CMakeLists.txt:
> 
> SET(CPACK_PROJECT_CONFIG_FILE ${CMAKE_BINARY_DIR}/CPackOptions.cmake)
> # CPackOptions.cmake contains package file name SET(CPACK_GENERATOR
> "TBZ2") INCLUDE(CPack)

Due to the circular header-dependency the binaries of terminal and uart
should have the same mutual dependency. In this case you could build
them in within one target.

regards
--
Patrick.

-- 

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] Difference between PRIVATE and PUBLIC with target_link_libraries

[Patrick Boettcher]

On Fri, 13 May 2016 07:06:32 +1000
Craig Scott  wrote:

> Patrick,
> 
> I suggest if you can reduce your problem down to a small, reproducible
> example, then file a bug. I did a test just now with CMake 3.5.2 and
> everything behaved as expected, including the header search path
> propagation, so maybe there's something unusual in your project which
> a simple case doesn't capture. Perhaps also try different generator
> types in case that results in something different (unlikely, but
> since you see different behaviour to me, give it a go).

I filed a bug with a test-case reduced to 7 lines of cmake. I
reproduced it with GNU Make and Ninja a generator.

https://cmake.org/Bug/view.php?id=16102

I'm also reading some cmake-code, but haven't yet found where includes
are inherited from linked targets. Currently looking at 
cmGeneratorTarget::GetIncludeDirectories() ...

Thanks for your feedback.

best regards,
--
Patrick.
-- 

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] Difference between PRIVATE and PUBLIC with target_link_libraries

[Patrick Boettcher]

On Thu, 12 May 2016 09:20:10 -0500
iosif neitzke  wrote:

> I'm sorry, I'm not sure I understand.  In your example, there is
> target_link_libraries(lib3 PUBLIC lib1).  It looks like lib2 has
> target_link_libraries(lib2 PRIVATE lib1).

Yes. That is correct.

When building the code for lib2 and lib3 the include-path of lib1 is
provided (as expected).

Then when building exe1 (links to lib2) and exe2 (links to lib3) the
lib1's include-path is present in both cases.

Whereas it should not be present with exe1, at least that is my
understanding.

--
Patrick.
-- 

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] Difference between PRIVATE and PUBLIC with target_link_libraries

[Patrick Boettcher]

On Thu, 12 May 2016 09:04:10 -0500
iosif neitzke  wrote:

> target_include_directories(lib1 INTERFACE /tmp) means /tmp is
> propagated with lib1, but not used to build lib1.

I know. Could you elaborate how this is related with lib3 PRIVATEly linking to
lib1?

regards,
--
Patrick.
-- 

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] Difference between PRIVATE and PUBLIC with target_link_libraries

[Patrick Boettcher]

On Wed, 11 May 2016 21:58:34 +1000
Craig Scott  wrote:

[..] 
> If you were paying careful attention, you would have noticed that
> when A links in B as PRIVATE, the include directories of B never
> propagate to something linking to A, but if A is a static library,
> then the *linking* of B behaves as though the relationship was
> PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries
> only applies to the *linking*, not to the other dependencies
> (compiler options/flags and include search paths). The upshot of all
> this is that if you select PRIVATE, PUBLIC or INTERFACE based on the
> explanations in the dot points above, then CMake will ensure
> dependencies propagate through to where they are required, regardless
> of whether libraries are static or shared. This does, of course, rely
> on you the developer not missing any dependencies or specifying the
> wrong PRIVATE/PUBLIC/INTERFACE relationship.

Thank you for you long explanation. It was exactly my understanding. 

So cmake 3.5.0 has a bug then because I don't see the behavior you
describe. Have you seen my example I sent in my first mail? 

http://public.kitware.com/pipermail/cmake/2016-May/063382.html

Include-dirs from B are propagated to C which links to A which itself
linked privately to B.

Should I file a bug?

regards,
--
Patrick.





 


-- 

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] Difference between PRIVATE and PUBLIC with target_link_libraries

[Patrick Boettcher]

On Tue, 10 May 2016 11:39:49 +0200
Attila Krasznahorkay  wrote:

> Hi Patrick,
> 
> I *think* that these public/private rules behave a bit differently
> for static libraries than they do for shared ones.
> 
> But I have to admit, that based on this code I also would've guessed
> that -I/tmp would not show up in the build of exe1...
> 
> I did manage to use public and private dependencies as expected in my
> own configurations, so I'm not exactly sure what's going wrong in
> your case. Which version of CMake did you use for the test?

I'm using cmake 3.5.0.

Thank you for your feedback - I'll try to use shared-libraries, to see
whether it changes something or not

regards,
--
Patrick.
-- 

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] Difference between PRIVATE and PUBLIC with target_link_libraries

[Patrick Boettcher]

Hi list,

What is the differences between PRIVATE and PUBLIC when used with
target_link_libraries?

I read the help and understood that it works like in C++: PRIVATE will
make everything which was PUBLIC before also PRIVATE if inherited
privately.

An example:

  add_library(lib1 INTERFACE)
  target_include_directories(lib1 INTERFACE /tmp)

  add_library(lib2 src2.c)
  target_include_directories(lib2 PUBLIC /bin)
  target_link_libraries(lib2 PRIVATE lib1) # PRIVATE here

  add_library(lib3 src3.c)
  target_include_directories(lib3 PUBLIC /bin)
  target_link_libraries(lib3 PUBLIC lib1) # PUBLIC here
 
  add_executable(exe1 exe.c)
  target_link_libraries(exe1 lib2)

  add_executable(exe2 exe.c)
  target_link_libraries(exe2 lib3)


When building exe2 both include-dirs (from lib1 and lib3) are present:

  [..] -I/bin -I/tmp  [..]

as they are for exe1 - however I would have expected to not see /tmp
because lib3 and lib1 are linked privately.

Where is my mistake?

Thanks,
--
Patrick.

-- 

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] Two-stage build - how to include and know existing targets

[Patrick Boettcher]

Hi list,

In my project I have to build things in two stages (different compilers
and different flags between the two stages). Both are built with CMake.

I'm looking for a way of how to correctly include the generated
products from one project (libraries in my case) in the other
project's build.

Right now I'm using export(TARGETS ... FILE something.cmake) in project
1 which gives me everything I need (a file I can include in the other
build). 

With the exception of not knowing targets I have to consider. Project 1
can freely define one or more targets with any name. I need to consider
all of them in the project 2.

How can I do it nicely?

Currently I'm thinking of adding manually a variable containing a list
of all targets to "something.cmake" once created with export.

Thanks,
--
Patrick.
-- 

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] Performance issues on very large project

[Patrick Boettcher]

Hi,

On Tue, 5 Apr 2016 23:18:41 -0500
Steven Stallion  wrote:

> All,
> 
> I am currently working on a very large project that contains over 500
> (yes, really) listfiles. A co-worker was looking into some performance
> issues we were seeing during configuration and found something very
> interesting. Currently configuration is taking 1m57s across several
> configurations using Mac OS X as a host and the latest .dmg from
> cmake.org (3.5.1).
> 
> We have a core module that provides a number of helper functions and
> macros (completely stateless) that is included by most of this
> listfiles (nearly 400 of them). We found that an include guard was
> missing, after adding that configuration now clocks in at 1m30s.
> 
> Taking things a step further, we removed includes of the module, and
> simply included it once in the top-level listfile. Configuration then
> dropped to about 55s.
> 
> The results above seem to indicate a possible file I/O bottleneck.
> This is very surprising to me - these builds are being run on recent
> core-i7's with SSDs. Is anyone else on the list dealing with large
> projects or similar configuration issues?

LLVM/Clang is using ~330 CMakeLists.txt - I never noticed the
config-step to be a bottleneck (cmake ../llvm takes 10 seconds on my
system). But LLVM/Clang is not including a lot of Modules.

real0m10.551s
user0m6.696s
sys 0m1.576s

Maybe it is more a question of LOC of than the number of files.

regards,
--
Patrick.
-- 

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] cross-compilation: add dependency to all linked targets

[Patrick Boettcher]

Hi list,

I'm building applications for an bare-metal sytem. There
are no standard libraries.

In my toolchain-file I specify 

  set(CMAKE_SYSTEM_NAME "Generic")

and I'm telling gcc to not include std-libraries with -nostdlib .

In my toolchain-file I changed 

  CMAKE_EXE_LINKER_FLAGS

in order to link with my LdScript and to add basic stuff during link.
A crt0 for my platform myself and other stuff in the future.

Is there a way to add a dependency to (existing) files in a generic
manner so that all executable- and library-targets are getting a
link-dependency?

Like a system-library-template-variable to fill in.

Thanks in advance for any help.

best regards,
--
Patrick.







-- 

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] Good practice: using INTERFACE-libraries in FindABC.cmake?

[Patrick Boettcher]

On Mon, 29 Feb 2016 21:20:59 +0100
Stephen Kelly <steve...@gmail.com> wrote:

> Patrick Boettcher wrote:
> 
> > I came across the INTERFACE-type of libraries when writing a
> > FindModule.cmake-file for custom libraries installed by my
> > project.  
> 
> You don't provide FindModules for your CMake-built libraries. 

Thank you for the pointer. I wasn't aware of it and haven't entirely
understood it yet.

However, when I said 'for custom libraries installed by my project' I
was not referring to cmake-based projects. These libraries are used as
is and for the moment I don't want to integrate them via ExternalProject.

--
Patrick.
-- 

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] Good practice: using INTERFACE-libraries in FindABC.cmake?

[Patrick Boettcher]

Hi list,

I came across the INTERFACE-type of libraries when writing a
FindModule.cmake-file for custom libraries installed by my
project.

Here is what I'm doing after having found the libraries and the
determined the paths: LIB1 is the library and LIB1_INCLUDE_DIRS its
include-dirs:

  add_library(name INTERFACE)

  target_link_libraries(name INTERFACE ${LIB1})

  if(FFTW3_FOUND)
target_include_directories(name INTERFACE
{$FFTW3_INCLUDE_DIRS})
target_link_libraries(name INTERFACE ${FFTW3_LIBRARIES} )
  endif()

  target_include_directories(name INTERFACE ${LIB1_INCLUDE_DIRS})

  # need c++11 compile options for if-name
  set_property(TARGET name PROPERTY
INTERFACE_COMPILE_FEATURES cxx_range_for)

This makes that in the CMakeLists.txt which includes my package-file a
user needing libname for his executable does:

  add_executable(main main.cpp)
  target_link_libraries(main name)

This will 

1) set C++11 flags for compilation
2) set the right include-pathes
3) link with the right libraries as per my order

Awesome. But is this a good practice? Are there any pitfalls?

Thank you for your help in advance.

best regards,
--
Patrick.
-- 

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