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  wrote:

> On Wed, May 17, 2017 at 2:55 AM, Patrick Boettcher
> > 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] CTest question

[Eric Noulard]

We lack information on how your test are failing. If they all timeout then
may be you should setup a proper timeout for the test. The actual execution
speed of a test may depend on the load of your machine or the network
(depending on what the test are actually doing).
This may be even more sensible if your test are run in parallel. Do you run
ctest with --parallel option?

Do your tests depends on each other? If so did you setup test dependencies?

Le 17 mai 2017 10:59 PM, "T.Sariyski"  a écrit :

> Hi,
>
>
>
> I wonder what is the reason that sometimes ctest ends with numerous
> ‘Failed’ and ‘Timeout’, which ‘ctest –rerun-failed’ reports ‘Passed’. At
> times the number of these false failures is about one third. I guess that
> the problem is in the way I set my tests, but I have no clue where to look,
> or how to ‘debug’ the ctest run.
>
> Any advice is highly appreciated.
>
>
>
> Thanks,
>
> Ted
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] RPATH for external library

[Pawel Veselov]

On Wed, May 17, 2017 at 2:55 AM, Patrick Boettcher
> 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.

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.

[skipped]
-- 

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] ctest test run order

[Juan E. Sanchez]

I remember that the longest tests used to run first.  Now they seem to 
run in a random order on Windows, Mac, Linux.


Is this the expected behavior?  How can I get longest test first?

Regards,

Juan
--

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

[Robert Maynard]

No you would set the properties on ExeA and ExeB and that would effect the
target_link_library generation for the interface library I

I have written an example that drops the Foo libraries as they aren't
needed to show my example.

https://github.com/robertmaynard/Sandbox/blob/master/CMakeInterfaceChangesLibrary/CMakeLists.txt

On Wed, May 17, 2017 at 5:15 PM, 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 ^_^
>
> Thanks for the input, though!
>
> Etan
>
> On 17 May 2017, at 18:49, Robert Maynard 
> wrote:
>
> I have a feeling that you could do this with generator expressions. You
> would have the interface link line for I have a generator expression that
> switches between IA and IB. Than you would setup ExeA and ExeB to trigger
> this switch. Maybe using something like $?
>
> On Wed, May 17, 2017 at 8:28 AM, Etan Kissling  wrote:
>
>> Hi, and thanks for the quick reaction :-)
>>
>> The approach with forward declaration looks interesting. However, I don't
>> think that it will resolve all the problems.
>>
>> One issue is that there are multiple apps, each using separate
>> implementations.
>> • ExeA uses the generic libraries Foo and Bar, as well as the **IA**
>> implementation of interface library I.
>> • ExeB uses the generic libraries Foo and Bar, as well as the **IB**
>> implementation of interface library I.
>>
>> On top of that, I'd like to be able to build Foo and Bar independently as
>> static libraries, without IA or IB being present.
>>
>> Is it possible to replace references to interface library I with
>> implementation IA, but only while ExeA is being compiled, and vice versa
>> for ExeB?
>> There are only static libraries involved, so the compilation of Foo / Bar
>> should be the same in both cases.
>>
>> Thanks
>>
>> Etan
>>
>>
>>
>> > On 16 May 2017, at 10:39, Patrick Boettcher <
>> patrick.boettc...@posteo.de> wrote:
>> >
>> > 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 dependenc

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

[David Cole via CMake]

The way I know how to do this is to add it last at the bottom of the
top-level CMakeLists.txt file, and then use add_dependencies to make
it depend on all other targets. (Or at least all other "leaf" targets,
which further depend on others, ... the sum of which is "all other
targets" besides the new "last" target.)

So it's not pretty, but it's possible.


HTH,
David C.



On Wed, May 17, 2017 at 11:36 AM, 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!
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Link order and interface multiplicity

[Etan Kissling]

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 ^_^

Thanks for the input, though!

Etan

On 17 May 2017, at 18:49, Robert Maynard 
mailto:robert.mayn...@kitware.com>> wrote:

I have a feeling that you could do this with generator expressions. You would 
have the interface link line for I have a generator expression that switches 
between IA and IB. Than you would setup ExeA and ExeB to trigger this switch. 
Maybe using something like $?

On Wed, May 17, 2017 at 8:28 AM, Etan Kissling 
mailto:kissl...@oberon.ch>> wrote:
Hi, and thanks for the quick reaction :-)

The approach with forward declaration looks interesting. However, I don't think 
that it will resolve all the problems.

One issue is that there are multiple apps, each using separate implementations.
* ExeA uses the generic libraries Foo and Bar, as well as the **IA** 
implementation of interface library I.
* ExeB uses the generic libraries Foo and Bar, as well as the **IB** 
implementation of interface library I.

On top of that, I'd like to be able to build Foo and Bar independently as 
static libraries, without IA or IB being present.

Is it possible to replace references to interface library I with implementation 
IA, but only while ExeA is being compiled, and vice versa for ExeB?
There are only static libraries involved, so the compilation of Foo / Bar 
should be the same in both cases.

Thanks

Etan



> On 16 May 2017, at 10:39, Patrick Boettcher 
> mailto:patrick.boettc...@posteo.de>> wrote:
>
> Hi,
>
> On Mon, 15 May 2017 12:30:10 +
> Etan Kissling mailto:kissl...@oberon.ch>> 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

[CMake] CTest question

[T.Sariyski]

Hi,

 

I wonder what is the reason that sometimes ctest ends with numerous ‘Failed’ 
and ‘Timeout’, which ‘ctest –rerun-failed’ reports ‘Passed’. At times the 
number of these false failures is about one third. I guess that the problem is 
in the way I set my tests, but I have no clue where to look, or how to ‘debug’ 
the ctest run.

Any advice is highly appreciated.

 

Thanks,

Ted

-- 

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

[Robert Maynard]

I have a feeling that you could do this with generator expressions. You
would have the interface link line for I have a generator expression that
switches between IA and IB. Than you would setup ExeA and ExeB to trigger
this switch. Maybe using something like $?

On Wed, May 17, 2017 at 8:28 AM, Etan Kissling  wrote:

> Hi, and thanks for the quick reaction :-)
>
> The approach with forward declaration looks interesting. However, I don't
> think that it will resolve all the problems.
>
> One issue is that there are multiple apps, each using separate
> implementations.
> • ExeA uses the generic libraries Foo and Bar, as well as the **IA**
> implementation of interface library I.
> • ExeB uses the generic libraries Foo and Bar, as well as the **IB**
> implementation of interface library I.
>
> On top of that, I'd like to be able to build Foo and Bar independently as
> static libraries, without IA or IB being present.
>
> Is it possible to replace references to interface library I with
> implementation IA, but only while ExeA is being compiled, and vice versa
> for ExeB?
> There are only static libraries involved, so the compilation of Foo / Bar
> should be the same in both cases.
>
> Thanks
>
> Etan
>
>
>
> > On 16 May 2017, at 10:39, Patrick Boettcher 
> wrote:
> >
> > 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
>
-- 

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 ea

[CMake] Force target to always run last?

[Robert Dailey]

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!
-- 

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] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)

[René J . V . Bertin]

Volker Enderlein wrote:

Hi,

Thanks, that helps. With there is maybe something to learn from the CMake 
sources, too.

R.

> Hello,
> 
> according to https://sourceforge.net/p/predef/wiki/Compilers/ you could
> check with
> 
> check_cxx_source_compiles("
>  #if defined (_MSC_VER) && (_MSC_VER == 1900) && (_MSC_FULL_VER ==
> 190024210)
>  #else
>#error compiler is not MSVC Update3
>  #endif
>  int main() {
>  return 0;
>  }
> " MSVC_UPDATE3_FOUND)
> 
> for the requested feature.
> 
> HTH, Cheers, Volker
> 
> 
> Am 15/05/2017 um 14:56 schrieb René J.V. Bertin:
>> Hello,
>>
>> A question that will hopefully have a quick/easy answer:
>>
>> I'd like to detect when the MSVC /fpermissive- (yes, that's a dash at the
>> end) can be used instead of /Za . I know that a later update bumped the
>> version to 14.0.25422.01 and thus undoubtedly _MSC_FULL_VER== 1402542201 in C
>> code so I could assume everyone keeps installs their updates and use that
>> value.
>>
>> But what does this translate to in CMake code (MSVC_VERSION)? Probably not
>> just 1903 I presume?
>>
>> Thanks,
>> René
> 


-- 

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

[Etan Kissling]

Hi, and thanks for the quick reaction :-)

The approach with forward declaration looks interesting. However, I don't think 
that it will resolve all the problems.

One issue is that there are multiple apps, each using separate implementations.
• ExeA uses the generic libraries Foo and Bar, as well as the **IA** 
implementation of interface library I.
• ExeB uses the generic libraries Foo and Bar, as well as the **IB** 
implementation of interface library I.

On top of that, I'd like to be able to build Foo and Bar independently as 
static libraries, without IA or IB being present.

Is it possible to replace references to interface library I with implementation 
IA, but only while ExeA is being compiled, and vice versa for ExeB? 
There are only static libraries involved, so the compilation of Foo / Bar 
should be the same in both cases.

Thanks

Etan



> On 16 May 2017, at 10:39, Patrick Boettcher  
> wrote:
> 
> 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] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)

[Volker Enderlein]

Hello,

according to https://sourceforge.net/p/predef/wiki/Compilers/ you could 
check with


check_cxx_source_compiles("
#if defined (_MSC_VER) && (_MSC_VER == 1900) && (_MSC_FULL_VER == 
190024210)

#else
  #error compiler is not MSVC Update3
#endif
int main() {
return 0;
}
" MSVC_UPDATE3_FOUND)

for the requested feature.

HTH, Cheers, Volker


Am 15/05/2017 um 14:56 schrieb René J.V. Bertin:

Hello,

A question that will hopefully have a quick/easy answer:

I'd like to detect when the MSVC /fpermissive- (yes, that's a dash at the end) 
can be used instead of /Za . I know that a later update bumped the version to 
14.0.25422.01 and thus undoubtedly _MSC_FULL_VER== 1402542201 in C code so I 
could assume everyone keeps installs their updates and use that value.

But what does this translate to in CMake code (MSVC_VERSION)? Probably not just 
1903 I presume?

Thanks,
René


--

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] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)

[René J . V . Bertin]

René J.V. Bertin wrote:

Bump. No one who can help here?

-- 

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