I've started to use CMake a quite long time ago, and do not search for
"standards" or "guidelines" anymore %)
But I could mention some chapters in the official documentation (in the
"Reference Manuals" section) which are really full of "secret knowledge",
but the problem is that they are too
Hi Robert,
On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey
wrote:
>
> One problem I thought of with the former (one big target.cmake with
> all import targets in there) is that if you only ask for a subset of
> components in find_package(), you will still get all of
On Fri, Sep 1, 2017 at 1:40 PM, Alex Turbov wrote:
> Hi Robert,
>
>
> On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey
> wrote:
>>
>>
>> One problem I thought of with the former (one big target.cmake with
>> all import targets in there) is that if you
First of all, I want to apologize for including the developer list.
Maybe I'm not being patient enough, but it seems like every post I've
made on the normal users list doesn't get any attention.
Secondly, the cmake-packages portion of the cmake documentation
doesn't go into a ton of detail about
I think your analysis is correct.
You could try doing a ctest_submit after each ctest_test call. Not
sure if you could get "correct" results with that technique. I run
some scripts that do something similar without subproject involved,
and it mostly works, but messes up the +/- tests passed and
Hi all,
I've been having some success with CTest and am interested in using
CDash as well.
In order to generate some nice output, sub projects seem to be the best
way of presenting the data in CDash for our setup. This setup is perhaps
summed up by having one projects that contains a few