From rjvbertin at gmail.com  Tue Jan  3 09:21:28 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 03 Jan 2017 15:21:28 +0100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
Message-ID: <2723217.JG0fgKC0bN@portia.local>

Hi,

I just had a run-in with a CMake file from Qt5 in a project I've been building with a locally built Clang 3.9 version, affectionately called clang-mp-3.9 . I got the cryptic message

 CMake Error in src/platformtheme/CMakeLists.txt:
   No known features for CXX compiler

   "Clang"

   version 3.9.0.


Would you consider adding support for non-Apple clang versions on Mac too, and who would best request that, a Qt dev who considers the cxx_decltype test crucial, or the 1st user for whom that breaks his builds (i.e. me)?

I see this has already come up for HB:
https://cmake.org/pipermail/cmake/2016-December/064719.html


Thanks,
Ren? Bertin

From robert.maynard at kitware.com  Tue Jan  3 10:02:44 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 3 Jan 2017 10:02:44 -0500
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <2723217.JG0fgKC0bN@portia.local>
References: <2723217.JG0fgKC0bN@portia.local>
Message-ID: <CAFzjYVp4O+7mHLXd8ipBz88QXowQe1H+CcedP+Bte3fYAHSavA@mail.gmail.com>

The problem that was reported in that other thread was due to having
policy CMP0025 set to a false value, once that policy was enabled
compiler detection worked properly.

I would make sure the same isn't happening for you.

I have attached a simple CMakeList.txt file you can use to determine
if potentially you are seeing the same policy issue.



On Tue, Jan 3, 2017 at 9:21 AM, Ren? J.V. Bertin <rjvbertin at gmail.com> wrote:
> Hi,
>
> I just had a run-in with a CMake file from Qt5 in a project I've been building with a locally built Clang 3.9 version, affectionately called clang-mp-3.9 . I got the cryptic message
>
>  CMake Error in src/platformtheme/CMakeLists.txt:
>    No known features for CXX compiler
>
>    "Clang"
>
>    version 3.9.0.
>
>
> Would you consider adding support for non-Apple clang versions on Mac too, and who would best request that, a Qt dev who considers the cxx_decltype test crucial, or the 1st user for whom that breaks his builds (i.e. me)?
>
> I see this has already come up for HB:
> https://cmake.org/pipermail/cmake/2016-December/064719.html
>
>
> Thanks,
> Ren? Bertin
> --
>
> 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
-------------- next part --------------

cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR)
cmake_policy(SET CMP0025 NEW)

project(t C CXX)

cmake_policy(GET CMP0025 appleClangPolicy)
if(NOT appleClangPolicy STREQUAL NEW)
  message(STATUS "cmake_determine_compile_features was not enabled as policy 0025 needs to be set to NEW")
endif()

message(STATUS "CMAKE_CXX_COMPILE_FEATURES: ${CMAKE_CXX_COMPILE_FEATURES}")

From rjvbertin at gmail.com  Tue Jan  3 10:26:52 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 03 Jan 2017 16:26:52 +0100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <CAFzjYVp4O+7mHLXd8ipBz88QXowQe1H+CcedP+Bte3fYAHSavA@mail.gmail.com>
References: <2723217.JG0fgKC0bN@portia.local>
 <CAFzjYVp4O+7mHLXd8ipBz88QXowQe1H+CcedP+Bte3fYAHSavA@mail.gmail.com>
Message-ID: <1596195.QUDJkKmZPp@bola>

On Tuesday January 3 2017 10:02:44 Robert Maynard wrote:

Hi,

Thanks for the sample CMake file!

It appears indeed that the policy defaulting to OLD is the culprit here: setting it to NEW at an appropriate location (and throwing out build.dir/CMake*) makes detection work properly. Surprised me a bit TBH; a casual read (and unburdened with prior knowledge) of the CMP0025 doc seems to suggest that the opposite would happen.

That almost begs the question what you're waiting for to make the new setting the default. :)
Maybe there's a way to toggle it locally, so that it doesn't have to be set in every project that may need to be built with a non-Apple clang version?

Cheers,
Ren? Bertin

>The problem that was reported in that other thread was due to having
>policy CMP0025 set to a false value, once that policy was enabled
>compiler detection worked properly.
>
>I would make sure the same isn't happening for you.
>
>I have attached a simple CMakeList.txt file you can use to determine
>if potentially you are seeing the same policy issue.
>
>
>
>On Tue, Jan 3, 2017 at 9:21 AM, Ren? J.V. Bertin <rjvbertin at gmail.com> wrote:
>> Hi,
>>
>> I just had a run-in with a CMake file from Qt5 in a project I've been building with a locally built Clang 3.9 version, affectionately called clang-mp-3.9 . I got the cryptic message
>>
>>  CMake Error in src/platformtheme/CMakeLists.txt:
>>    No known features for CXX compiler
>>
>>    "Clang"
>>
>>    version 3.9.0.
>>
>>
>> Would you consider adding support for non-Apple clang versions on Mac too, and who would best request that, a Qt dev who considers the cxx_decltype test crucial, or the 1st user for whom that breaks his builds (i.e. me)?
>>
>> I see this has already come up for HB:
>> https://cmake.org/pipermail/cmake/2016-December/064719.html
>>
>>
>> Thanks,
>> Ren? Bertin
>> --
>>
>> 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


From robert.maynard at kitware.com  Tue Jan  3 10:36:54 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 3 Jan 2017 10:36:54 -0500
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <1596195.QUDJkKmZPp@bola>
References: <2723217.JG0fgKC0bN@portia.local>
 <CAFzjYVp4O+7mHLXd8ipBz88QXowQe1H+CcedP+Bte3fYAHSavA@mail.gmail.com>
 <1596195.QUDJkKmZPp@bola>
Message-ID: <CAFzjYVrgu5KZc5eo=nHe7c2+reNi-2_iZpGTFbt_p0wwem4uSQ@mail.gmail.com>

The minimum cmake version of each project controls the default state
of the policies. So for policy 25 you need a minimum of CMake 3.0.

This is partially a moot point, because compiler feature detection was
added in CMake 3.0, so if you are expecting that feature to exist you
should be requiring CMake 3.0.

On Tue, Jan 3, 2017 at 10:26 AM, Ren? J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Tuesday January 3 2017 10:02:44 Robert Maynard wrote:
>
> Hi,
>
> Thanks for the sample CMake file!
>
> It appears indeed that the policy defaulting to OLD is the culprit here: setting it to NEW at an appropriate location (and throwing out build.dir/CMake*) makes detection work properly. Surprised me a bit TBH; a casual read (and unburdened with prior knowledge) of the CMP0025 doc seems to suggest that the opposite would happen.
>
> That almost begs the question what you're waiting for to make the new setting the default. :)
> Maybe there's a way to toggle it locally, so that it doesn't have to be set in every project that may need to be built with a non-Apple clang version?
>
> Cheers,
> Ren? Bertin
>
>>The problem that was reported in that other thread was due to having
>>policy CMP0025 set to a false value, once that policy was enabled
>>compiler detection worked properly.
>>
>>I would make sure the same isn't happening for you.
>>
>>I have attached a simple CMakeList.txt file you can use to determine
>>if potentially you are seeing the same policy issue.
>>
>>
>>
>>On Tue, Jan 3, 2017 at 9:21 AM, Ren? J.V. Bertin <rjvbertin at gmail.com> wrote:
>>> Hi,
>>>
>>> I just had a run-in with a CMake file from Qt5 in a project I've been building with a locally built Clang 3.9 version, affectionately called clang-mp-3.9 . I got the cryptic message
>>>
>>>  CMake Error in src/platformtheme/CMakeLists.txt:
>>>    No known features for CXX compiler
>>>
>>>    "Clang"
>>>
>>>    version 3.9.0.
>>>
>>>
>>> Would you consider adding support for non-Apple clang versions on Mac too, and who would best request that, a Qt dev who considers the cxx_decltype test crucial, or the 1st user for whom that breaks his builds (i.e. me)?
>>>
>>> I see this has already come up for HB:
>>> https://cmake.org/pipermail/cmake/2016-December/064719.html
>>>
>>>
>>> Thanks,
>>> Ren? Bertin
>>> --
>>>
>>> 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
>

From rjvbertin at gmail.com  Tue Jan  3 11:29:37 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 03 Jan 2017 17:29:37 +0100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <CAFzjYVrgu5KZc5eo=nHe7c2+reNi-2_iZpGTFbt_p0wwem4uSQ@mail.gmail.com>
References: <2723217.JG0fgKC0bN@portia.local> <1596195.QUDJkKmZPp@bola>
 <CAFzjYVrgu5KZc5eo=nHe7c2+reNi-2_iZpGTFbt_p0wwem4uSQ@mail.gmail.com>
Message-ID: <1585933.6JRZW131YN@portia.local>

On Tuesday January 03 2017 10:36:54 Robert Maynard wrote:

That's all nice and well but a bit delicate to expect from an unknown number of project to adapt their minimum required CMake version for a policy they probably don't even know they require.


> The minimum cmake version of each project controls the default state
> of the policies. So for policy 25 you need a minimum of CMake 3.0.
> This is partially a moot point, because compiler feature detection was
> added in CMake 3.0, so if you are expecting that feature to exist you
> should be requiring CMake 3.0.

Maybe, indeed, but that becomes a much less trivial point if the policy becomes necessary somewhere hidden deep in a module that's loaded somewhere well into running cmake. How is the user supposed to understand what happens from the error message?

The point would be moot if the minimum required cmake version could be adjusted whenever necessary, or policy 25 could be set when required.
Or indeed if a cmake installation can be configured locally to set a policy, or to apply a limit to how far back the minimum required version can be set.

R.


From robert.maynard at kitware.com  Tue Jan  3 11:41:29 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 3 Jan 2017 11:41:29 -0500
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <1585933.6JRZW131YN@portia.local>
References: <2723217.JG0fgKC0bN@portia.local> <1596195.QUDJkKmZPp@bola>
 <CAFzjYVrgu5KZc5eo=nHe7c2+reNi-2_iZpGTFbt_p0wwem4uSQ@mail.gmail.com>
 <1585933.6JRZW131YN@portia.local>
Message-ID: <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>

On Tue, Jan 3, 2017 at 11:29 AM, Ren? J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Tuesday January 03 2017 10:36:54 Robert Maynard wrote:
>
> That's all nice and well but a bit delicate to expect from an unknown number of project to adapt their minimum required CMake version for a policy they probably don't even know they require.
>
>
>> The minimum cmake version of each project controls the default state
>> of the policies. So for policy 25 you need a minimum of CMake 3.0.
>> This is partially a moot point, because compiler feature detection was
>> added in CMake 3.0, so if you are expecting that feature to exist you
>> should be requiring CMake 3.0.
>
> Maybe, indeed, but that becomes a much less trivial point if the policy becomes necessary somewhere hidden deep in a module that's loaded somewhere well into running cmake. How is the user supposed to understand what happens from the error message?

It is the responsibility of the project to understand what components
of CMake they require, and correctly specify a cmake_minimum required
that satisfies all those requirements. In this case to use compile
features you need a minimum of 3.0 which also automatically enables
policy 25.

>
> The point would be moot if the minimum required cmake version could be adjusted whenever necessary, or policy 25 could be set when required.

You can explicitly do both of those things currently see:
https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

> Or indeed if a cmake installation can be configured locally to set a policy, or to apply a limit to how far back the minimum required version can be set.
>
> R.
>

From rjvbertin at gmail.com  Tue Jan  3 12:12:30 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 03 Jan 2017 18:12:30 +0100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>
References: <2723217.JG0fgKC0bN@portia.local> <1585933.6JRZW131YN@portia.local>
 <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>
Message-ID: <2141885.DSta7uvqJE@portia.local>

On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:

> It is the responsibility of the project to understand what components
> of CMake they require, and correctly specify a cmake_minimum required
> that satisfies all those requirements. In this case to use compile
> features you need a minimum of 3.0 which also automatically enables
> policy 25.

I agree with you in a way, but in reality it would be up to end users and packagers to feed back that information to an unknown number of projects and convince them why it's necessary to comply with the request. That's just not doable.
It would be a lot easier if the policy could be set at a central location, in this case in the Qt module invoking the test that fails.


And it's CMake's responsibility to generate useful error messages, and where possible provide a hint for the fix.

> You can explicitly do both of those things currently see:
> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

Ah, thanks. I take it one can also change a line in cmPolicies.h:

  SELECT(POLICY, CMP0025, "Compiler id for Apple Clang is now AppleClang.",   \
         3, 0, 0, cmPolicies::NEW)                                           \

?

R.

From paul.wilkinson at cmedrobotics.com  Mon Jan  2 18:27:01 2017
From: paul.wilkinson at cmedrobotics.com (Paul Wilkinson)
Date: Mon, 2 Jan 2017 23:27:01 +0000
Subject: [cmake-developers] Creating a Keil uVision generator
Message-ID: <VI1PR07MB086334BAC030F0B047EAA92EED6F0@VI1PR07MB0863.eurprd07.prod.outlook.com>

Hi all,

I am involved in a software project targeting a handful of ARM Cortex-M
microcontrollers. We develop the software using the Keil uVision v5 IDE [1]. We
are considering whether CMake could help us with some of the limitations we
encounter using uVision alone.

Does anyone have experience or insight in to creating a CMake generator for an
embedded systems IDE like uVision?

Read on for some technical details.

A uVision project's structure appears _roughly_ similar to a Microsoft Visual
Studio 12 project. uVision has a Multi-Project Workspace (.uvmpw) rather than a
VS solution (.sln), and a uVision Project (.uvprojx) instead of a VS project
(.vcxproj).

One notable difference in the XML schemas: in uVision, the source file elements
are a child of the target elements (a uVision "target" is comparable to a VS
"configuration"), in contrast to VS's approach where a configuration-specific
option is a child of the source file element and has a "Condition" attribute.

As with the Visual Studio generators, a generator for uVision projects would
ideally be a multi-configuration generator.

I expect there are many concepts in CMake that wouldn't map to a uVision option,
and vice-versa. For example the "Packs" system used by uVision might not mesh
well with what CMake understands as a library. For my limited requirements -- a
single project workspace, where the project consists of exactly one executable
and no libraries other than some third-party libraries passed to linker -- I
expect we could make do with a skeleton/template .uvprojx and the CMake
generator would fill in the gaps for the source files.

Some of the benefits I would imagine we would get from such a generator:

- more human-friendly and diff-friendly project files (CMakeLists.txt instead
  of .uvprojx)

- avoiding a combinatorial explosion of configurations by using the CMake
  language and its cache variables.

[1] http://www2.keil.com/mdk5/uvision/

Thanks,
Paul Wilkinson
http://www.cmedrobotics.com/
________________________________

This e-mail message is confidential and for use by the addressee only. If you are not the intended recipient, you must not use, disclose, copy or forward this transmission. Please return the message to the sender by replying to it and then delete the message from your computer. Cambridge Medical Robotics shall not be held liable to any person resulting from the use of any information contained in this e-mail and shall not be liable to any person who acts or omits to do anything in reliance upon it. Cambridge Medical Robotics does not accept responsibility for changes made to this message after it was sent.

Company Information:
Name: Cambridge Medical Robotics Limited.
Registered Address: Unit 2, Crome Lea Business Park, Madingley Road, Cambridge, CB23 7PH, UK.
Registered as a Company in England: 08863657 VAT Number: GB 186 4383 74.
info at cmedrobotics.com

From robert.maynard at kitware.com  Tue Jan  3 13:43:40 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 3 Jan 2017 13:43:40 -0500
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <2141885.DSta7uvqJE@portia.local>
References: <2723217.JG0fgKC0bN@portia.local> <1585933.6JRZW131YN@portia.local>
 <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>
 <2141885.DSta7uvqJE@portia.local>
Message-ID: <CAFzjYVqWThUsM_-0t9dFgmdb1y2pDniBLTTztKQDXn_Kop2C_w@mail.gmail.com>

I doubt the change to cmPolicies.h would do as you expect, as the
logic to set a policy to a given state ( OLD,WARN,NEW ) is actually
done by cmPolicies::ApplyPolicyVersion.

Now as far as how Qt5 is operating, personally I agree it would be
nice that the module would provide better warnings or errors, instead
they have just documented these issues on their cmake page:
http://doc.qt.io/qt-5/cmake-manual.html

On Tue, Jan 3, 2017 at 12:12 PM, Ren? J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:
>
>> It is the responsibility of the project to understand what components
>> of CMake they require, and correctly specify a cmake_minimum required
>> that satisfies all those requirements. In this case to use compile
>> features you need a minimum of 3.0 which also automatically enables
>> policy 25.
>
> I agree with you in a way, but in reality it would be up to end users and packagers to feed back that information to an unknown number of projects and convince them why it's necessary to comply with the request. That's just not doable.
> It would be a lot easier if the policy could be set at a central location, in this case in the Qt module invoking the test that fails.
>
>
> And it's CMake's responsibility to generate useful error messages, and where possible provide a hint for the fix.
>
>> You can explicitly do both of those things currently see:
>> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html
>
> Ah, thanks. I take it one can also change a line in cmPolicies.h:
>
>   SELECT(POLICY, CMP0025, "Compiler id for Apple Clang is now AppleClang.",   \
>          3, 0, 0, cmPolicies::NEW)                                           \
>
> ?
>
> R.

From rjvbertin at gmail.com  Tue Jan  3 14:26:25 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 03 Jan 2017 20:26:25 +0100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>
References: <2723217.JG0fgKC0bN@portia.local> <1585933.6JRZW131YN@portia.local>
 <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>
Message-ID: <2972424.5Cn09d4kNK@portia.local>

On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:

> You can explicitly do both of those things currently see:
> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

Are you sure about the minimum required version? I cannot seem to have any luck with `-DCMAKE_MINIMUM_REQUIRED_VERSION=3.0`.

R.


From robert.maynard at kitware.com  Tue Jan  3 14:27:40 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 3 Jan 2017 14:27:40 -0500
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <2972424.5Cn09d4kNK@portia.local>
References: <2723217.JG0fgKC0bN@portia.local> <1585933.6JRZW131YN@portia.local>
 <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>
 <2972424.5Cn09d4kNK@portia.local>
Message-ID: <CAFzjYVrSMbeRd3f6L+U5Ar5McZ_hfPQGCPM-yRhpZTcvn0q=GA@mail.gmail.com>

Sorry I wasn't clear. I mean the cmake_minimum_required command (
https://cmake.org/cmake/help/v3.0/command/cmake_minimum_required.html
)

On Tue, Jan 3, 2017 at 2:26 PM, Ren? J.V. Bertin <rjvbertin at gmail.com>
wrote:

> On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:
>
> > You can explicitly do both of those things currently see:
> > https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html
>
> Are you sure about the minimum required version? I cannot seem to have any
> luck with `-DCMAKE_MINIMUM_REQUIRED_VERSION=3.0`.
>
> R.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170103/b626d9e3/attachment.html>

From rjvbertin at gmail.com  Tue Jan  3 14:49:01 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 03 Jan 2017 20:49:01 +0100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <CAFzjYVrSMbeRd3f6L+U5Ar5McZ_hfPQGCPM-yRhpZTcvn0q=GA@mail.gmail.com>
References: <2723217.JG0fgKC0bN@portia.local> <2972424.5Cn09d4kNK@portia.local>
 <CAFzjYVrSMbeRd3f6L+U5Ar5McZ_hfPQGCPM-yRhpZTcvn0q=GA@mail.gmail.com>
Message-ID: <3272629.CleqpXTdn0@portia.local>

On Tuesday January 03 2017 14:27:40 Robert Maynard wrote:

Well, that has to be set in every project, or else we'd have to write an initial cache file to be loaded with -C ...

Weird, btw: I just ran into a project that apparently wasn't satisfied with setting only CMP0025 on the commandline. It did set the minimum required version to 2.8.x but that was well after the project() definition, and it seems to be behind the scenes of that call that the compiler features are tested (judging from message(STATUS "here") probes).

Do you know what's happening there, and have any brilliant thoughts how we can prevent this without have to scan each project?

> Sorry I wasn't clear. I mean the cmake_minimum_required command (
> https://cmake.org/cmake/help/v3.0/command/cmake_minimum_required.html
> )


From robert.maynard at kitware.com  Tue Jan  3 15:23:45 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 3 Jan 2017 15:23:45 -0500
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <3272629.CleqpXTdn0@portia.local>
References: <2723217.JG0fgKC0bN@portia.local> <2972424.5Cn09d4kNK@portia.local>
 <CAFzjYVrSMbeRd3f6L+U5Ar5McZ_hfPQGCPM-yRhpZTcvn0q=GA@mail.gmail.com>
 <3272629.CleqpXTdn0@portia.local>
Message-ID: <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>

Any project that isn't setting cmake_minimum_required before calling
project is invoking deprecated behavior of CMake, and is ignoring
Policy CMP0000 (
https://cmake.org/cmake/help/v3.4/policy/CMP0000.html#policy:CMP0000
).

Basically my recommendation is if a project isn't setting
cmake_minimum_required before the first project call than nothing you
can do will fix that, as it is an error.

On Tue, Jan 3, 2017 at 2:49 PM, Ren? J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Tuesday January 03 2017 14:27:40 Robert Maynard wrote:
>
> Well, that has to be set in every project, or else we'd have to write an initial cache file to be loaded with -C ...
>
> Weird, btw: I just ran into a project that apparently wasn't satisfied with setting only CMP0025 on the commandline. It did set the minimum required version to 2.8.x but that was well after the project() definition, and it seems to be behind the scenes of that call that the compiler features are tested (judging from message(STATUS "here") probes).
>
> Do you know what's happening there, and have any brilliant thoughts how we can prevent this without have to scan each project?
>
>> Sorry I wasn't clear. I mean the cmake_minimum_required command (
>> https://cmake.org/cmake/help/v3.0/command/cmake_minimum_required.html
>> )
>

From rjvbertin at gmail.com  Tue Jan  3 15:41:03 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 03 Jan 2017 21:41:03 +0100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>
References: <2723217.JG0fgKC0bN@portia.local> <3272629.CleqpXTdn0@portia.local>
 <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>
Message-ID: <2026573.QpI33mtGQh@portia.local>

On Tuesday January 03 2017 15:23:45 Robert Maynard wrote:

> Basically my recommendation is if a project isn't setting
> cmake_minimum_required before the first project call than nothing you
> can do will fix that, as it is an error.

The issue here is not that the minimum version was NOT being set. Apparently that isn't an issue if I set CMP0025 from the commandline. The issue was a project that requested an earlier CMake version (2.8.something) further down. Apparently that undoes the explicit CMP0025 setting, but not if I execute a cmake_minimum_required(3.0) first.

Either way, I'm getting signals from others using the build system this is about (MacPorts) to please not force a minimum required CMake version, and calling `cmake_minimum_required` in an initial cache file does not have the expected effect.

R.

From steveire at gmail.com  Tue Jan  3 19:43:51 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 04 Jan 2017 00:43:51 +0000
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
References: <2723217.JG0fgKC0bN@portia.local> <3272629.CleqpXTdn0@portia.local>
 <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>
 <2026573.QpI33mtGQh@portia.local>
Message-ID: <o4hgg2$f0g$1@blaine.gmane.org>

Ren? J.V. Bertin wrote:

> The
> issue was a project that requested an earlier CMake version
> (2.8.something) further down. 

There should be no 'further down'. There should be exactly one use of 
cmake_minimum_required per buildsystem. If you are hitting this issue 
because you are cloning random repos and using add_subdirectory, you're 
essentially getting undefined behavior, unless the target repo is designed 
to let you do that. 

That is - some buildsystems check whether they are top-level and only then 
invoke cmake_minimum_required. Something like:

 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
   # Building standalone
   cmake_minimum_required(VERSION 3.3)
   project(Dependency)
 endif()

 add_executable(etc)



if you use add_subdirectory with top-level projects which don't explicitly 
do something like that, you're getting undefined , and generally unexpected 
behavior in many ways.

Thanks,

Steve.



From steveire at gmail.com  Tue Jan  3 19:39:03 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 04 Jan 2017 00:39:03 +0000
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
References: <2723217.JG0fgKC0bN@portia.local> <1585933.6JRZW131YN@portia.local>
 <CAFzjYVrBhyQ91WEwo=nn7AZzbMG=fEiyQm-FxovCUqhrbJQsWw@mail.gmail.com>
 <2141885.DSta7uvqJE@portia.local>
Message-ID: <o4hg72$mba$1@blaine.gmane.org>

Ren? J.V. Bertin wrote:

> On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:
> 
>> It is the responsibility of the project to understand what components
>> of CMake they require, and correctly specify a cmake_minimum required
>> that satisfies all those requirements. In this case to use compile
>> features you need a minimum of 3.0 which also automatically enables
>> policy 25.
> 
> I agree with you in a way, but in reality it would be up to end users and
> packagers to feed back that information to an unknown number of projects
> and convince them why it's necessary to comply with the request. That's
> just not doable. It would be a lot easier if the policy could be set at a
> central location, in this case in the Qt module invoking the test that
> fails.
> 
> 
> And it's CMake's responsibility to generate useful error messages, and
> where possible provide a hint for the fix.

Usually CMake does. CMP0025 is a bit unique (perhaps to a fault) in that it 
does not. Look at its docs.

Thanks,

Steve.
 


From craig.scott at crascit.com  Tue Jan  3 20:12:46 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 4 Jan 2017 12:12:46 +1100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <o4hgg2$f0g$1@blaine.gmane.org>
References: <2723217.JG0fgKC0bN@portia.local> <3272629.CleqpXTdn0@portia.local>
 <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>
 <2026573.QpI33mtGQh@portia.local> <o4hgg2$f0g$1@blaine.gmane.org>
Message-ID: <CA+dygY=FNgsCCWWf-fgOoB7xf18kmBJEtFwkWwXopci8PZjTfg@mail.gmail.com>

On Wed, Jan 4, 2017 at 11:43 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Ren? J.V. Bertin wrote:
>
> > The
> > issue was a project that requested an earlier CMake version
> > (2.8.something) further down.
>
> There should be no 'further down'. There should be exactly one use of
> cmake_minimum_required per buildsystem. If you are hitting this issue
> because you are cloning random repos and using add_subdirectory, you're
> essentially getting undefined behavior, unless the target repo is designed
> to let you do that.
>
> That is - some buildsystems check whether they are top-level and only then
> invoke cmake_minimum_required. Something like:
>
>  if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
>    # Building standalone
>    cmake_minimum_required(VERSION 3.3)
>    project(Dependency)
>  endif()
>
>  add_executable(etc)
>
>
>
> if you use add_subdirectory with top-level projects which don't explicitly
> do something like that, you're getting undefined , and generally unexpected
> behavior in many ways.
>

This seems at odds with the CMake documentation for
cmake_minimum_required(). That documentation talks about calling
cmake_minimum_required() within a function as a valid case, which is
obviously not going to be at the start of a top level CMakeLists.txt file.
I see no reason why having multiple calls to cmake_minimum_required()
shouldn't work. Yes, each one will alter the policy behaviour for that
scope and below, but assuming that's what the project wanted to enforce,
this should be fine.

We have many projects which do exactly the scenario you mention above where
a project can be built standalone or added to another project via
add_subdirectory(). We have not found it necessary to test if a project is
top level or not before calling cmake_minimum_required(). The behaviour is
well-defined and performs as per the documentation in regard to policies
and minimum CMake versions as far as we've observed. Can you point me/us at
documentation or code which shows why this should be considered undefined
behaviour? I'm particularly interested in this case since we use it
frequently in production.

Also, in case it is of interest, in a hierarchical project arrangement
where another project is brought in via add_subdirectory, the
CMAKE_POLICY_DEFAULT_CMPNNNN
<https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_DEFAULT_CMPNNNN.html>
variable
can be used to alter the default for a policy so that if that sub-project
specifies an older version in its cmake_minimum_required(), the
driving/main project can still influence its behaviour without requiring
changes to that sub-project. Not ideal, but I've had at least one
legitimate case where this was useful (dealing with warnings associated
with CMP0048 <https://cmake.org/cmake/help/latest/policy/CMP0048.html>).


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170104/46a9618e/attachment.html>

From konstantin at podsvirov.pro  Wed Jan  4 07:09:14 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Wed, 04 Jan 2017 15:09:14 +0300
Subject: [cmake-developers] Allow CodeBlocks for NMake Makefiles JOM
In-Reply-To: <1205181482580886@web10o.yandex.ru>
References: <1205181482580886@web10o.yandex.ru>
Message-ID: <6922651483531754@web19m.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170104/98263a83/attachment.html>

From ben.boeckel at kitware.com  Wed Jan  4 10:12:51 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 4 Jan 2017 10:12:51 -0500
Subject: [cmake-developers] COMPILE_FEATURES,
 Mac and non-Apple clang versions
In-Reply-To: <CA+dygY=FNgsCCWWf-fgOoB7xf18kmBJEtFwkWwXopci8PZjTfg@mail.gmail.com>
References: <2723217.JG0fgKC0bN@portia.local> <3272629.CleqpXTdn0@portia.local>
 <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>
 <2026573.QpI33mtGQh@portia.local> <o4hgg2$f0g$1@blaine.gmane.org>
 <CA+dygY=FNgsCCWWf-fgOoB7xf18kmBJEtFwkWwXopci8PZjTfg@mail.gmail.com>
Message-ID: <20170104151251.GA27117@megas.kitware.com>

On Wed, Jan 04, 2017 at 12:12:46 +1100, Craig Scott wrote:
> We have many projects which do exactly the scenario you mention above where
> a project can be built standalone or added to another project via
> add_subdirectory(). We have not found it necessary to test if a project is
> top level or not before calling cmake_minimum_required(). The behaviour is
> well-defined and performs as per the documentation in regard to policies
> and minimum CMake versions as far as we've observed. Can you point me/us at
> documentation or code which shows why this should be considered undefined
> behaviour? I'm particularly interested in this case since we use it
> frequently in production.

I agree; I've seen projects do multiple cmake_minimum_required() calls
and work as one would expect. However, the problem is, it seems to me,
with CMP0025 specifically because it changes the logic around the
identity detection of the compiler. The compiler is only identified
once, so once it is detected as being X, it will always be X, even if
CMP0025 changes in the future (via explicit setting, a change to the
version in the cmake_minimum_required() call, etc.) without resetting
the build tree.

--Ben

From ch.schmidbauer at gmail.com  Wed Jan  4 17:12:55 2017
From: ch.schmidbauer at gmail.com (Christian Schmidbauer)
Date: Wed, 4 Jan 2017 23:12:55 +0100
Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path
In-Reply-To: <57643D28.6070501@kitware.com>
References: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com>
 <575ECFC2.7090804@kitware.com>
 <CAMMtFbGu5R7vy5=CJCjp8dzVomyjAiyxhB4OyTJjY9YnXw53=w@mail.gmail.com>
 <57642FAA.5050507@kitware.com>
 <CAMMtFbH+YwUFfvqpM-1xEer99i2A+RkjraL4GGF9CzgW8yKk_A@mail.gmail.com>
 <57643D28.6070501@kitware.com>
Message-ID: <CAMMtFbFzS9i-7Lta7udt=uxWrP0ixWDVhoc3EzpGFK-Fz8GKLA@mail.gmail.com>

On Fri, Jun 17, 2016 at 8:10 PM, Brad King <brad.king at kitware.com> wrote:
> On 06/17/2016 01:33 PM, Christian Schmidbauer wrote:
>>> CMake sets the lib32/lib64 ones in its own
>>> platform modules for the relevant platforms so user code never
>>> needs to do it.  Where in user code would it be done?
>>
>> In my setup, I would create a custom my-config.cmake file
>
> And that is included from CMakeLists.txt files?
>
>> SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32 search path" FORCE)
>
> I think you meant to use set_property here.  It is not a cache entry.
> However, see below.
>
>> This way I can overwrite cmake's default lib32/lib64 search folders.
>> Why do you ask? Do you have a specific opinion about this?
>
> If the goal is to be able to override it for a local build then
> we shouldn't have to modify the project CMake code.  Setting the
> global property requires editing code.  The existing properties
> FIND_LIBRARY_USE_LIB{32,64}_PATHS make sense because they are
> configured by CMake as properties of the current system.
>
> Instead we could activate this behavior through a variable that
> could then be added to the cache on the command line via -D.
> That would allow local builds to configure any project to search
> this way.  For example:
>
>   cmake ../src -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=x32
>
> -Brad
>

I did not intend to use it for a local build. My idea of
"FIND_LIBRARY_USE_CUSTOM_PATHS" was the following:

Currently, cmake tries to detect the naming scheme for
lib/lib32/lib64, hence making the life of a distribution with
non-standard library folders very hard. This patch should allow a
distribution to set the naming scheme of the lib<qual> folder to
whatever they want (allowed should be anything, see [1]).

I don't have enough insight into cmake in order to say what would be
the "proper" way to achieve this. I went ahead and followed the logic
from Gentoo's portage (see [2] line 531-533) and tried to expand it
such that you can specify any string for <qual>.

If you have a better way to achieve this, I am all ears.

Best regards,
Chris

[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s10.html
[2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/cmake-utils.eclass?revision=1.114&view=markup

From chuck.atkins at kitware.com  Thu Jan  5 14:47:13 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 5 Jan 2017 14:47:13 -0500
Subject: [cmake-developers] Fw: CTest and Address Sanitizer
In-Reply-To: <CY4PR02MB2325A9C2A47A939014386BC2A46B0@CY4PR02MB2325.namprd02.prod.outlook.com>
References: <BN6PR02MB2322B432F48D436F9AEE7DE7A4960@BN6PR02MB2322.namprd02.prod.outlook.com>
 <CY4PR02MB2325268D19C83BB8F70712E5A4960@CY4PR02MB2325.namprd02.prod.outlook.com>
 <CABgOZMbjbz4y4iC8tzHTD0y-WcuaZnqX_jpXYQU1R5rXEHrmiA@mail.gmail.com>
 <CY4PR02MB2325A9C2A47A939014386BC2A46B0@CY4PR02MB2325.namprd02.prod.outlook.com>
Message-ID: <CAOXZzG6yBhxiS7sjoyv7cWyJyuGDw1dsEmD5_YWSm5d+ZUZ72g@mail.gmail.com>

Hi Karl,

>> I believe that the AddressSanitizer should normally stop with a non-zero
> error code right after the first error.
>
> I have many tests within each executable test application, forcing the
> application to exit on the first error is not optimal since it means I
> cannot get an overview of all the issues and triage/fix them in logical
> order. Instead I have to test/fix/retest every time
>


That's by design and isn't to do with how CMake integrates asan; i.e. it's
just how asan works.  The idea being that once you hit a memory corruption
then any further results can't be relied on.  From the asan documentation:
http://clang.llvm.org/docs/AddressSanitizer.html

"If a bug is detected, the program will print an error message to stderr
and exit with a non-zero exit code. AddressSanitizer exits on the first
detected error. This is by design:

   - This approach allows AddressSanitizer to produce faster and smaller
   generated code (both by ~5%).
   - Fixing bugs becomes unavoidable. AddressSanitizer does not produce
   false alarms. Once a memory corruption occurs, the program is in an
   inconsistent state, which could lead to confusing results and potentially
   misleading subsequent reports.

"

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170105/73bf29a5/attachment.html>

From steveire at gmail.com  Thu Jan  5 19:57:11 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Fri, 06 Jan 2017 00:57:11 +0000
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
References: <2723217.JG0fgKC0bN@portia.local> <3272629.CleqpXTdn0@portia.local>
 <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>
 <2026573.QpI33mtGQh@portia.local> <o4hgg2$f0g$1@blaine.gmane.org>
 <CA+dygY=FNgsCCWWf-fgOoB7xf18kmBJEtFwkWwXopci8PZjTfg@mail.gmail.com>
Message-ID: <o4mq12$56i$1@blaine.gmane.org>

Craig Scott wrote:

>> if you use add_subdirectory with top-level projects which don't
>> explicitly do something like that, you're getting undefined , and
>> generally unexpected behavior in many ways.
> 
> This seems at odds with the CMake documentation for
> cmake_minimum_required(). That documentation talks about calling
> cmake_minimum_required() within a function as a valid case

I don't know why using that command inside a function would be a good idea.

What would you be trying to achieve with putting it in a function not near 
the top? Can you give an example?

> Yes, each one will alter the policy behaviour for that
> scope and below, but assuming that's what the project wanted to enforce,
> this should be fine.

I would expect that many users are surprised by the result of this. 
cmake_policy(VERSION) is probably better if you want to set policies.

[Aside: I happen to think that it would be better if the canonical start of 
a top CMakeLists file would be 

 cmake_policy(VERSION 3.2)
 project(foo)

Most users (especially non-power-users) don't realize the connection between 
cmake_minimum_required and policies and why that's important]

> We have many projects which do exactly the scenario you mention above
> where a project can be built standalone or added to another project via
> add_subdirectory(). We have not found it necessary to test if a project is
> top level or not before calling cmake_minimum_required(). 

My comment should have been more-general in that the contained project 
should be designed to be 'inlined as a subdirectory' like that and it 
otherwise shouldn't be done. 

There are many pitfalls. I have encountered at least one pitfall resulting 
from cmake_minimum_required being unconditional which I don't remember now 
unfortunately. Perhaps the problem was my inexperience to understand 
messages I was seeing and what I expected from the code.

Others include 

* conflicting target names
* conflicting option()s, or option()s which shouldn't be exposed
* modification of global or cache variables affecting the container project 
in unexpected ways such as modifying compile flags
* possibly odd behavior if you have multiple include(CTest) or 
include(CPack) in different directories
* projects which assume CMAKE_SOURCE_DIR is their top-level and use 
something like include($CMAKE_SOURCE_DIR}/cmake/MyPrivateMacros.cmake)
* deliberate checks for top-level in a file include()d in multiple locations 
in the project.

Sure, you can test things out when you add a new 
 
 add_subdirectory(random_github_clone)

but just because it works (enough! - do any of them use CMAKE_SOURCE_DIR and 
it doesn't cause *visible* problems?) with all of the external projects 
you've tried so far doesn't mean you can expect it to work with any external 
project. 

For me, that's as close as you get to 'undefined behavior' in CMake code.

Thanks,

Steve.



From debuggery at outlook.com  Thu Jan  5 20:21:11 2017
From: debuggery at outlook.com (Karl Robinson)
Date: Fri, 6 Jan 2017 01:21:11 +0000
Subject: [cmake-developers] Fw: CTest and Address Sanitizer
In-Reply-To: <CAOXZzG6yBhxiS7sjoyv7cWyJyuGDw1dsEmD5_YWSm5d+ZUZ72g@mail.gmail.com>
References: <BN6PR02MB2322B432F48D436F9AEE7DE7A4960@BN6PR02MB2322.namprd02.prod.outlook.com>
 <CY4PR02MB2325268D19C83BB8F70712E5A4960@CY4PR02MB2325.namprd02.prod.outlook.com>
 <CABgOZMbjbz4y4iC8tzHTD0y-WcuaZnqX_jpXYQU1R5rXEHrmiA@mail.gmail.com>
 <CY4PR02MB2325A9C2A47A939014386BC2A46B0@CY4PR02MB2325.namprd02.prod.outlook.com>,
 <CAOXZzG6yBhxiS7sjoyv7cWyJyuGDw1dsEmD5_YWSm5d+ZUZ72g@mail.gmail.com>
Message-ID: <BN6PR02MB232275E29F0BB69BE288F67AA4630@BN6PR02MB2322.namprd02.prod.outlook.com>

Hi Chuck


Firstly, thanks for taking the time to respond.


The sanitizers exit on failure thing makes perfect sense although why it isn't the default behavior mystifies me. Turning it on gets me the effect I am looking for (CTest can detect a failure) but what I really want to know and the reason for my original post is:


1) Why do I always get Valgrind when I run memtest? Either that or "Memory checker (MemoryCheckCommand) not set, or cannot find the specified program.". Looking at the source code I _think_ setting  the MEMORYCHECK_TYPE variable to AddressSanitizer should be enough, I shouldn't need to set the MemoryCheckCommand and there isn't one for the sanitizers anyway


2) The documentation hints that CTest should be able to understand the output of the sanitizers, I can't say if this true or not with any certainty but it doesn't seem to be the case


Thanks again!


________________________________
From: Chuck Atkins <chuck.atkins at kitware.com>
Sent: Thursday, January 5, 2017 11:47:13 AM
To: Karl Robinson
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Fw: CTest and Address Sanitizer

Hi Karl,

>> I believe that the AddressSanitizer should normally stop with a non-zero error code right after the first error.

I have many tests within each executable test application, forcing the application to exit on the first error is not optimal since it means I cannot get an overview of all the issues and triage/fix them in logical order. Instead I have to test/fix/retest every time


That's by design and isn't to do with how CMake integrates asan; i.e. it's just how asan works.  The idea being that once you hit a memory corruption then any further results can't be relied on.  From the asan documentation: http://clang.llvm.org/docs/AddressSanitizer.html

"If a bug is detected, the program will print an error message to stderr and exit with a non-zero exit code. AddressSanitizer exits on the first detected error. This is by design:

  *   This approach allows AddressSanitizer to produce faster and smaller generated code (both by ~5%).
  *   Fixing bugs becomes unavoidable. AddressSanitizer does not produce false alarms. Once a memory corruption occurs, the program is in an inconsistent state, which could lead to confusing results and potentially misleading subsequent reports.

"

- Chuck


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170106/69a9fa2a/attachment.html>

From comicfans44 at gmail.com  Sat Jan  7 23:59:46 2017
From: comicfans44 at gmail.com (comic fans)
Date: Sun, 8 Jan 2017 12:59:46 +0800
Subject: [cmake-developers] [RFC] Fastbuild generator
Message-ID: <CAKzW8o=KvuksvXuwCZoxUDW6aYiYa+JtRKwpPV5kTEEdg1Yaiw@mail.gmail.com>

Hello:

Fastbuild is a opensource multi platform build tool which has built-in
cache/distribute (likes ccache/distcc) and pch/unity build
support(http://fastbuild.org/docs/home.html).


@inbilla created fastbuild generator based on 3.2.1 here
https://github.com/inbilla/CMake , this completed almost everything
but didn't continue developing for a while. recently I've rebase his
work on master branch, with some
tweaks(https://gitlab.kitware.com/comicfans/cmake/commits/upstream2),now
it can builds cmake , and almost llvm/clang,  so I'd like to share
this here, hopes more user to test this out.

I haven't touch cmake code before so it may not as good as you think.
If anyone interested to try this code, any comments and suggestion
would be helpful.


How Fastbuild compares to Ninja :
If build locally, fastbuild almost as fast as ninja , but fastbuild
provides simpler distrubte support,you can just run fastbuild worker
on many woker machine (without need to install toolchain) to speed up.
As I tested,

host (4core4thread 8GB ) local build clang:  60 min
host + worker (6core12thread 32GB) distrubite clang : 30 min

Fastbuild Generator current status:

 local build works on linux/windows (I don't have mac to test)

 some cmake variable not set correctly (RUNTIME_OUTPUT_DIRECTORY,
LIBRARY_OUTPUT_DIRECTORY,  how to put CFGIntDir in ?  help needed !),

 distrubte build not work (you can list toolchain exe/dll in header,
or just copy header from fastbuild src's to make distribute build
work) I wonder if cmake has builtin support to list all these files,
help needed!

config/build on windows must run from vs cmd console, because cmake
didn't detect windows SDK for include/link path (Ninja generator also
suffer from this). help needed.

edit CMake files didn't auto trigger fastbuild auto rebuild, must rerun cmake

rerun cmake makes fastbuild rebuild everything. this is fastbuild's
shortcoming, author is working on this.

custom commands will generate script file (bash/bat) ,should we write
commands as argument to sh/cmd , or improve this in fastbuild ?

From charles.huet at gmail.com  Mon Jan  9 04:12:17 2017
From: charles.huet at gmail.com (Charles Huet)
Date: Mon, 09 Jan 2017 09:12:17 +0000
Subject: [cmake-developers] [RFC] Fastbuild generator
In-Reply-To: <CAKzW8o=KvuksvXuwCZoxUDW6aYiYa+JtRKwpPV5kTEEdg1Yaiw@mail.gmail.com>
References: <CAKzW8o=KvuksvXuwCZoxUDW6aYiYa+JtRKwpPV5kTEEdg1Yaiw@mail.gmail.com>
Message-ID: <CAGTK6mb0KquzoxBRftO1N-Do89=umhcOp0ky=GVpS4ohxpS2Hw@mail.gmail.com>

Hi,

I ported the work of @inbilla to CMake trunk a few months ago, and fixed
quite a few tests on my fork: https://github.com/packadal/CMake

I think it would be best if we tried to synchronize our efforts, since lots
of people are interested in getting a FastBuild generator for CMake !
There is a gitter channel that is used to discuss the progress here:
https://gitter.im/inbilla/CMake

I hope we can get this to work well enough to be iontegrated in CMake 3.8,
but I did not have time to work on this lately.
I hope to get back to it this week, but I am always available for
discussion :)

Best


Le dim. 8 janv. 2017 ? 05:59, comic fans <comicfans44 at gmail.com> a ?crit :

Hello:

Fastbuild is a opensource multi platform build tool which has built-in
cache/distribute (likes ccache/distcc) and pch/unity build
support(http://fastbuild.org/docs/home.html).


@inbilla created fastbuild generator based on 3.2.1 here
https://github.com/inbilla/CMake , this completed almost everything
but didn't continue developing for a while. recently I've rebase his
work on master branch, with some
tweaks(https://gitlab.kitware.com/comicfans/cmake/commits/upstream2),now
it can builds cmake , and almost llvm/clang,  so I'd like to share
this here, hopes more user to test this out.

I haven't touch cmake code before so it may not as good as you think.
If anyone interested to try this code, any comments and suggestion
would be helpful.


How Fastbuild compares to Ninja :
If build locally, fastbuild almost as fast as ninja , but fastbuild
provides simpler distrubte support,you can just run fastbuild worker
on many woker machine (without need to install toolchain) to speed up.
As I tested,

host (4core4thread 8GB ) local build clang:  60 min
host + worker (6core12thread 32GB) distrubite clang : 30 min

Fastbuild Generator current status:

 local build works on linux/windows (I don't have mac to test)

 some cmake variable not set correctly (RUNTIME_OUTPUT_DIRECTORY,
LIBRARY_OUTPUT_DIRECTORY,  how to put CFGIntDir in ?  help needed !),

 distrubte build not work (you can list toolchain exe/dll in header,
or just copy header from fastbuild src's to make distribute build
work) I wonder if cmake has builtin support to list all these files,
help needed!

config/build on windows must run from vs cmd console, because cmake
didn't detect windows SDK for include/link path (Ninja generator also
suffer from this). help needed.

edit CMake files didn't auto trigger fastbuild auto rebuild, must rerun
cmake

rerun cmake makes fastbuild rebuild everything. this is fastbuild's
shortcoming, author is working on this.

custom commands will generate script file (bash/bat) ,should we write
commands as argument to sh/cmd , or improve this in fastbuild ?
--

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170109/bfd23180/attachment.html>

From eike at sf-mail.de  Mon Jan  9 04:59:13 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 09 Jan 2017 10:59:13 +0100
Subject: [cmake-developers] Recording compiler features for older gcc
	versions
Message-ID: <28540444.kHl9saaQ7y@devpool21>

I need for several projects the ability to set CMAKE_C_STANDARD on older 
compilers, at least gcc 4.2, but preferably also down to gcc 3.4. I have them 
available, so testing is not the issue. But there are some problems besides 
"just record them".

The problems that I know of:

-WriteCompilerDetectionHeader last time had problems when the features for the 
compiler were recorded only for C for a given version, i.e. I can't just tell 
CMake "gcc 3.4ff. know about C99" without also recording C++ features for that 
versions
-the standard check for working features is currently auto_type, which is not 
supported by older compilers. Basically all support long_long_type, so we 
either need to change that (patch is in my gcc-34-features branch), or we need 
a better way to check what is available at all before using it.

Any help welcome.

Eike

From daniel at pfeifer-mail.de  Mon Jan  9 05:46:18 2017
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Mon, 9 Jan 2017 11:46:18 +0100
Subject: [cmake-developers] Can we please require TR1 to build CMake?
Message-ID: <CANZMcXorK5NqOO655w0pzwr=AZT+p=MdUj_MY4QSfuarpm-1Hw@mail.gmail.com>

Hi and happy 2017,

I am currently doing some refactoring (more on that later) and I would like
to start using TR1/C++11 library features, namely std::function, std::bind,
std::placeholders, std::shared_ptr, std::make_shared.

Some background information:

The Dinkumware standard library introduced TR1 in version 5.05. Visual
Studio 2008 (without Service Pack) ships with version 5.03. Visual Studio
2008 SP1 has version 5.05. Visual Studio 2010 has version 5.20. This
version puts the symbols into namespace std. The version number is stored
in _CPPLIB_VER.

The GNU libstdc++ introduced TR1 in version 4.0. The TR1 headers have been
put into a subdirectory. Starting with version 4.3, the headers can be
included as in C++11 and the symbols are in namespace std, but only if the
language mode is set to C++0x or higher. The library version number is
stored in __GLIBCXX__.

The LLVM libc++ was designed for C++11 from the beginning.

I could not find information about TR1 availability in other standard
library implementations. So I made a test run on the nightly dashboard
builds. The results are here:
https://open.cdash.org/index.php?project=CMake&date=2016-12-29
I was very surprised by the small number of failed builds.

Five expected nightly builds failed on dash2win64.kitware. Apparently
Visual Studio 2008 SP1 is not installed. The Intel compiler uses the
standard library of Visual Studio.

AIX-7.1_IBM-12.1 reports that __IBMCPP_TR1__ must be defined to use TR1.
That should be easy to fix.

Xcode 2.1 and 3.2 fail. These builds are not marked as "expected".

This leaves HP-UX.11iv2.ia64-aCC and Solaris-10-8.11_Oracle-12.3.

Here is my concrete proposal:

* Explicitly require SP1 for Visual Studio 2008.
* Drop support for Xcode 2.1 and 3.2 or mark builds as expected.
* Disallow compiling in C++98 mode if compiler is capable of C++11.
* Require TR1 by all means. This may require setting up Boost.TR1 on a very
small number of exotic platforms.

Cheers, Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170109/02ee3ac1/attachment.html>

From brad.king at kitware.com  Mon Jan  9 14:10:20 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 14:10:20 -0500
Subject: [cmake-developers] CMake 3.8 feature freeze on 2017-02-01
Message-ID: <4f8bf366-cd4d-77e4-0cfc-70fbb3e3e938@kitware.com>

Hi Folks,

The feature freeze in 'master' for CMake 3.8 will be on Feb 1, 2017.
I may announce a freeze in 'next' sometime in the preceding week so
that we can get any remaining dashboard trouble cleaned up.

I've just returned from vacation and will try to work through the
open MRs and mailing list threads in time for the 3.8 freeze.  I
should be able to get through most of the work, but any major new
changes or infrastructure will likely have to wait until post-3.8
development opens.

Thanks,
-Brad

From brad.king at kitware.com  Mon Jan  9 14:30:58 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 14:30:58 -0500
Subject: [cmake-developers] Can we please require TR1 to build CMake?
In-Reply-To: <CANZMcXorK5NqOO655w0pzwr=AZT+p=MdUj_MY4QSfuarpm-1Hw@mail.gmail.com>
References: <CANZMcXorK5NqOO655w0pzwr=AZT+p=MdUj_MY4QSfuarpm-1Hw@mail.gmail.com>
Message-ID: <31df61b3-3d59-8762-4167-f5b82c2b9282@kitware.com>

On 01/09/2017 05:46 AM, Daniel Pfeifer wrote:
> start using TR1/C++11 library features, namely std::function, std::bind,
> std::placeholders, std::shared_ptr, std::make_shared.

I'd love to be able to start using those too, but last time I checked
they are not supported everywhere CMake builds, at least in the standard
libraries (see below).

> AIX-7.1_IBM-12.1 reports that __IBMCPP_TR1__ must be defined to use TR1.

Hopefully, but that would take some investigation.

> Xcode 2.1 and 3.2 fail. These builds are not marked as "expected".

I'd be okay with dropping these.

> This leaves HP-UX.11iv2.ia64-aCC and Solaris-10-8.11_Oracle-12.3.

IIUC the Oracle compiler supports C++11 when told to use the proper
stdlib.  However, I don't think there is a solution on HP-UX with its
standard library.

> * Explicitly require SP1 for Visual Studio 2008.

Okay.  For hosting CMake's own build we could even consider requiring
VS 2010.  One blocker for that on Kitware's side is updating our
dashboard machines as needed to be able to host CMake builds even if
testing generators for older versions.  I'm not sure when I'll have
time to do that.

> * Disallow compiling in C++98 mode if compiler is capable of C++11.

Okay.

> * Require TR1 by all means. This may require setting up Boost.TR1
>   on a very small number of exotic platforms.

IIRC there is a tool to extract a subset of boost.  Please see how
small it can get.  We can even remove the config headers for the
platforms we don't need to use it, perhaps manually.

Thanks,
-Brad


From brad.king at kitware.com  Mon Jan  9 14:36:56 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 14:36:56 -0500
Subject: [cmake-developers] Recording compiler features for older gcc
 versions
In-Reply-To: <28540444.kHl9saaQ7y@devpool21>
References: <28540444.kHl9saaQ7y@devpool21>
Message-ID: <eac478e8-89ad-15ab-76a9-859eaa796e61@kitware.com>

On 01/09/2017 04:59 AM, Rolf Eike Beer wrote:
> I need for several projects the ability to set CMAKE_C_STANDARD on older 
> compilers

I think it would be fine to add the minimum infrastructure needed for
that and then just disable the WCDH and Tests/* pieces that don't work
with it.  We could also just not document this support.  Until more
people are interested in it that have time to implement it fully, I don't
think we need to fully support it beyond your use case.

> -the standard check for working features is currently auto_type, which is not 
> supported by older compilers. Basically all support long_long_type,

I'm hesitant to switch to long_long_type because that is often supported
by compilers in C++98 mode, so it may defeat the test.

Thanks,
-Brad


From brad.king at kitware.com  Mon Jan  9 14:39:45 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 14:39:45 -0500
Subject: [cmake-developers] Do all non-Windows host platforms support
 uname(3)
In-Reply-To: <a9aa4fdb-e1e7-4165-9a46-8152c221057a@googlemail.com>
References: <a9aa4fdb-e1e7-4165-9a46-8152c221057a@googlemail.com>
Message-ID: <47c4aa1b-b814-296c-f1ff-7e9cf3da1cbd@kitware.com>

On 12/27/2016 11:14 AM, Gregor Jasny via cmake-developers wrote:
> recently I realized that most pre-defined CMake variables are not
> available in scripting context. In my use case I had to identify a Linux
> host system. Unfortunately only CMAKE_HOST_{APPLE,SOLARIS,UNIX,WIN32}
> are available in scripting context.
> 
> I wondered if all supported host operating systems support the uname(3)
> function call? If yes we could also make CMAKE_HOST_SYSTEM_NAME in
> scripting context.
> 
> A proof-of-concept patch is located here:
> https://gitlab.kitware.com/gjasny/cmake/commits/cmake-host-system-name

That looks worth a try.  If any platforms come up where it is not
supported then we can port the source accordingly.

I'd like to wait a while before testing it in `next` because there
are many open MRs I need to get through in the next few days.

Thanks,
-Brad


From brad.king at kitware.com  Mon Jan  9 14:48:27 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 14:48:27 -0500
Subject: [cmake-developers] Creating a Keil uVision generator
In-Reply-To: <VI1PR07MB086334BAC030F0B047EAA92EED6F0@VI1PR07MB0863.eurprd07.prod.outlook.com>
References: <VI1PR07MB086334BAC030F0B047EAA92EED6F0@VI1PR07MB0863.eurprd07.prod.outlook.com>
Message-ID: <3191013f-69c5-79ec-aeac-c4cb92c4f438@kitware.com>

On 01/02/2017 06:27 PM, Paul Wilkinson wrote:
> As with the Visual Studio generators, a generator for uVision projects would
> ideally be a multi-configuration generator.

Yes, the layouts sounds similar.  A uVision project generator implementation
could be modeled after the VS 2015 generator.  It would be nice to use the
cmXMLWriter for the actual writing of the files if they are XML syntax
(the VS generator would ideally do this too but pre-dated the helper).

> I expect there are many concepts in CMake that wouldn't map to a uVision option,
> and vice-versa. For example the "Packs" system used by uVision might not mesh
> well with what CMake understands as a library.

This may be a problem.  Unless CMake's buildsystem model:

 https://cmake.org/cmake/help/v3.7/manual/cmake-buildsystem.7.html

can be mapped cleanly to uVision project files then it may not be a good fit.

> For my limited requirements -- a
> single project workspace, where the project consists of exactly one executable
> and no libraries other than some third-party libraries passed to linker -- I
> expect we could make do with a skeleton/template .uvprojx and the CMake
> generator would fill in the gaps for the source files.

Unfortunately that case sounds so limited that a special case to support it
would not be appropriate for inclusion in CMake.  Way back in the VS 6 days
when CMake started we used template project files for generation, and they
were very painful to maintain and extend.

Thanks,
-Brad


From brad.king at kitware.com  Mon Jan  9 14:55:48 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 14:55:48 -0500
Subject: [cmake-developers] Unknown Imported & Global libraries
In-Reply-To: <12897DE5-1416-4336-8568-219AD7447491@gmail.com>
References: <12897DE5-1416-4336-8568-219AD7447491@gmail.com>
Message-ID: <0f88063c-9042-fe23-4372-8f743514a76d@kitware.com>

On 12/21/2016 07:12 AM, Florent Castelli wrote:
> find_package(foo)
> if(NOT FOO_FOUND)
>   add_library(foo STATIC foo.cpp)
> endif()

Instead do

  find_package(foo)
  if(NOT FOO_FOUND)
    add_subdirectory(bundled_foo)
  endif()

so that the imported targets are visible.  Inside the bundled_foo you can build
the target and then crate an ALIAS library whose name matches what the imported
target would have been.

> make imported libraries global by default

The reason they are locally scoped is that find_package() may load
different, possibly conflicting, external packages in separate directories.
The find_package() call should be made at the highest level that contains
anything that directly references the target.  See above example.

An alternative is:

  find_package(foo)
  add_library(Foo INTERFACE)
  target_link_libraries(Foo PUBLIC FOO::FOO)

That will make a globally visible Foo target that when used forwards all
usage requirements from the imported target.

-Brad


From brad.king at kitware.com  Mon Jan  9 15:17:47 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 15:17:47 -0500
Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path
In-Reply-To: <CAMMtFbFzS9i-7Lta7udt=uxWrP0ixWDVhoc3EzpGFK-Fz8GKLA@mail.gmail.com>
References: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com>
 <575ECFC2.7090804@kitware.com>
 <CAMMtFbGu5R7vy5=CJCjp8dzVomyjAiyxhB4OyTJjY9YnXw53=w@mail.gmail.com>
 <57642FAA.5050507@kitware.com>
 <CAMMtFbH+YwUFfvqpM-1xEer99i2A+RkjraL4GGF9CzgW8yKk_A@mail.gmail.com>
 <57643D28.6070501@kitware.com>
 <CAMMtFbFzS9i-7Lta7udt=uxWrP0ixWDVhoc3EzpGFK-Fz8GKLA@mail.gmail.com>
Message-ID: <9ca7d61c-9b6b-ad4a-be86-9c08321d9a47@kitware.com>

On 01/04/2017 05:12 PM, Christian Schmidbauer wrote:
>>   cmake ../src -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=x32
> 
> Currently, cmake tries to detect the naming scheme for
> lib/lib32/lib64, hence making the life of a distribution with
> non-standard library folders very hard. This patch should allow a
> distribution to set the naming scheme of the lib<qual> folder to
> whatever they want (allowed should be anything, see [1]).
> 
> I don't have enough insight into cmake in order to say what would be
> the "proper" way to achieve this. I went ahead and followed the logic
> from Gentoo's portage (see [2] line 531-533) and tried to expand it
> such that you can specify any string for <qual>.

I think their use of `LIB_SUFFIX` and my proposed variable named
above are about the same except for the name.  Currently your
patch checks for a `FIND_LIBRARY_USE_CUSTOM_PATHS` global property
and uses that to decide whether to check the `LIB_SUFFIX` variable.

Instead I think it could just check for a single variable called
`CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX`, and if set use it instead
of the default lib/lib32/lib64 for the current platform.  That will
allow users and distro packagers to build projects with the custom
lib dir suffix.

-Brad


From eike at sf-mail.de  Mon Jan  9 15:55:59 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 09 Jan 2017 21:55:59 +0100
Subject: [cmake-developers] Recording compiler features for older gcc
	versions
In-Reply-To: <eac478e8-89ad-15ab-76a9-859eaa796e61@kitware.com>
References: <28540444.kHl9saaQ7y@devpool21>
 <eac478e8-89ad-15ab-76a9-859eaa796e61@kitware.com>
Message-ID: <2320761.bvgDPpd3F5@daneel.sf-tec.de>

Am Montag, 9. Januar 2017, 14:36:56 schrieb Brad King:
> On 01/09/2017 04:59 AM, Rolf Eike Beer wrote:
> > I need for several projects the ability to set CMAKE_C_STANDARD on older
> > compilers
> 
> I think it would be fine to add the minimum infrastructure needed for
> that and then just disable the WCDH and Tests/* pieces that don't work
> with it.  We could also just not document this support.  Until more
> people are interested in it that have time to implement it fully, I don't
> think we need to fully support it beyond your use case.

I'm fine with that. I will probably not have time to look into this the coming 
days, but I hope I can do it before the 3.8 feature freeze.

> > -the standard check for working features is currently auto_type, which is
> > not supported by older compilers. Basically all support long_long_type,

> I'm hesitant to switch to long_long_type because that is often supported
> by compilers in C++98 mode, so it may defeat the test.

That was also the reason I was reluctant about this. So we need to come up 
with a better solution, e.g. use auto_type if supported by the compiler and 
fall back to long_long_type for others. Please revert my topic from stage for 
the moment, it will take me at least until end of the week before I have time 
to look at this again.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170109/1b20f5f1/attachment-0001.sig>

From brad.king at kitware.com  Mon Jan  9 16:06:36 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 9 Jan 2017 16:06:36 -0500
Subject: [cmake-developers] Recording compiler features for older gcc
 versions
In-Reply-To: <2320761.bvgDPpd3F5@daneel.sf-tec.de>
References: <28540444.kHl9saaQ7y@devpool21>
 <eac478e8-89ad-15ab-76a9-859eaa796e61@kitware.com>
 <2320761.bvgDPpd3F5@daneel.sf-tec.de>
Message-ID: <d99dbfd4-d652-d678-c554-78d9d2326e6a@kitware.com>

On 01/09/2017 03:55 PM, Rolf Eike Beer wrote:
> Please revert my topic from stage for the moment

Done.

Thanks,
-Brad


From eike at sf-mail.de  Mon Jan  9 16:26:17 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 09 Jan 2017 22:26:17 +0100
Subject: [cmake-developers] Can we please require TR1 to build CMake?
In-Reply-To: <CANZMcXorK5NqOO655w0pzwr=AZT+p=MdUj_MY4QSfuarpm-1Hw@mail.gmail.com>
References: <CANZMcXorK5NqOO655w0pzwr=AZT+p=MdUj_MY4QSfuarpm-1Hw@mail.gmail.com>
Message-ID: <2068867.jUoVU5PnD5@daneel.sf-tec.de>

> The GNU libstdc++ introduced TR1 in version 4.0. The TR1 headers have been
> put into a subdirectory. Starting with version 4.3, the headers can be
> included as in C++11 and the symbols are in namespace std, but only if the
> language mode is set to C++0x or higher. The library version number is
> stored in __GLIBCXX__.

For an entirely different reason (missing atomic support) gcc 3.4 currently 
causes trouble, as in libuv is not building. There are also failures in SHA3 
which I can't explain, and which could also be related to atomic support. So 
my suggestion would be to also drop support for gcc 3.4, i.e. require 
gcc>=4.0. The last release of gcc 3.4 is from 2006, which is close to the 
timeframe of the MSVC versions we require.

Opinions?

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170109/16cfc024/attachment.sig>

From florent.castelli at gmail.com  Mon Jan  9 19:00:11 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Tue, 10 Jan 2017 01:00:11 +0100
Subject: [cmake-developers] Unknown Imported & Global libraries
In-Reply-To: <0f88063c-9042-fe23-4372-8f743514a76d@kitware.com>
References: <12897DE5-1416-4336-8568-219AD7447491@gmail.com>
 <0f88063c-9042-fe23-4372-8f743514a76d@kitware.com>
Message-ID: <BA1CB601-1168-451A-BA75-909A85EEDCC3@gmail.com>


> On 9 Jan 2017, at 20:55, Brad King <brad.king at kitware.com> wrote:
> 
> On 12/21/2016 07:12 AM, Florent Castelli wrote:
>> find_package(foo)
>> if(NOT FOO_FOUND)
>>  add_library(foo STATIC foo.cpp)
>> endif()
> 
> Instead do
> 
>  find_package(foo)
>  if(NOT FOO_FOUND)
>    add_subdirectory(bundled_foo)
>  endif()
> 
> so that the imported targets are visible.  Inside the bundled_foo you can build
> the target and then crate an ALIAS library whose name matches what the imported
> target would have been.
> 

The problem with that approach is that it?s up to the ?caller? to put that boilerplate and it would be much nicer to have all of that in the callee, all within the same script.
Additionally, all the bundled library are usually setup in another folder ?ext?, ?vendor?, ?3rdparty? which will be a different context and won?t make those available to the rest of the code.

>> make imported libraries global by default
> 
> The reason they are locally scoped is that find_package() may load
> different, possibly conflicting, external packages in separate directories.
> The find_package() call should be made at the highest level that contains
> anything that directly references the target.  See above example.
> 

If the libraries don?t come from a find_package() call but my code, it should be my responsibility to make sure there?s no 2 conflicting libraries with the same name.
If I can guarantee that, then that is an annoying restriction on imported targets. 

> An alternative is:
> 
>  find_package(foo)
>  add_library(Foo INTERFACE)
>  target_link_libraries(Foo PUBLIC FOO::FOO)
> 
> That will make a globally visible Foo target that when used forwards all
> usage requirements from the imported target.
> 

That?s another approach I?m considering. It?s just annoying that ?FOO::FOO? becomes reserved as I?d rather have the external libraries ?namespaced?, and I can?t redefine an alias.
I guess I could set their name to Ext::FOO::FOO instead which would be decent.
Again, that?s some more annoying boilerplate.

Note it should also be INTERFACE and not PUBLIC in there.

> -Brad
> 

Anyway, this still doesn?t explain why ?UNKNOWN IMPORTED? and ?GLOBAL? keywords don?t work with each other. My guess is they should under a controlled setup, but I couldn?t make it work.

/Florent

From stephen.sorley at gmail.com  Wed Jan 11 15:59:18 2017
From: stephen.sorley at gmail.com (Stephen Sorley)
Date: Wed, 11 Jan 2017 15:59:18 -0500
Subject: [cmake-developers] deprecate check_function_exists?
Message-ID: <CAKtrNpE_Np13kLcnvWSsgVBOCFcsm+dp70aRY5L92zwdnFzNAA@mail.gmail.com>

There are two big issues with the check_function_exists() module that I've
run into, and that others have also encountered:

(1) It can't detect functions that are inlined in system headers or
specified as a #define macro. (see
https://cmake.org/pipermail/cmake-developers/2015-July/025766.html)

(2) For 32-bit Windows builds, it can't link against functions declared
with a different calling convention than __cdecl. Since the Win32 API uses
__stdcall, check_function_exists can't detect anything from libraries like
kernel.lib or ws2_32.lib. (see
https://cmake.org/pipermail/cmake/2008-April/021099.html)

The check_symbol_exists() module solves both of the above problems, and it
does verify that the function is available at link time (if the symbol
isn't a #define).

So, could check_function_exists() be explicitly deprecated in the
documentation in favor of check_symbol_exists()?  I think most users find
it natural to try using check_function_exists() first because of the name,
when they really should be using check_symbol_exists() for all of the use
cases I can think of.


Thanks!

Stephen Sorley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170111/29da4728/attachment.html>

From shmuelhcmake at gmail.com  Wed Jan 11 16:23:53 2017
From: shmuelhcmake at gmail.com (Shmuel H,)
Date: Wed, 11 Jan 2017 23:23:53 +0200
Subject: [cmake-developers] [Discussion] Add python support for CMakeLists
Message-ID: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>

Hello,

First of all, I have been using CMake for a few years now, it is awesome
tool, thank you.

The only problem I currently have with CMake is its language, which has not
really intended to be one. After reading a few endless discussions about
this topic, I decided to give it a try and do something practical.

My current design is using Python as an extension for the regular
CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.

It should not be too hard to maintain, the current API design uses only 1-3
function that should be implemented in cmake.

For more information, see the [closed] merge request #389
<https://gitlab.kitware.com/cmake/cmake/merge_requests/389>.

I would be happy to hear your opinion about this idea.

Best regards,
Shmuel H.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170111/bdca652f/attachment.html>

From daniel at pfeifer-mail.de  Thu Jan 12 05:16:38 2017
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Thu, 12 Jan 2017 11:16:38 +0100
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
Message-ID: <CANZMcXp0KuOFtNd+QDdCiF1yG8VhN7gMrMqtHqidiYpQLEBO4w@mail.gmail.com>

On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, <shmuelhcmake at gmail.com> wrote:

> Hello,
>
> First of all, I have been using CMake for a few years now, it is awesome
> tool, thank you.
>
> The only problem I currently have with CMake is its language, which has
> not really intended to be one. After reading a few endless discussions
> about this topic, I decided to give it a try and do something practical.
>
> My current design is using Python as an extension for the regular
> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.
>
> It should not be too hard to maintain, the current API design uses only
> 1-3 function that should be implemented in cmake.
>
> For more information, see the [closed] merge request #389
> <https://gitlab.kitware.com/cmake/cmake/merge_requests/389>.
>
> I would be happy to hear your opinion about this idea.
>

Hello Shmuel,

what do you find fault with the CMake language?  I have my own complaints
about it, which may be completely orthogonal or even contradictory to yours.

I am currently refactoring cmCommand and the way commands are interpreted
in the CMake language. This refactoring will simplify porting the CMake
language frontend to a different scripting engine. I have spent some
thoughts on this and I have a very strong opinion about the direction.

To avoid another "language X is better than Y" discussion, I will not go
into more details. You should elaborate your motivation first.

cheers, Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/d08f94fe/attachment.html>

From charles.huet at gmail.com  Thu Jan 12 04:48:44 2017
From: charles.huet at gmail.com (Charles Huet)
Date: Thu, 12 Jan 2017 09:48:44 +0000
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
Message-ID: <CAGTK6mYKWdACmQ7GtW8Oz+WbnDvEPodXbxEbtN4_qb8QnYCN-g@mail.gmail.com>

Hi,

I also worked on a similar prototype, and I think this should be discussed
further and set as a long-term goal for CMake.

The conclusions from the last time this came up were (from the top of my
head):

1)
Lua is the language that should be used, since it is easy to embed on all
the platforms CMake supports. All arguments about language X being better
than language Y do not matter, since all other languages do not answer to
the constraints that are CMake's, which are, as I understand them:
- being embeddable so as to not depend on the user to install something else
- support for lots of various platforms (e.g. ARM)

2)
This needs refactoring in CMake core that are ongoing (and some of this is
also needed for the cmake server if I understand correctly) but far from
finished.


The biggest problem I see is that there is no official stance from Kitware
on this subject.


Le mer. 11 janv. 2017 ? 23:52, Shmuel H, <shmuelhcmake at gmail.com> a ?crit :

> Hello,
>
> First of all, I have been using CMake for a few years now, it is awesome
> tool, thank you.
>
> The only problem I currently have with CMake is its language, which has
> not really intended to be one. After reading a few endless discussions
> about this topic, I decided to give it a try and do something practical.
>
> My current design is using Python as an extension for the regular
> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.
>
> It should not be too hard to maintain, the current API design uses only
> 1-3 function that should be implemented in cmake.
>
> For more information, see the [closed] merge request #389
> <https://gitlab.kitware.com/cmake/cmake/merge_requests/389>.
>
> I would be happy to hear your opinion about this idea.
>
> Best regards,
> Shmuel H.
> --
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/42ac6d33/attachment.html>

From brad.king at kitware.com  Thu Jan 12 09:27:30 2017
From: brad.king at kitware.com (Brad King)
Date: Thu, 12 Jan 2017 09:27:30 -0500
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
Message-ID: <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>

On 01/11/2017 04:23 PM, Shmuel H, wrote:
> a few endless discussions about this topic

Previous discussions have not ended in a new language being integrated,
but that does not mean they failed.  Several challenges w.r.t. the
internal architecture were identified.  A lot of progress has been made
in addressing some of those, but there is more work to do.  The goal is
to separate the representation of the build system model that is fed to
the generators from the current CMake language implementation.  Once that
is done then other approaches/languages can be added to build the model
instead of using the current language exclusively.

> My current design is using Python as an extension for the regular
> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.

We'd rather not introduce Python as a dependency of CMake's distribution,
even optionally.  It may be reasonable to have optional support when Python
can be found at runtime.  However, any such approach would need to avoid
requiring dynamic loading of plugins into CMake or any kind of stable
C++ API to be maintained.

Since previous such discussions we've now had the cmake-server mode
introduced.  It allows programs written in any language to communicate
with CMake through a JSON protocol.  Currently the protocol is very
minimal and geared toward IDEs that want to get a representation of the
build system after configuration of a build tree.

A similar approach could be used to interact with external processes
during configuration.  Such a protocol would allow programs written
in any language to be used for defining CMake build systems.

Previous discussions have also identified the value of having a declarative
specification format.  This is largely orthogonal to the procedural language
that drives the configuration process because any such language could still
have a command/step that loads the declarative part.

-Brad


From marco.schuler at gmail.com  Thu Jan 12 05:18:03 2017
From: marco.schuler at gmail.com (Marco Schuler)
Date: Thu, 12 Jan 2017 11:18:03 +0100
Subject: [cmake-developers] Fwd:  Creating a Keil uVision generator
In-Reply-To: <CAEHCvauzFcma2eurPttvC4TAB5F7T6gDZkuWY0ypO2TJr9dCDg@mail.gmail.com>
References: <VI1PR07MB086334BAC030F0B047EAA92EED6F0@VI1PR07MB0863.eurprd07.prod.outlook.com>
 <CAEHCvauzFcma2eurPttvC4TAB5F7T6gDZkuWY0ypO2TJr9dCDg@mail.gmail.com>
Message-ID: <CAEHCvasf_tJW4pwybD1Vs7vasnLhnfnQa5xZ8GAXQ8kOeyqWHA@mail.gmail.com>

From: Marco Schuler <marco.schuler at gmail.com>
Date: 2017-01-12 11:16 GMT+01:00
Subject: Re: [cmake-developers] Creating a Keil uVision generator
To: Paul Wilkinson <paul.wilkinson at cmedrobotics.com>


Hi all

2017-01-03 0:27 GMT+01:00 Paul Wilkinson <paul.wilkinson at cmedrobotics.com>:

> Hi all,
>
> I am involved in a software project targeting a handful of ARM Cortex-M
> microcontrollers. We develop the software using the Keil uVision v5 IDE
> [1]. We
> are considering whether CMake could help us with some of the limitations we
> encounter using uVision alone.


Same here. Lots of different boards and applications with shared code. It
is a nightmare to manage all the configurations in uVision!

I was thinking and investigating for a uVision generator some time ago
already. I was also talking to the people from Keil at the embedded world
congress about it. They did not like an approach using a template project
that would be filled in with contents derived from CMake. There approach
would be to generate a project-import file (xml) that can be imported with
uVision using the -i option (see http://www.keil.com/
support/man/docs/uv4/uv4_commandline.htm). The format of such a file is
specified in "C:\Keil_v5\UV4\project_import.xsd".

The problem with such an import is that the available options are not
sufficient for most cases.


> Does anyone have experience or insight in to creating a CMake generator
> for an
> embedded systems IDE like uVision?
>
> Read on for some technical details.
>
> A uVision project's structure appears _roughly_ similar to a Microsoft
> Visual
> Studio 12 project. uVision has a Multi-Project Workspace (.uvmpw) rather
> than a
> VS solution (.sln), and a uVision Project (.uvprojx) instead of a VS
> project
> (.vcxproj).


While looking at the directory that contains the project_import.xsd, I
struggled over the following files:

- project_optx.xsd
- project_mpw.xsd
- project_proj.xsd
- project_opt.xsd
- project_projx.xsd

Here, all the possible options for project-/opt-/uvmpw-files are defined.
Maybe these could be a starting-point for a uVision generator.


>
>

> Some of the benefits I would imagine we would get from such a generator:
>
> - more human-friendly and diff-friendly project files (CMakeLists.txt
> instead
>   of .uvprojx)
>
> - avoiding a combinatorial explosion of configurations by using the CMake
>   language and its cache variables.
>

I fully agree to these points!

--
Cheers!
 Marco

> ________________________________
>
> This e-mail message is confidential and for use by the addressee only. If
> you are not the intended recipient, you must not use, disclose, copy or
> forward this transmission. Please return the message to the sender by
> replying to it and then delete the message from your computer. Cambridge
> Medical Robotics shall not be held liable to any person resulting from the
> use of any information contained in this e-mail and shall not be liable to
> any person who acts or omits to do anything in reliance upon it. Cambridge
> Medical Robotics does not accept responsibility for changes made to this
> message after it was sent.
>
> Company Information:
> Name: Cambridge Medical Robotics Limited.
> Registered Address: Unit 2, Crome Lea Business Park, Madingley Road,
> Cambridge, CB23 7PH, UK.
> Registered as a Company in England: 08863657 VAT Number: GB 186 4383 74.
> info at cmedrobotics.com
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/f073e74c/attachment.html>

From brad.king at kitware.com  Thu Jan 12 09:44:59 2017
From: brad.king at kitware.com (Brad King)
Date: Thu, 12 Jan 2017 09:44:59 -0500
Subject: [cmake-developers] deprecate check_function_exists?
In-Reply-To: <CAKtrNpE_Np13kLcnvWSsgVBOCFcsm+dp70aRY5L92zwdnFzNAA@mail.gmail.com>
References: <CAKtrNpE_Np13kLcnvWSsgVBOCFcsm+dp70aRY5L92zwdnFzNAA@mail.gmail.com>
Message-ID: <6ca79d25-bfa4-5361-a41f-d55c3c4ac656@kitware.com>

On 01/11/2017 03:59 PM, Stephen Sorley wrote:
> So, could check_function_exists() be explicitly deprecated in the
> documentation in favor of check_symbol_exists()?

Yes.  Please submit a MR with proposed documentation updates.

There may still be use cases for the test that `check_function_exists`
performs, so I don't want to add an actual deprecation warning to it.
A documentation update will be fine though.

Thanks,
-Brad


From shmuelhcmake at gmail.com  Thu Jan 12 10:56:45 2017
From: shmuelhcmake at gmail.com (Shmuel H,)
Date: Thu, 12 Jan 2017 17:56:45 +0200
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CANZMcXp0KuOFtNd+QDdCiF1yG8VhN7gMrMqtHqidiYpQLEBO4w@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <CANZMcXp0KuOFtNd+QDdCiF1yG8VhN7gMrMqtHqidiYpQLEBO4w@mail.gmail.com>
Message-ID: <CAHQPbX8fdH98J6cySJCrNHjMwp2MjcuUnnJyMjzYyyMxWLRx4Q@mail.gmail.com>

Hi Daniel,

It is not about a specific problem with the CMake language, I have little
problems with almost every language (e.g. Python with its variable scopes
and destructors, C++ with a few strange standard decisions), nothing is
perfect.

However, I think that reinventing the wheel is very bad, especially when
there was no intention to create a wheel. The current CMake language is a
mix between a config file format and a programming language. Therefore, it
has a very strange and not intuitive syntax, as well as challenging scope
and variables management.  These are not "problems with a language",
problems can be fixed, in this case, fixing them would result a completely
different language.

Regards,
Shmuel.


On Thu, Jan 12, 2017 at 12:16 PM, Daniel Pfeifer <daniel at pfeifer-mail.de>
wrote:

> On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, <shmuelhcmake at gmail.com>
> wrote:
>
>> Hello,
>>
>> First of all, I have been using CMake for a few years now, it is awesome
>> tool, thank you.
>>
>> The only problem I currently have with CMake is its language, which has
>> not really intended to be one. After reading a few endless discussions
>> about this topic, I decided to give it a try and do something practical.
>>
>> My current design is using Python as an extension for the regular
>> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.
>>
>> It should not be too hard to maintain, the current API design uses only
>> 1-3 function that should be implemented in cmake.
>>
>> For more information, see the [closed] merge request #389
>> <https://gitlab.kitware.com/cmake/cmake/merge_requests/389>.
>>
>> I would be happy to hear your opinion about this idea.
>>
>
> Hello Shmuel,
>
> what do you find fault with the CMake language?  I have my own complaints
> about it, which may be completely orthogonal or even contradictory to yours.
>
> I am currently refactoring cmCommand and the way commands are interpreted
> in the CMake language. This refactoring will simplify porting the CMake
> language frontend to a different scripting engine. I have spent some
> thoughts on this and I have a very strong opinion about the direction.
>
> To avoid another "language X is better than Y" discussion, I will not go
> into more details. You should elaborate your motivation first.
>
> cheers, Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/ea81294b/attachment.html>

From jeanmichael.celerier at gmail.com  Thu Jan 12 12:28:23 2017
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Thu, 12 Jan 2017 18:28:23 +0100
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
Message-ID: <CAE1uMrUWNP-Rr-gdC1nDRvG_f8KP1LBap6CLFyEEpfuf+wZ_cQ@mail.gmail.com>

(My simple user opinion):

I'm not a fan of the idea.
Not particularly because of Python, but because with this, now
if I want to use a library that someone made with a CMakeLists.py in my
project
(for instance as a submodule) :
* I also have to install Python on the machines where the build happens,
* tell my users to install Python,
* add it to their PATH...

Many already have trouble just installing and running CMake, and this adds
another
potential layer of complexity, and a fragmentation of the ecosystem.
Unless CMake would ship with its own Python interpreter ?

I know, this is a non-problem on Linux and OS X (or is it ? On my machine
/usr/bin/python is python 3 but on others it is python 2),
but there are some poor people out there stuck with Windows machines, and I
wouldn't like their lives to be even harder.

Best regards
Jean-Micha?l

On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, <shmuelhcmake at gmail.com> wrote:

> Hello,
>
> First of all, I have been using CMake for a few years now, it is awesome
> tool, thank you.
>
> The only problem I currently have with CMake is its language, which has
> not really intended to be one. After reading a few endless discussions
> about this topic, I decided to give it a try and do something practical.
>
> My current design is using Python as an extension for the regular
> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.
>
> It should not be too hard to maintain, the current API design uses only
> 1-3 function that should be implemented in cmake.
>
> For more information, see the [closed] merge request #389
> <https://gitlab.kitware.com/cmake/cmake/merge_requests/389>.
>
> I would be happy to hear your opinion about this idea.
>
> Best regards,
> Shmuel H.
>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/5d77613a/attachment.html>

From shmuelhcmake at gmail.com  Thu Jan 12 12:35:41 2017
From: shmuelhcmake at gmail.com (Shmuel H,)
Date: Thu, 12 Jan 2017 19:35:41 +0200
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAE1uMrUWNP-Rr-gdC1nDRvG_f8KP1LBap6CLFyEEpfuf+wZ_cQ@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <CAE1uMrUWNP-Rr-gdC1nDRvG_f8KP1LBap6CLFyEEpfuf+wZ_cQ@mail.gmail.com>
Message-ID: <CAHQPbX8wvguXJ82FMNAnFk0B7S-ZWDt7pSTwHZiGSTCyK=ei7g@mail.gmail.com>

Hi Jean,

If that would be implemented, a python (or any other language) interpreter
would be included in CMake. However, Brad have a problem with that approach.

On Thu, Jan 12, 2017 at 7:28 PM, Jean-Micha?l Celerier <
jeanmichael.celerier at gmail.com> wrote:

> (My simple user opinion):
>
> I'm not a fan of the idea.
> Not particularly because of Python, but because with this, now
> if I want to use a library that someone made with a CMakeLists.py in my
> project
> (for instance as a submodule) :
> * I also have to install Python on the machines where the build happens,
> * tell my users to install Python,
> * add it to their PATH...
>
> Many already have trouble just installing and running CMake, and this adds
> another
> potential layer of complexity, and a fragmentation of the ecosystem.
> Unless CMake would ship with its own Python interpreter ?
>
> I know, this is a non-problem on Linux and OS X (or is it ? On my machine
> /usr/bin/python is python 3 but on others it is python 2),
> but there are some poor people out there stuck with Windows machines, and
> I wouldn't like their lives to be even harder.
>
> Best regards
> Jean-Micha?l
>
> On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, <shmuelhcmake at gmail.com>
> wrote:
>
>> Hello,
>>
>> First of all, I have been using CMake for a few years now, it is awesome
>> tool, thank you.
>>
>> The only problem I currently have with CMake is its language, which has
>> not really intended to be one. After reading a few endless discussions
>> about this topic, I decided to give it a try and do something practical.
>>
>> My current design is using Python as an extension for the regular
>> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.
>>
>> It should not be too hard to maintain, the current API design uses only
>> 1-3 function that should be implemented in cmake.
>>
>> For more information, see the [closed] merge request #389
>> <https://gitlab.kitware.com/cmake/cmake/merge_requests/389>.
>>
>> I would be happy to hear your opinion about this idea.
>>
>> Best regards,
>> Shmuel H.
>>
>> --
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/fd25369c/attachment.html>

From shmuelhcmake at gmail.com  Thu Jan 12 13:20:45 2017
From: shmuelhcmake at gmail.com (Shmuel H,)
Date: Thu, 12 Jan 2017 20:20:45 +0200
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
Message-ID: <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>

Hello Bard,

First of all, let me show my appreciation for an open source maintainer
that open for changes which is not a obvious.

The problem with a solution that doesn't add another language as a
dependency is that it creates incompatibility and requires installing of
more components in order to achieve a working system (e.g. Install Python,
Install a program that communicates with CMake Server, etc) which creates
the complete opposite of the "almost universal-compatible build system" the
CMake project has been able to achieve until now.

I'm interested in your reason behind the decision not to add Python as a
dependency: is that a licencing problem, a problem specific about Python,
or maybe a general problem with dependencies, which generally make our life
harder?

However, for me - a user, a known and well-designed programming language
for CMake would be very helpful. I can't say that for every other user, but
I think it would make their life a lot easier too.

Kind regards,
Shmuel.

On Thu, Jan 12, 2017 at 4:27 PM, Brad King <brad.king at kitware.com> wrote:

> On 01/11/2017 04:23 PM, Shmuel H, wrote:
> > a few endless discussions about this topic
>
> Previous discussions have not ended in a new language being integrated,
> but that does not mean they failed.  Several challenges w.r.t. the
> internal architecture were identified.  A lot of progress has been made
> in addressing some of those, but there is more work to do.  The goal is
> to separate the representation of the build system model that is fed to
> the generators from the current CMake language implementation.  Once that
> is done then other approaches/languages can be added to build the model
> instead of using the current language exclusively.
>
> > My current design is using Python as an extension for the regular
> > CMakeLists.txt files: if there is a CMakeLists.py file, it would be
> loaded.
>
> We'd rather not introduce Python as a dependency of CMake's distribution,
> even optionally.  It may be reasonable to have optional support when Python
> can be found at runtime.  However, any such approach would need to avoid
> requiring dynamic loading of plugins into CMake or any kind of stable
> C++ API to be maintained.
>
> Since previous such discussions we've now had the cmake-server mode
> introduced.  It allows programs written in any language to communicate
> with CMake through a JSON protocol.  Currently the protocol is very
> minimal and geared toward IDEs that want to get a representation of the
> build system after configuration of a build tree.
>
> A similar approach could be used to interact with external processes
> during configuration.  Such a protocol would allow programs written
> in any language to be used for defining CMake build systems.
>
> Previous discussions have also identified the value of having a declarative
> specification format.  This is largely orthogonal to the procedural
> language
> that drives the configuration process because any such language could still
> have a command/step that loads the declarative part.
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/7447158e/attachment-0001.html>

From stephen.sorley at gmail.com  Thu Jan 12 13:22:00 2017
From: stephen.sorley at gmail.com (Stephen Sorley)
Date: Thu, 12 Jan 2017 13:22:00 -0500
Subject: [cmake-developers] deprecate check_function_exists?
In-Reply-To: <6ca79d25-bfa4-5361-a41f-d55c3c4ac656@kitware.com>
References: <CAKtrNpE_Np13kLcnvWSsgVBOCFcsm+dp70aRY5L92zwdnFzNAA@mail.gmail.com>
 <6ca79d25-bfa4-5361-a41f-d55c3c4ac656@kitware.com>
Message-ID: <CAKtrNpF9VkX2dtuYGrDt3H7-HgSTeC3N99vuskhz+Cic+k2jMA@mail.gmail.com>

Thanks Brad, I've created the merge request here:

https://gitlab.kitware.com/cmake/cmake/merge_requests/394

-Stephen Sorley

On Thu, Jan 12, 2017 at 9:44 AM, Brad King <brad.king at kitware.com> wrote:

> On 01/11/2017 03:59 PM, Stephen Sorley wrote:
> > So, could check_function_exists() be explicitly deprecated in the
> > documentation in favor of check_symbol_exists()?
>
> Yes.  Please submit a MR with proposed documentation updates.
>
> There may still be use cases for the test that `check_function_exists`
> performs, so I don't want to add an actual deprecation warning to it.
> A documentation update will be fine though.
>
> Thanks,
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/be4adc6f/attachment.html>

From mikedld at mikedld.com  Thu Jan 12 15:39:36 2017
From: mikedld at mikedld.com (Mike Gelfand)
Date: Thu, 12 Jan 2017 23:39:36 +0300
Subject: [cmake-developers] install/local/fast and install/strip/fast are
	not fast
Message-ID: <bd5a9bfb-637b-cb57-0370-0764dbc91788@mikedld.com>

Hello everyone,


Didn't trace back when this happened, but for quite a long time now
install/local/fast and install/strip/fast targets, at least when using
"Unix Makefiles" generator, are not at all fast. They depend on
install/local and install/strip targets respectively instead of
preinstall/fast and don's contain any commands instead of repeating
commands in install/local and install/strip.


The patch that follows (against current master) is enough to make things
right.


Regards,

Mike


--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -1592,8 +1592,8 @@ void
cmLocalUnixMakefileGenerator3::WriteLocalAllRules(
 
       // Provide a "/fast" version of the target.
       depends.clear();
-      if ((targetName == "install") || (targetName == "install_local") ||
-          (targetName == "install_strip")) {
+      if ((targetName == "install") || (targetName == "install/local") ||
+          (targetName == "install/strip")) {
         // Provide a fast install target that does not depend on all
         // but has the same command.
         depends.push_back("preinstall/fast");


From mikedld at mikedld.com  Thu Jan 12 17:37:53 2017
From: mikedld at mikedld.com (Mike Gelfand)
Date: Fri, 13 Jan 2017 01:37:53 +0300
Subject: [cmake-developers] install/local/fast and install/strip/fast
 are not fast
In-Reply-To: <bd5a9bfb-637b-cb57-0370-0764dbc91788@mikedld.com>
References: <bd5a9bfb-637b-cb57-0370-0764dbc91788@mikedld.com>
Message-ID: <6fcb02ac-b284-8fbf-8593-f644619d8345@mikedld.com>

Opened a MR for your convenience:
https://gitlab.kitware.com/cmake/cmake/merge_requests/397

Regards,
Mike

From comicfans44 at gmail.com  Thu Jan 12 20:47:01 2017
From: comicfans44 at gmail.com (comic fans)
Date: Fri, 13 Jan 2017 09:47:01 +0800
Subject: [cmake-developers] [RFC] Fastbuild generator
In-Reply-To: <CAGTK6mb0KquzoxBRftO1N-Do89=umhcOp0ky=GVpS4ohxpS2Hw@mail.gmail.com>
References: <CAKzW8o=KvuksvXuwCZoxUDW6aYiYa+JtRKwpPV5kTEEdg1Yaiw@mail.gmail.com>
 <CAGTK6mb0KquzoxBRftO1N-Do89=umhcOp0ky=GVpS4ohxpS2Hw@mail.gmail.com>
Message-ID: <CAKzW8okpowyRhWrK+H6nHSYJzyOsfRer=VjbVe-ck8DSgLJEyg@mail.gmail.com>

I hope I've known this earlier so I can do less... and I'll goto your branch and
join gitter channel to discuss .

On Mon, Jan 9, 2017 at 5:12 PM, Charles Huet <charles.huet at gmail.com> wrote:
> Hi,
>
> I ported the work of @inbilla to CMake trunk a few months ago, and fixed
> quite a few tests on my fork: https://github.com/packadal/CMake
>
> I think it would be best if we tried to synchronize our efforts, since lots
> of people are interested in getting a FastBuild generator for CMake !
> There is a gitter channel that is used to discuss the progress here:
> https://gitter.im/inbilla/CMake
>
> I hope we can get this to work well enough to be iontegrated in CMake 3.8,
> but I did not have time to work on this lately.
> I hope to get back to it this week, but I am always available for discussion
> :)
>
> Best
>
>
> Le dim. 8 janv. 2017 ? 05:59, comic fans <comicfans44 at gmail.com> a ?crit :
>>
>> Hello:
>>
>> Fastbuild is a opensource multi platform build tool which has built-in
>> cache/distribute (likes ccache/distcc) and pch/unity build
>> support(http://fastbuild.org/docs/home.html).
>>
>>
>> @inbilla created fastbuild generator based on 3.2.1 here
>> https://github.com/inbilla/CMake , this completed almost everything
>> but didn't continue developing for a while. recently I've rebase his
>> work on master branch, with some
>> tweaks(https://gitlab.kitware.com/comicfans/cmake/commits/upstream2),now
>> it can builds cmake , and almost llvm/clang,  so I'd like to share
>> this here, hopes more user to test this out.
>>
>> I haven't touch cmake code before so it may not as good as you think.
>> If anyone interested to try this code, any comments and suggestion
>> would be helpful.
>>
>>
>> How Fastbuild compares to Ninja :
>> If build locally, fastbuild almost as fast as ninja , but fastbuild
>> provides simpler distrubte support,you can just run fastbuild worker
>> on many woker machine (without need to install toolchain) to speed up.
>> As I tested,
>>
>> host (4core4thread 8GB ) local build clang:  60 min
>> host + worker (6core12thread 32GB) distrubite clang : 30 min
>>
>> Fastbuild Generator current status:
>>
>>  local build works on linux/windows (I don't have mac to test)
>>
>>  some cmake variable not set correctly (RUNTIME_OUTPUT_DIRECTORY,
>> LIBRARY_OUTPUT_DIRECTORY,  how to put CFGIntDir in ?  help needed !),
>>
>>  distrubte build not work (you can list toolchain exe/dll in header,
>> or just copy header from fastbuild src's to make distribute build
>> work) I wonder if cmake has builtin support to list all these files,
>> help needed!
>>
>> config/build on windows must run from vs cmd console, because cmake
>> didn't detect windows SDK for include/link path (Ninja generator also
>> suffer from this). help needed.
>>
>> edit CMake files didn't auto trigger fastbuild auto rebuild, must rerun
>> cmake
>>
>> rerun cmake makes fastbuild rebuild everything. this is fastbuild's
>> shortcoming, author is working on this.
>>
>> custom commands will generate script file (bash/bat) ,should we write
>> commands as argument to sh/cmd , or improve this in fastbuild ?
>> --
>>
>> 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

From brad.king at kitware.com  Fri Jan 13 10:56:22 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 13 Jan 2017 10:56:22 -0500
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
Message-ID: <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>

On 01/12/2017 01:20 PM, Shmuel H, wrote:
> maybe a general problem with dependencies, which generally
> make our life harder?

Yes.  People typically install CMake only in order to build something else.
If Python were added as an external dependency then that would be yet
another step.  If it were bundled then our bootstrap script and CMake-based
build of CMake itself would both have to learn to build Python.  Python
is also a distribution in addition to a language, so deploying it raises
the question of what to bundle with it.  None of these is something I'd
like to have added to the responsibilities of maintaining and distributing
CMake.

There are already other build systems that use Python as their language,
but many people still choose CMake over them anyway.

> However, for me - a user, a known and well-designed programming language
> for CMake would be very helpful. I can't say that for every other user,
> but I think it would make their life a lot easier too. 

As Charles Huet mentioned Lua is a good choice because it provides a
language and is portable to everywhere that has C.  It is also not a
distribution.  I've posted in the past a design for a cmake_lua command
that allows one to use Lua code within CMakeLists.txt files.  Actually
using it as a full replacement language though will first require more
refactoring internally as I mentioned in my previous post.

As I've mentioned in previous discussions, if we're going to go through
a language change we should make sure it addresses important needs.
Having a declarative specification that can be externally tooled will
be helpful to IDEs.  I'd envision such a format that is then imported
by the procedural-language part of the configuration process for
evaluation of conditions and finalization for the current target.

Without a comprehensive design I'm hesitant to proceed on any such effort.

-Brad

From egor.pugin at gmail.com  Fri Jan 13 11:05:47 2017
From: egor.pugin at gmail.com (Egor Pugin)
Date: Fri, 13 Jan 2017 19:05:47 +0300
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
Message-ID: <CAHtU+mq_YTQf1fQ0hJ8V5zaVucx_NaOA6qhhijOgPg7Q-D5r-g@mail.gmail.com>

Hi,

Why not just use C/C++ for writing build system (bs) rules?
C++ is for those who have modern compilers. (By C++ I mean modern C++11-14-17).
C is for everything. These two apis can coexist.

CMake first will build bs itself (e.g. into shared library) and then
load and execute it on the source tree.

I'll investigate this in my C++ Archive Network [1] project very soon.
Now I have mentioned here declarative (YAML) syntax with custom CMake
insertions. For example, see specifications [2-5].

[1] https://cppan.org/
[2] https://cppan.org/pvt.cppan.demo.sqlite3/version/3.16.1/specification
[3] https://cppan.org/pvt.cppan.demo.unicode.icu.i18n/version/58.2.0/specification
[4] https://cppan.org/pvt.cppan.demo.webp/version/0.5.1/specification
[5] https://cppan.org/pvt.cppan.demo.boost.conversion/version/1.62.0/specification

On 13 January 2017 at 18:56, Brad King <brad.king at kitware.com> wrote:
> On 01/12/2017 01:20 PM, Shmuel H, wrote:
>> maybe a general problem with dependencies, which generally
>> make our life harder?
>
> Yes.  People typically install CMake only in order to build something else.
> If Python were added as an external dependency then that would be yet
> another step.  If it were bundled then our bootstrap script and CMake-based
> build of CMake itself would both have to learn to build Python.  Python
> is also a distribution in addition to a language, so deploying it raises
> the question of what to bundle with it.  None of these is something I'd
> like to have added to the responsibilities of maintaining and distributing
> CMake.
>
> There are already other build systems that use Python as their language,
> but many people still choose CMake over them anyway.
>
>> However, for me - a user, a known and well-designed programming language
>> for CMake would be very helpful. I can't say that for every other user,
>> but I think it would make their life a lot easier too.
>
> As Charles Huet mentioned Lua is a good choice because it provides a
> language and is portable to everywhere that has C.  It is also not a
> distribution.  I've posted in the past a design for a cmake_lua command
> that allows one to use Lua code within CMakeLists.txt files.  Actually
> using it as a full replacement language though will first require more
> refactoring internally as I mentioned in my previous post.
>
> As I've mentioned in previous discussions, if we're going to go through
> a language change we should make sure it addresses important needs.
> Having a declarative specification that can be externally tooled will
> be helpful to IDEs.  I'd envision such a format that is then imported
> by the procedural-language part of the configuration process for
> evaluation of conditions and finalization for the current target.
>
> Without a comprehensive design I'm hesitant to proceed on any such effort.
>
> -Brad
> --
>
> 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



-- 
Egor Pugin

From brad.king at kitware.com  Fri Jan 13 11:15:19 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 13 Jan 2017 11:15:19 -0500
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHtU+mq_YTQf1fQ0hJ8V5zaVucx_NaOA6qhhijOgPg7Q-D5r-g@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHtU+mq_YTQf1fQ0hJ8V5zaVucx_NaOA6qhhijOgPg7Q-D5r-g@mail.gmail.com>
Message-ID: <a3be1104-86bb-b0b4-6c00-85d2178a9837@kitware.com>

On 01/13/2017 11:05 AM, Egor Pugin wrote:
> Why not just use C/C++ for writing build system (bs) rules?
> 
> CMake first will build bs itself (e.g. into shared library) and then
> load and execute it on the source tree.

In an earlier post of this thread I said that no dynamic loading will
be allowed.  We used to have the `load_command` command but it is now
deprecated.  This approach simply doesn't work because we can't know
that the toolchains can compile for CMake's architecture on the host.
Certainly we're not going to include a C++ JIT in CMake itself ;)

> I'll investigate this in my C++ Archive Network [1] project very soon.
> Now I have mentioned here declarative (YAML) syntax with custom CMake
> insertions. For example, see specifications [2-5].

YAML may be a nice choice for a declarative spec, especially because
it can just contain JSON too.  One requirement for such a format is
that it is possible for a tool to read the entire spec, make small
modifications, and write it back out as close as possible to the
original format.  The idea is that "git diff" should only show the
changes made by the tool.  This means a standard layout would need
to be defined.

-Brad


From konstantin at podsvirov.pro  Fri Jan 13 11:09:09 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Fri, 13 Jan 2017 19:09:09 +0300
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
Message-ID: <2776281484323749@web22g.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170113/39f3b496/attachment.html>

From egor.pugin at gmail.com  Fri Jan 13 11:29:55 2017
From: egor.pugin at gmail.com (Egor Pugin)
Date: Fri, 13 Jan 2017 19:29:55 +0300
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <a3be1104-86bb-b0b4-6c00-85d2178a9837@kitware.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHtU+mq_YTQf1fQ0hJ8V5zaVucx_NaOA6qhhijOgPg7Q-D5r-g@mail.gmail.com>
 <a3be1104-86bb-b0b4-6c00-85d2178a9837@kitware.com>
Message-ID: <CAHtU+mrg4cHBhQDzGytGEuy+jo_qgivTYV0QGAKLvvZ0_gnfbw@mail.gmail.com>

> One requirement for such a format is
> that it is possible for a tool to read the entire spec, make small
> modifications, and write it back out as close as possible to the
> original format.

I have such yaml formatting function for my layout.
You may see those pretty specs I've posted.
At the moment it lacks of some deep nodes formatting, but the overall
structure is preserved. See [1].

> This means a standard layout would need to be defined.

And my current layout [2] (from that function too).

[1] https://github.com/cppan/cppan/blob/master/src/common/yaml.cpp#L171
[2] https://github.com/cppan/cppan/blob/master/src/common/yaml.cpp#L196

On 13 January 2017 at 19:15, Brad King <brad.king at kitware.com> wrote:
> On 01/13/2017 11:05 AM, Egor Pugin wrote:
>> Why not just use C/C++ for writing build system (bs) rules?
>>
>> CMake first will build bs itself (e.g. into shared library) and then
>> load and execute it on the source tree.
>
> In an earlier post of this thread I said that no dynamic loading will
> be allowed.  We used to have the `load_command` command but it is now
> deprecated.  This approach simply doesn't work because we can't know
> that the toolchains can compile for CMake's architecture on the host.
> Certainly we're not going to include a C++ JIT in CMake itself ;)
>
>> I'll investigate this in my C++ Archive Network [1] project very soon.
>> Now I have mentioned here declarative (YAML) syntax with custom CMake
>> insertions. For example, see specifications [2-5].
>
> YAML may be a nice choice for a declarative spec, especially because
> it can just contain JSON too.  One requirement for such a format is
> that it is possible for a tool to read the entire spec, make small
> modifications, and write it back out as close as possible to the
> original format.  The idea is that "git diff" should only show the
> changes made by the tool.  This means a standard layout would need
> to be defined.
>
> -Brad
>



-- 
Egor Pugin

From shmuelhcmake at gmail.com  Fri Jan 13 11:45:07 2017
From: shmuelhcmake at gmail.com (Shmuel H,)
Date: Fri, 13 Jan 2017 18:45:07 +0200
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
Message-ID: <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>

I think that the special thing about CMake, is the option to customize a
build system (if needed). This is also the thing that makes CMake harder to
use than other declarative-based build systems.

Therefore, I think we should combine these things together:

   - From one side, we would have (for example) a global list of targets
   with the option to export it to (for example) a JSON document and then
   simply load it.
   - From the other side, programmers should be able to use a script
   language to customize their build process.

That would enable programmers, IDEs and automated tools to create a valid
and simple documents for simple projects and also would give programmers
the power they need in order to customize cmake for their needs.

For example, a simple declaration (pseudo code):
cmake_libraries += {
                                   ["name":      "myLib",
                                    "files":         "myLib.c",
                                    "link_type": "static"]
                                }

And a customized script for easily adding a library for a cpp class:
def my_add_library(name, class_name):
    cmake_libraries += {
                                       ["name":      name,
                                        "files":         [class_name +
'.cpp', class_name + '.h'],
                                        "link_type": MY_LINK_TYPE]
                                    }

# Then, add my customized library:
 my_add_library('myLib', 'myLib')

Note that it still would be possible to export these "scripted files" to a
simple JSON file.

I would be happy to hear your opinion about this general design.


On Fri, Jan 13, 2017 at 5:56 PM, Brad King <brad.king at kitware.com> wrote:

> On 01/12/2017 01:20 PM, Shmuel H, wrote:
> > maybe a general problem with dependencies, which generally
> > make our life harder?
>
> Yes.  People typically install CMake only in order to build something else.
> If Python were added as an external dependency then that would be yet
> another step.  If it were bundled then our bootstrap script and CMake-based
> build of CMake itself would both have to learn to build Python.  Python
> is also a distribution in addition to a language, so deploying it raises
> the question of what to bundle with it.  None of these is something I'd
> like to have added to the responsibilities of maintaining and distributing
> CMake.
>
> There are already other build systems that use Python as their language,
> but many people still choose CMake over them anyway.
>
> > However, for me - a user, a known and well-designed programming language
> > for CMake would be very helpful. I can't say that for every other user,
> > but I think it would make their life a lot easier too.
>
> As Charles Huet mentioned Lua is a good choice because it provides a
> language and is portable to everywhere that has C.  It is also not a
> distribution.  I've posted in the past a design for a cmake_lua command
> that allows one to use Lua code within CMakeLists.txt files.  Actually
> using it as a full replacement language though will first require more
> refactoring internally as I mentioned in my previous post.
>
> As I've mentioned in previous discussions, if we're going to go through
> a language change we should make sure it addresses important needs.
> Having a declarative specification that can be externally tooled will
> be helpful to IDEs.  I'd envision such a format that is then imported
> by the procedural-language part of the configuration process for
> evaluation of conditions and finalization for the current target.
>
> Without a comprehensive design I'm hesitant to proceed on any such effort.
>
> -Brad
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170113/cef60632/attachment.html>

From davispuh at gmail.com  Fri Jan 13 13:16:16 2017
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Fri, 13 Jan 2017 20:16:16 +0200
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAGTK6mYKWdACmQ7GtW8Oz+WbnDvEPodXbxEbtN4_qb8QnYCN-g@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <CAGTK6mYKWdACmQ7GtW8Oz+WbnDvEPodXbxEbtN4_qb8QnYCN-g@mail.gmail.com>
Message-ID: <CAOE4rSwX6GFEz1ZBCpFgbf5=aoDyKNDLxYEa=EKxHPUjWMzzBA@mail.gmail.com>

2017-01-12 11:48 GMT+02:00 Charles Huet <charles.huet at gmail.com>:
[...]
> Lua is the language that should be used, since it is easy to embed on all
> the platforms CMake supports. All arguments about language X being better
> than language Y do not matter, since all other languages do not answer to
> the constraints that are CMake's, which are, as I understand them:
> - being embeddable so as to not depend on the user to install something else
> - support for lots of various platforms (e.g. ARM)
>

Lua isn't only option, there is also [1] mruby (embedded Ruby)
compiles to C library which can be statically linked. It also is very
customizable, you can compile only those features which you need.


[1] https://github.com/mruby/mruby

From robert.maynard at kitware.com  Fri Jan 13 14:21:53 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 13 Jan 2017 14:21:53 -0500
Subject: [cmake-developers] [ANNOUNCE] CMake 3.7.2 available for download
Message-ID: <CAFzjYVphqzA9A69gH6amk6n9_sdAn0WRo7=Ad6WyJC3nu99xAg@mail.gmail.com>

We are pleased to announce that CMake 3.7.2 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.7.2 since 3.7.1:

Aleix Pol (1):
      cmake-server: Do not try watching subdirectories with empty names

Brad King (4):
      VS: Add v141 flag table entry for `-Zc:inline-`
      VS: Add v140 flag table entries for `-Zc:inline[-]`
      VS: Fix standalone Windows7.1SDK toolset selection
      CMake 3.7.2

Roger Leigh (1):
      FindBoost: Add support for 1.63

Rolf Eike Beer (1):
      FindPostgreSQL: automatically find installations from yum.postgresql.org

Tobias Hunger (3):
      server-mode: Do not ignore the first cacheArgument on configure
      server-mode: Call ResetErrorOccured before configure
      server-mode: Do not crash when running into INTERFACE_LIBRARY

Vic Luo (1):
      FindBoost: Add support for VS 2017

From brad.king at kitware.com  Fri Jan 13 14:28:38 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 13 Jan 2017 14:28:38 -0500
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
Message-ID: <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>

On 01/13/2017 11:45 AM, Shmuel H, wrote:
> * From the other side, programmers should be able to use a script
>   language to customize their build process.
> 
> For example, a simple declaration (pseudo code):
> cmake_libraries += {
>                                    ["name":      "myLib",
>                                     "files":         "myLib.c",
>                                     "link_type": "static"]
>                                 }

The declarative part needs to be self-standing so that it can be loaded
by an IDE, edited by the user, and saved back out in the original format
with a minimal diff.  An IDE will have no idea how to write snippets back
into a procedural script.  This is one reason CMakeLists.txt files cannot
be edited through an IDE except as text files.

My proposal is that the declarative part would have most of the build,
but with some kind of named condition/config variables.  Then the
procedural part will introspect the system to determine the values of
the configuration variables so that CMake can evaluate the conditions.

-Brad


From shmuelhcmake at gmail.com  Sat Jan 14 03:27:34 2017
From: shmuelhcmake at gmail.com (Shmuel H,)
Date: Sat, 14 Jan 2017 10:27:34 +0200
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
Message-ID: <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>

Maybe we could combine them together: the configuration process would be
separated into two stages:

   1. Script stage: Look for and run build script, that will generate a
   [JSON] configuration file.
   2. Look for a configuration file, and generate build files according to
   it.

Then, a programmer should decide if he need to use the script stage. If
not, he would be able to edit it all with its favorite IDE. If he need the
script stage, he would not be able to edit it with a automatic tools.

I think we should make the configuration files as simple as we can (`cbp`
files are not a good example for a simple file): usable defaults for
fields, etc.

Adding named condition \ variables would serve only a part of developers
needs (for example, choosing source files according to the current OS) but
it would prevent developers from being able to customize their building
with functions (For example, applying a long set of configurations for each
build target to be used as a plugin for an application with a lot of
restrictions).

On Fri, Jan 13, 2017 at 9:28 PM, Brad King <brad.king at kitware.com> wrote:

> On 01/13/2017 11:45 AM, Shmuel H, wrote:
> > * From the other side, programmers should be able to use a script
> >   language to customize their build process.
> >
> > For example, a simple declaration (pseudo code):
> > cmake_libraries += {
> >                                    ["name":      "myLib",
> >                                     "files":         "myLib.c",
> >                                     "link_type": "static"]
> >                                 }
>
> The declarative part needs to be self-standing so that it can be loaded
> by an IDE, edited by the user, and saved back out in the original format
> with a minimal diff.  An IDE will have no idea how to write snippets back
> into a procedural script.  This is one reason CMakeLists.txt files cannot
> be edited through an IDE except as text files.
>
> My proposal is that the declarative part would have most of the build,
> but with some kind of named condition/config variables.  Then the
> procedural part will introspect the system to determine the values of
> the configuration variables so that CMake can evaluate the conditions.
>
> -Brad
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170114/51ee93df/attachment.html>

From craig.scott at crascit.com  Sat Jan 14 20:23:51 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Sun, 15 Jan 2017 12:23:51 +1100
Subject: [cmake-developers] COMPILE_FEATURES,
	Mac and non-Apple clang versions
In-Reply-To: <o4mq12$56i$1@blaine.gmane.org>
References: <2723217.JG0fgKC0bN@portia.local> <3272629.CleqpXTdn0@portia.local>
 <CAFzjYVp6arDGFopJtUja5oywqb3gQQAM5vegZkzCLkAqVP7HtA@mail.gmail.com>
 <2026573.QpI33mtGQh@portia.local> <o4hgg2$f0g$1@blaine.gmane.org>
 <CA+dygY=FNgsCCWWf-fgOoB7xf18kmBJEtFwkWwXopci8PZjTfg@mail.gmail.com>
 <o4mq12$56i$1@blaine.gmane.org>
Message-ID: <CA+dygYmv5njh7ArPR4Odigk85kaL5ShS3GnNKxUHa9KOkuJiPA@mail.gmail.com>

On Fri, Jan 6, 2017 at 11:57 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Craig Scott wrote:
>
> >> if you use add_subdirectory with top-level projects which don't
> >> explicitly do something like that, you're getting undefined , and
> >> generally unexpected behavior in many ways.
> >
> > This seems at odds with the CMake documentation for
> > cmake_minimum_required(). That documentation talks about calling
> > cmake_minimum_required() within a function as a valid case
>
> I don't know why using that command inside a function would be a good idea.
>
> What would you be trying to achieve with putting it in a function not near
> the top? Can you give an example?
>


That wasn't my point, I was only indicating that the documentation seems to
indicate it's a valid thing to do. I wouldn't argue that's it's a *useful*
thing to do. ;)



> > We have many projects which do exactly the scenario you mention above
> > where a project can be built standalone or added to another project via
> > add_subdirectory(). We have not found it necessary to test if a project
> is
> > top level or not before calling cmake_minimum_required().
>
> My comment should have been more-general in that the contained project
> should be designed to be 'inlined as a subdirectory' like that and it
> otherwise shouldn't be done.
>
> There are many pitfalls. I have encountered at least one pitfall resulting
> from cmake_minimum_required being unconditional which I don't remember now
> unfortunately. Perhaps the problem was my inexperience to understand
> messages I was seeing and what I expected from the code.
>
> Others include
>
> * conflicting target names
> * conflicting option()s, or option()s which shouldn't be exposed
> * modification of global or cache variables affecting the container project
> in unexpected ways such as modifying compile flags
> * possibly odd behavior if you have multiple include(CTest) or
> include(CPack) in different directories
> * projects which assume CMAKE_SOURCE_DIR is their top-level and use
> something like include($CMAKE_SOURCE_DIR}/cmake/MyPrivateMacros.cmake)
> * deliberate checks for top-level in a file include()d in multiple
> locations
> in the project.
>
> Sure, you can test things out when you add a new
>
>  add_subdirectory(random_github_clone)
>
> but just because it works (enough! - do any of them use CMAKE_SOURCE_DIR
> and
> it doesn't cause *visible* problems?) with all of the external projects
> you've tried so far doesn't mean you can expect it to work with any
> external
> project.
>
> For me, that's as close as you get to 'undefined behavior' in CMake code.
>
>
We use the approach mostly with projects under our control, so we can
address the various issues you mentioned such that projects are safe to use
in this way. Even for the 3rd party projects we use, we set the git tag to
a known sha and can work through any issues to get the behaviour we want
for that specific snapshot of their code in most cases. There are a few
tricks you can use to inject things into such projects without having to
edit them (e.g. fixing missing INTERFACE dependencies with the various
target_xxx commands and using the CMAKE_PROJECT_<PROJECT-NAME_INCLUDE
variable to inject addition CMake code). But your point that you are at the
mercy of such projects assuming they are the top level project is one of
the more annoying aspects of using this approach.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170115/a12bb413/attachment.html>

From csiga.biga at aol.com  Mon Jan 16 05:46:04 2017
From: csiga.biga at aol.com (csiga.biga at aol.com)
Date: Mon, 16 Jan 2017 11:46:04 +0100
Subject: [cmake-developers] [Discussion] Add python support forCMakeLists
In-Reply-To: <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
 <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
Message-ID: <mailman.0.1484563906.15417.cmake-developers@cmake.org>

This all rhymes fairly well with an earlier suggestion of mine, CMake IR, a stateless intermediate representation. Though I originally suggested this feature to facilitate the authoring of generators, it could?ve also act as an alternative front-end, other than the CMake script language (which is still the least friendliest part in CMake, hence these attempts of ridding it in favor of friendlier scripting languages).

The scenario depicted here is pretty much doable already, but not in CMake terms. The stateless part is pretty much MSBuild, built atop XML with well defined schemas for the various build steps (C++ build, C++ link, C# build, etc.), and there is a custom target that has pre-build, build, and post-build steps (as all other targets as well). If you?d invoke Python there, you?re pretty much at the place you depict here. Using MSBuild, you?d only need a schema to invoke CMake targets to interoperate with current CMake projects.

One of the reasons why VS is so successful, is because you don?t need to invoke voodoo to acomplish something as simple as a build. Click-click and you?re done. This is because the build representation is SIMPLE (just XML). I understand that the reason why CMakes script language only has one type, the string type is because it is the common denominator for all the target generators and it is easy to handle inside generator implementations, but heck, it?s a pain to use. The fact that source files to add_executable() may be a list, but target_compile_definitions cannot? it?s a joke. I have to manually insert spaces in between compiler options.

Apologies if my tone is harsh at times, but I believe CMake could do a lot better. Server Mode is welcome sight, but it?s pretty much a workaround, or at least half the job. I believe CMake really needs to open to other front-ends than its script language, and Server Mode only compliments this. I understand that it becomes an N*M issue at this point, but heck; we have lived with containers and iterators (abstractions in general) that go around this issue.

MSBuild going cross-platform thanks to .Net Core renders it a compelling alternative for everyday tasks. (And I still have not touched upon Scons, Cake, Fake, Psbuild and the likes.)

Felad?: Shmuel H,
Elk?ldve: 2017. janu?r 14., szombat 9:27
C?mzett: Brad King
M?solatot kap: CMake Developers
T?rgy: Re: [cmake-developers] [Discussion] Add python support forCMakeLists

Maybe we could combine them together: the configuration process would be separated into two stages:
1. Script stage: Look for and run build script, that will generate a [JSON] configuration file.
2. Look for a configuration file, and generate build files according to it.
Then, a programmer should decide if he need to use the script stage. If not, he would be able to edit it all with its favorite IDE. If he need the script stage, he would not be able to edit it with a automatic tools.

I think we should make the configuration files as simple as we can (`cbp` files are not a good example for a simple file): usable defaults for fields, etc.

Adding named condition \ variables would serve only a part of developers needs (for example, choosing source files according to the current OS) but it would prevent developers from being able to customize their building with functions (For example, applying a long set of configurations for each build target to be used as a plugin for an application with a lot of restrictions).

On Fri, Jan 13, 2017 at 9:28 PM, Brad King <brad.king at kitware.com> wrote:
On 01/13/2017 11:45 AM, Shmuel H, wrote:
> * From the other side, programmers should be able to use a script
>? ?language to customize their build process.
>
> For example, a simple declaration (pseudo code):
> cmake_libraries += {
>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ["name":? ? ? "myLib",
>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"files":? ? ? ? ?"myLib.c",
>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"link_type": "static"]
>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}

The declarative part needs to be self-standing so that it can be loaded
by an IDE, edited by the user, and saved back out in the original format
with a minimal diff.? An IDE will have no idea how to write snippets back
into a procedural script.? This is one reason CMakeLists.txt files cannot
be edited through an IDE except as text files.

My proposal is that the declarative part would have most of the build,
but with some kind of named condition/config variables.? Then the
procedural part will introspect the system to determine the values of
the configuration variables so that CMake can evaluate the conditions.

-Brad

--

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170116/e5345b4d/attachment.html>

From brad.king at kitware.com  Mon Jan 16 14:47:09 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 16 Jan 2017 14:47:09 -0500
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
 <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
Message-ID: <e92d1169-1eec-0ccb-e19d-41e2ae66b4fe@kitware.com>

On 01/14/2017 03:27 AM, Shmuel H, wrote:
>  1. Script stage: Look for and run build script, that will generate a
>     [JSON] configuration file.

My point is that an IDE should be able to edit the declarative spec
without having run a configuration or even create a build tree.  The
spec should be the preferred form for making changes and stored in
version control.  Any intermediate spec generated by a procedural
language script cannot serve this role.

-Brad


From shmuelhcmake at gmail.com  Mon Jan 16 15:02:42 2017
From: shmuelhcmake at gmail.com (Shmuel H,)
Date: Mon, 16 Jan 2017 22:02:42 +0200
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <e92d1169-1eec-0ccb-e19d-41e2ae66b4fe@kitware.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
 <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
 <e92d1169-1eec-0ccb-e19d-41e2ae66b4fe@kitware.com>
Message-ID: <CAHQPbX9JPvN8SQzZbUFLGWFE-fkLw6JPaCzV5-DF=cFN9+eNGQ@mail.gmail.com>

> My point is that an IDE should be able to edit the declarative spec
> without having run a configuration or even create a build tree.  The
> spec should be the preferred form for making changes and stored in
> version control.  Any intermediate spec generated by a procedural
> Language script cannot serve this role.

I understand that. Maybe we should let the user decide whether to use the
advantages the declarative spec or to use a script to generate it. That
way, we would not lose the scripting future, which is a big future of
CMake. On the other side, we would not force users to use that and even we
would make it a lot easier for IDEs to manage these projects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170116/84e82adf/attachment.html>

From florent.castelli at gmail.com  Mon Jan 16 15:40:47 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Mon, 16 Jan 2017 21:40:47 +0100
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <CAHQPbX9JPvN8SQzZbUFLGWFE-fkLw6JPaCzV5-DF=cFN9+eNGQ@mail.gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
 <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
 <e92d1169-1eec-0ccb-e19d-41e2ae66b4fe@kitware.com>
 <CAHQPbX9JPvN8SQzZbUFLGWFE-fkLw6JPaCzV5-DF=cFN9+eNGQ@mail.gmail.com>
Message-ID: <DE0ABF6B-9964-4771-97D5-BD72913B12CF@gmail.com>

Well, CMake scripts can be written in a somewhat declarative form now.
What prevents this now is that a lot of people use indirections everywhere. For example: add_library(foo STATIC ${SRCS})
If it was a plain list, any decent IDE would be able to parse this and add another file to the list easily.
If some commands allowed more expressive alternative forms, it would definitely improve the situation:

add_library(foo STATIC
  bar1.c
  bar2.c
  WINDOWS
  windows-specific.c
  APPLE
  apple-specific.m
)

I find that most of the conditionals are just to create the list of sources per platform and then the list of dependencies. It?s certainly possible to use generator expressions for some cases, but they don?t have the prettiest syntax around, and maybe also not access to all the local variables that you need to pick the right files.

In my company, I got annoyed by all the people who just copy pasted CMake files (in imperative form) around without understanding what was everything doing, so I made some functions with parameters similar to the example above and everything became a (custom) declarative format. 
It had the benefit of fixing all the copy issues around (that was just annoying boilerplate) and introduce some interesting sanity checks:
 - checking that all the files in the source folder are used (so we don?t miss a header for IDE users for example or leave stray files around)
 - checking that all the include folders exist (this prevents some spelling mistakes)
 - checking that all the include folders are relative and don?t go back in the hierarchy or aren?t absolute (for a cleaner project structure and preventing undeclared dependencies between targets)
 - checking for dependency cycles (and erroring on them), CMake tolerates this, not my coding standards (btw, it?s fun to write graph DFS algorithms in the CMake language)
 - translating ?Framework::Foobar? to the right calls to find the frameworks and link against it without more boilerplate
 - translating ?FOO::FOO? to a find_package() call and using the imported target automatically in some circumstances
All of that was done because CMake has a powerful scripting language, so it?s definitely interesting to have one!

Maybe CMake doesn?t need a real declarative mode, it just needs a small set of user friendly functions that does the same thing as the low level ones and can be easily edited by IDEs?

/Florent

> On 16 Jan 2017, at 21:02, Shmuel H, <shmuelhcmake at gmail.com> wrote:
> 
> > My point is that an IDE should be able to edit the declarative spec
> > without having run a configuration or even create a build tree.  The
> > spec should be the preferred form for making changes and stored in
> > version control.  Any intermediate spec generated by a procedural
> > Language script cannot serve this role.
> 
> I understand that. Maybe we should let the user decide whether to use the advantages the declarative spec or to use a script to generate it. That way, we would not lose the scripting future, which is a big future of CMake. On the other side, we would not force users to use that and even we would make it a lot easier for IDEs to manage these projects.
> -- 
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170116/96d9b3a3/attachment.html>

From s.pankevich at gmail.com  Mon Jan 16 15:49:53 2017
From: s.pankevich at gmail.com (Stanislav Pankevich)
Date: Mon, 16 Jan 2017 21:49:53 +0100
Subject: [cmake-developers] Question / Feature request: LLVM bitcode target
Message-ID: <CAFXpGYbdWO=ugMUpr-OEgGQy89LxV-LbbnRfYxqyYa1Gy3xR2w@mail.gmail.com>

Hello,

This goes somewhere between a question and a feature request.

We are working on mull, https://github.com/mull-project/mull mutation
testing
system based on top of LLVM. Currently the development is mostly focused
around
testing of C++ projects and we use LLVM and its libraries as a playground.

To run Mull against a library like LLVMCore or
LLVMSupport, we need to compile the library, its tests and all of
its dependencies to LLVM bitcode.

Currently the best thing we can do to achieve this so far is to get a
compilation database for a target and all of its dependencies using ninja
and
do some bash magic to patch the `clang ...` commands to
produce a suite of *.bc files which Mull can then consume.

We think that it would be great if CMake had a capability of generating
LLVM bitcode targets out of existing targets with a support of incremental
compilation so that one could iterate on development of a library
and this kind of bitcode target would produce a set of *.bc files in a same
way like
add_library produces libraries.

I have tried to clone the targets by hand using this script as a starting
point:
https://github.com/shadow/shadow/blob/master/cmake/LLVMTools.cmake#L40 but
found
that it was hard to create a clone of existing target to 100% match all of
the
compilation options of a source target. I could make it work for some of the
LLVM targets but overall this approach seems to not be a solid one.

So the following are questions that taken together might constitute a
feature request:

- Can it be possible to recursively clone existing library target created
with
add_library and all of its dependencies?
- Modify this cloned target to produce a set of *.bc files instead of a
binary.
- Have this routine wrapped into a stable and portable CMake function like:
add_llvm_bitcode_target?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170116/b74de653/attachment-0001.html>

From brad.king at kitware.com  Mon Jan 16 15:59:59 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 16 Jan 2017 15:59:59 -0500
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <DE0ABF6B-9964-4771-97D5-BD72913B12CF@gmail.com>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
 <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
 <e92d1169-1eec-0ccb-e19d-41e2ae66b4fe@kitware.com>
 <CAHQPbX9JPvN8SQzZbUFLGWFE-fkLw6JPaCzV5-DF=cFN9+eNGQ@mail.gmail.com>
 <DE0ABF6B-9964-4771-97D5-BD72913B12CF@gmail.com>
Message-ID: <49cc625b-35b7-4eb3-ffb6-fee8609138ee@kitware.com>

On 01/16/2017 03:40 PM, Florent Castelli wrote:
> Well, CMake scripts can be written in a somewhat declarative form now.
[snip]
> I made some functions with parameters similar to the example above and
> everything became a (custom) declarative format. 

Yes, many projects have macros/functions to achieve exactly that.
This shows that a preferred form for editing the spec, even for
humans, is a declarative format.  In the above cases that format is
stored inside `CMakeLists.txt` files or loaded by them.  This is
consistent with my proposal for a generalized declarative spec
that is loaded by the procedural language for evaluation.

-Brad


From steveire at gmail.com  Mon Jan 16 17:12:55 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 16 Jan 2017 22:12:55 +0000
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
 <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
 <e92d1169-1eec-0ccb-e19d-41e2ae66b4fe@kitware.com>
 <CAHQPbX9JPvN8SQzZbUFLGWFE-fkLw6JPaCzV5-DF=cFN9+eNGQ@mail.gmail.com>
 <DE0ABF6B-9964-4771-97D5-BD72913B12CF@gmail.com>
Message-ID: <o5jgh2$hu3$1@blaine.gmane.org>

Florent Castelli wrote:

> Well, CMake scripts can be written in a somewhat declarative form now.
> What prevents this now is that a lot of people use indirections
> everywhere. For example: add_library(foo STATIC ${SRCS}) If it was a plain
> list, any decent IDE would be able to parse this and add another file to
> the list easily. If some commands allowed more expressive alternative
> forms, it would definitely improve the situation:
> 
> add_library(foo STATIC
>   bar1.c
>   bar2.c
>   WINDOWS
>   windows-specific.c
>   APPLE
>   apple-specific.m
> )

It's up to users to use generator expressions instead of if(WIN32) or 
whatever:

 add_library(foo
   foo.cpp
   $<$<PLATFORM_ID:Windows>:foo_win.cpp>
 )

This has been possible for years and was designed with IDEs in mind:

 http://public.kitware.com/pipermail/cmake-developers/2014-September/023042.html

> I find that most of the conditionals are just to create the list of
> sources per platform and then the list of dependencies. It?s certainly
> possible to use generator expressions for some cases, but they don?t have
> the prettiest syntax around, and maybe also not access to all the local
> variables that you need to pick the right files.

You should be able to put any configure-time variable through the generator 
expressions $<BOOL> or $<STREQUAL> to make them genex-compatible.

Thanks,

Steve.



From florent.castelli at gmail.com  Mon Jan 16 17:37:43 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Mon, 16 Jan 2017 23:37:43 +0100
Subject: [cmake-developers] [Discussion] Add python support for
	CMakeLists
In-Reply-To: <o5jgh2$hu3$1@blaine.gmane.org>
References: <CAHQPbX895bymMkha88uoGikggFNZ0vXQy4Ckv-nFYVbfTErEAw@mail.gmail.com>
 <63bfdc89-b2dd-94e3-2144-bd7b87bfe71c@kitware.com>
 <CAHQPbX8k5WQhcEUufHa2KFOgLs1Zprkh_17G=w1Fxb9L_2Rb3Q@mail.gmail.com>
 <64755390-86ab-78da-5a9b-2d3636f6aaef@kitware.com>
 <CAHQPbX-rPyuzDZUxAOjympHGZtym0tVneh7a_760TeaBPF0uwg@mail.gmail.com>
 <e0738eb1-dab9-0ea1-b33a-f83bb05200ef@kitware.com>
 <CAHQPbX-ywDhmK9tU640rtyZ=mTyUsh9W6uhBKmnxp1xSxQyngg@mail.gmail.com>
 <e92d1169-1eec-0ccb-e19d-41e2ae66b4fe@kitware.com>
 <CAHQPbX9JPvN8SQzZbUFLGWFE-fkLw6JPaCzV5-DF=cFN9+eNGQ@mail.gmail.com>
 <DE0ABF6B-9964-4771-97D5-BD72913B12CF@gmail.com>
 <o5jgh2$hu3$1@blaine.gmane.org>
Message-ID: <8563366F-62DF-4598-AD42-93220D32017A@gmail.com>


> 
> It's up to users to use generator expressions instead of if(WIN32) or 
> whatever:
> 
> add_library(foo
>   foo.cpp
>   $<$<PLATFORM_ID:Windows>:foo_win.cpp>
> )
> 
> This has been possible for years and was designed with IDEs in mind:

Sure, it?s possible, but it?s not very user friendly or declarative (you need to parse and interpret the generator expression).

> 
> http://public.kitware.com/pipermail/cmake-developers/2014-September/023042.html
> 
>> I find that most of the conditionals are just to create the list of
>> sources per platform and then the list of dependencies. It?s certainly
>> possible to use generator expressions for some cases, but they don?t have
>> the prettiest syntax around, and maybe also not access to all the local
>> variables that you need to pick the right files.
> 
> You should be able to put any configure-time variable through the generator 
> expressions $<BOOL> or $<STREQUAL> to make them genex-compatible.

Same, it?s not user friendly or a great syntax.
I?ve rarely seen any advanced usage in projects in the wild, I think for that very reason.

One thing that I dislike in genex is that there is no ?else? clause.
So you have to duplicate the whole condition and add a $<NOT> around it.
Having something close to a ternary operator would be nice.

/Florent

From chris.bieneman at me.com  Tue Jan 17 17:25:40 2017
From: chris.bieneman at me.com (Chris Bieneman)
Date: Tue, 17 Jan 2017 14:25:40 -0800
Subject: [cmake-developers] Requesting Advice: Installing object files
Message-ID: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>

Hello CMake-developers!

In one of the LLVM sub-projects we have a problem where we need to install object files, which doesn't seem like a particularly easy task. I'm curious if anyone has any advice on how to approach this problem.

The patch is currently being reviewed here:
https://reviews.llvm.org/D28791 <https://reviews.llvm.org/D28791>

Since the object files have fairly simple compile commands our current approach is to compile the files in custom commands, then use install(FILES...). This is workable, but I'm wondering if there is a better way. They do need to be object files, static archives would not work because these specially named files are handled by linkers and other tools that we don't control.

Thank you!
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170117/ec3ed992/attachment.html>

From nilsgladitz at gmail.com  Wed Jan 18 04:14:26 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Wed, 18 Jan 2017 10:14:26 +0100
Subject: [cmake-developers] Requesting Advice: Installing object files
In-Reply-To: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>
References: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>
Message-ID: <bb95abc9-ee5c-805d-37de-78efde2b3985@gmail.com>

On 17.01.2017 23:25, Chris Bieneman wrote:
> Hello CMake-developers!
>
> In one of the LLVM sub-projects we have a problem where we need to 
> install object files, which doesn't seem like a particularly easy 
> task. I'm curious if anyone has any advice on how to approach this 
> problem.
>
> The patch is currently being reviewed here:
> https://reviews.llvm.org/D28791
>
> Since the object files have fairly simple compile commands our current 
> approach is to compile the files in custom commands, then use 
> install(FILES...). This is workable, but I'm wondering if there is a 
> better way. They do need to be object files, static archives would not 
> work because these specially named files are handled by linkers and 
> other tools that we don't control.

Also more of a workaround but perhaps you could create static libraries 
but extract them with e.g. CMAKE_AR (toolchain specific) during either 
installation e.g. install(CODE|SCRIPT) or as a POST_BUILD custom command.

An OBJECT library might be better suited in theory but I don't think it 
currently allows installation and the location of the object files is 
generator specific (and afair not always known to cmake).
By doing a manual extraction of the archive you'd be in control over 
where the objects go.

Nils

From ben.boeckel at kitware.com  Wed Jan 18 08:58:00 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 18 Jan 2017 08:58:00 -0500
Subject: [cmake-developers] Requesting Advice: Installing object files
In-Reply-To: <bb95abc9-ee5c-805d-37de-78efde2b3985@gmail.com>
References: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>
 <bb95abc9-ee5c-805d-37de-78efde2b3985@gmail.com>
Message-ID: <20170118135800.GA6386@megas.kitware.com>

On Wed, Jan 18, 2017 at 10:14:26 +0100, Nils Gladitz wrote:
> On 17.01.2017 23:25, Chris Bieneman wrote:
> > Hello CMake-developers!
> >
> > In one of the LLVM sub-projects we have a problem where we need to 
> > install object files, which doesn't seem like a particularly easy 
> > task. I'm curious if anyone has any advice on how to approach this 
> > problem.
> >
> > The patch is currently being reviewed here:
> > https://reviews.llvm.org/D28791
> >
> > Since the object files have fairly simple compile commands our current 
> > approach is to compile the files in custom commands, then use 
> > install(FILES...). This is workable, but I'm wondering if there is a 
> > better way. They do need to be object files, static archives would not 
> > work because these specially named files are handled by linkers and 
> > other tools that we don't control.
> 
> Also more of a workaround but perhaps you could create static libraries 
> but extract them with e.g. CMAKE_AR (toolchain specific) during either 
> installation e.g. install(CODE|SCRIPT) or as a POST_BUILD custom command.

This issue might be the best way to go:

    https://gitlab.kitware.com/cmake/cmake/issues/15226

> An OBJECT library might be better suited in theory but I don't think it 
> currently allows installation and the location of the object files is 
> generator specific (and afair not always known to cmake).
> By doing a manual extraction of the archive you'd be in control over 
> where the objects go.

Plus our plan for installing OBJECT libraries was to install them as
INTERFACE libraries, leaving the objects themselves behind. The idea is
to allow object libraries into target_link_libraries() for usage
requirements and to support exporting them as part of the build system
(an explicit $<TARGET_OBJECTS> would still be required to use their
objects due to issues with transitive linking causing duplicate symbols
if target_sources were used).

--Ben

From mhanna21 at bloomberg.net  Wed Jan 18 10:12:53 2017
From: mhanna21 at bloomberg.net (Matthew Hanna (BLOOMBERG/ 731 LEX))
Date: Wed, 18 Jan 2017 15:12:53 -0000
Subject: [cmake-developers] =?utf-8?q?pkg=5Fcheck=5Fmodules_does_not_respo?=
	=?utf-8?q?nd_to_changes=2E?=
Message-ID: <587F85F5021F070A003904C4_0_57441@msllnjpmsgsv06>

There is an optimization in pkg_check_modules that skips processing
once a successful execution has occurred and simply leaves the cached
return variables as is.  As currently implemented, any changes to the
parameters of pkg_check_modules, excluding PREFIX, will be ignored
following a successful execution.  Workarounds include modifying the
PREFIX and all references to it, or starting over from an empty build
directory.  Adding a pkg-config dependency after the initial
configuration is a regular part of our development workflow and the
existing workarounds are cumbersome.

I would like to enhance the behavior of pkg_check_modules to store the
parameters for a given PREFIX so that changes to those parameters can
disable the optimization and re-evaluate pkg_check_modules.

Are there any concerns about or objections to adding this behavior?

If not, should this change in behavior be noted in the documentation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170118/30707ab1/attachment.html>

From rcdailey.lists at gmail.com  Wed Jan 18 10:52:58 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Wed, 18 Jan 2017 09:52:58 -0600
Subject: [cmake-developers] Multi-line strings with indentation ignored
Message-ID: <CAHd499AHHYVLkMWBuE=goJ=y-jaNWxxLiCn6b-20ixMZquRbNQ@mail.gmail.com>

At the moment, with CMake 3.0 and on, I can use this syntax for
multi-line strings:


option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\
Enable additional diagnostic logs for zPay related code. \
Should not be enabled for production due to the sensitivity \
and volume of logs that will be printed." )

The problem with this approach is that it's ugly; I can't indent the
code because the indentations are made to be a literal part of the
string itself. I prefer the C++ approach to multi-line strings because
it allows strings to be hard-wrapped AND indent them for style, all
without affecting the actual string data:

option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS
    "Enable additional diagnostic logs for zPay related code. "
    "Should not be enabled for production due to the sensitivity "
    "and volume of logs that will be printed" )

This is much nicer, but CMake fails this code because it sees each
string as a separate parameter. Is there a mechanism I can use to
style my strings this way? If not, are there any plans to add better
multi-line string support?

From konstantin at podsvirov.pro  Wed Jan 18 14:20:14 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Wed, 18 Jan 2017 22:20:14 +0300
Subject: [cmake-developers] [Discussion] Down with discrimination CPack!
Message-ID: <422801484767214@web29m.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170118/92f103df/attachment.html>

From chris.bieneman at me.com  Wed Jan 18 14:47:42 2017
From: chris.bieneman at me.com (Chris Bieneman)
Date: Wed, 18 Jan 2017 11:47:42 -0800
Subject: [cmake-developers] Requesting Advice: Installing object files
In-Reply-To: <20170118135800.GA6386@megas.kitware.com>
References: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>
 <bb95abc9-ee5c-805d-37de-78efde2b3985@gmail.com>
 <20170118135800.GA6386@megas.kitware.com>
Message-ID: <C82B494F-3584-414E-BFDC-FC7CEA9D4E96@me.com>


> On Jan 18, 2017, at 5:58 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> 
> On Wed, Jan 18, 2017 at 10:14:26 +0100, Nils Gladitz wrote:
>> On 17.01.2017 23:25, Chris Bieneman wrote:
>>> Hello CMake-developers!
>>> 
>>> In one of the LLVM sub-projects we have a problem where we need to 
>>> install object files, which doesn't seem like a particularly easy 
>>> task. I'm curious if anyone has any advice on how to approach this 
>>> problem.
>>> 
>>> The patch is currently being reviewed here:
>>> https://reviews.llvm.org/D28791
>>> 
>>> Since the object files have fairly simple compile commands our current 
>>> approach is to compile the files in custom commands, then use 
>>> install(FILES...). This is workable, but I'm wondering if there is a 
>>> better way. They do need to be object files, static archives would not 
>>> work because these specially named files are handled by linkers and 
>>> other tools that we don't control.
>> 
>> Also more of a workaround but perhaps you could create static libraries 
>> but extract them with e.g. CMAKE_AR (toolchain specific) during either 
>> installation e.g. install(CODE|SCRIPT) or as a POST_BUILD custom command.

We could consider this, but I'm not sure that this is really any simpler than what we're doing.

> 
> This issue might be the best way to go:
> 
>    https://gitlab.kitware.com/cmake/cmake/issues/15226 <https://gitlab.kitware.com/cmake/cmake/issues/15226>

If this allowed TARGET_OBJECTS to be used in the install(FILES ...) command, then we could create an object library and a custom install rule for the objects, which would be a lot cleaner.

> 
>> An OBJECT library might be better suited in theory but I don't think it 
>> currently allows installation and the location of the object files is 
>> generator specific (and afair not always known to cmake).
>> By doing a manual extraction of the archive you'd be in control over 
>> where the objects go.
> 
> Plus our plan for installing OBJECT libraries was to install them as
> INTERFACE libraries, leaving the objects themselves behind. The idea is
> to allow object libraries into target_link_libraries() for usage
> requirements and to support exporting them as part of the build system
> (an explicit $<TARGET_OBJECTS> would still be required to use their
> objects due to issues with transitive linking causing duplicate symbols
> if target_sources were used).

Ah... that wouldn't work for us because we actually need the objects to be installed in the final product.

Thanks!
-Chris

> 
> --Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170118/6d29744a/attachment.html>

From ben.boeckel at kitware.com  Wed Jan 18 15:14:07 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 18 Jan 2017 15:14:07 -0500
Subject: [cmake-developers] Requesting Advice: Installing object files
In-Reply-To: <C82B494F-3584-414E-BFDC-FC7CEA9D4E96@me.com>
References: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>
 <bb95abc9-ee5c-805d-37de-78efde2b3985@gmail.com>
 <20170118135800.GA6386@megas.kitware.com>
 <C82B494F-3584-414E-BFDC-FC7CEA9D4E96@me.com>
Message-ID: <20170118201407.GA21551@megas.kitware.com>

On Wed, Jan 18, 2017 at 11:47:42 -0800, Chris Bieneman wrote:
> On Jan 18, 2017, at 5:58 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> > Plus our plan for installing OBJECT libraries was to install them as
> > INTERFACE libraries, leaving the objects themselves behind. The idea is
> > to allow object libraries into target_link_libraries() for usage
> > requirements and to support exporting them as part of the build system
> > (an explicit $<TARGET_OBJECTS> would still be required to use their
> > objects due to issues with transitive linking causing duplicate symbols
> > if target_sources were used).
> 
> Ah... that wouldn't work for us because we actually need the objects
> to be installed in the final product.

So I talked with Rob about this a bit and the INTERFACE bit is actually
the *exporting* of the target. Installing the target can install the
objects. I think the way this could work is that if it is installed, the
objects go and if they are exported, they are exported as an INTERFACE
library which supports a $<TARGET_OBJECTS> genex (and if the target is
not installed, it wouldn't work).

There will need to be some thought on it since there isn't a "just
export the target" mechanism yet. Off the top of my head, I'd like to
see install() have a INSTALL_OBJECTS keyword to cause OBJECT libraries
to put their objects anywhere (since I suspect it will be an uncommon
use case versus the need for a way to export the targets to an install
tree).

--Ben

From neundorf at kde.org  Wed Jan 18 16:07:50 2017
From: neundorf at kde.org (Alexander Neundorf)
Date: Wed, 18 Jan 2017 22:07:50 +0100
Subject: [cmake-developers] [Discussion] Down with discrimination CPack!
In-Reply-To: <422801484767214@web29m.yandex.ru>
References: <422801484767214@web29m.yandex.ru>
Message-ID: <4844054.IMnhrRRUBi@linux-l7nd>

On 2017 M01 18, Wed 22:20:14 CET Konstantin Podsvirov wrote:
> What about add to CMake language new packaging problematic scopes:
> 
> - COMPONENT;
> - COMPONENT_GROUP;
> - PACKAGE;
> - INSTALLER;
> - REPOSITORY?

that's a quite terse proposal...

Alex



From brad.king at kitware.com  Fri Jan 20 09:12:10 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 20 Jan 2017 09:12:10 -0500
Subject: [cmake-developers] Multi-line strings with indentation ignored
In-Reply-To: <CAHd499AHHYVLkMWBuE=goJ=y-jaNWxxLiCn6b-20ixMZquRbNQ@mail.gmail.com>
References: <CAHd499AHHYVLkMWBuE=goJ=y-jaNWxxLiCn6b-20ixMZquRbNQ@mail.gmail.com>
Message-ID: <bfdf5dfe-e942-725c-9f44-a5292eee5c79@kitware.com>

On 01/18/2017 10:52 AM, Robert Dailey wrote:
> At the moment, with CMake 3.0 and on, I can use this syntax for
> multi-line strings:
> 
> option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\
> Enable additional diagnostic logs for zPay related code. \
> Should not be enabled for production due to the sensitivity \
> and volume of logs that will be printed." )

One can also use bracket arguments:

https://cmake.org/cmake/help/v3.7/manual/cmake-language.7.html#bracket-argument

but they (intentionally) don't process any variable references.
Also they don't ignore indentation.

>     "Enable additional diagnostic logs for zPay related code. "
>     "Should not be enabled for production due to the sensitivity "
>     "and volume of logs that will be printed" )
> 
> it sees each string as a separate parameter.

Correct.

> Is there a mechanism I can use to style my strings this way?

One can do it with an intermediate variable:

```
string(CONCAT mystringvar
  "Enable additional diagnostic logs for zPay related code. "
  "Should not be enabled for production due to the sensitivity "
  "and volume of logs that will be printed"
  )
option(ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "${mystringvar}")
```

> are there any plans to add better multi-line string support?

Not currently.

-Brad


From brad.king at kitware.com  Fri Jan 20 09:12:19 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 20 Jan 2017 09:12:19 -0500
Subject: [cmake-developers] pkg_check_modules does not respond to
	changes.
In-Reply-To: <587F85F5021F070A003904C4_0_57441@msllnjpmsgsv06>
References: <587F85F5021F070A003904C4_0_57441@msllnjpmsgsv06>
Message-ID: <463762e2-7b05-3ddb-c192-00b760e4355a@kitware.com>

On 01/18/2017 10:12 AM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> I would like to enhance the behavior of pkg_check_modules to store the
> parameters for a given PREFIX so that changes to those parameters can
> disable the optimization and re-evaluate pkg_check_modules.
> 
> Are there any concerns about or objections to adding this behavior?

It sounds good in principle.  Please submit a MR with the specifics.

> If not, should this change in behavior be noted in the documentation?

Please include a release note in `Help/release/dev/$topic.rst`.
We can decide during MR review what other documentation may be
needed, if any.

Thanks,
-Brad


From brad.king at kitware.com  Fri Jan 20 09:12:25 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 20 Jan 2017 09:12:25 -0500
Subject: [cmake-developers] Requesting Advice: Installing object files
In-Reply-To: <20170118201407.GA21551@megas.kitware.com>
References: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>
 <bb95abc9-ee5c-805d-37de-78efde2b3985@gmail.com>
 <20170118135800.GA6386@megas.kitware.com>
 <C82B494F-3584-414E-BFDC-FC7CEA9D4E96@me.com>
 <20170118201407.GA21551@megas.kitware.com>
Message-ID: <e164eac0-217c-f9de-b6e6-3954d6cced78@kitware.com>

On 01/18/2017 03:14 PM, Ben Boeckel wrote:
> So I talked with Rob about this a bit and the INTERFACE bit is actually
> the *exporting* of the target. Installing the target can install the
> objects. I think the way this could work is that if it is installed, the
> objects go and if they are exported,

I agree something along these lines is the way to go.  The limitation of
not being able to install object libraries is only there because when
object libraries were first implemented they had a very specific purpose
and we didn't want to have to delay them just to think through all the
semantics of installation.

> they are exported as an INTERFACE library which supports a
> $<TARGET_OBJECTS> genex (and if the target is not installed, it
> wouldn't work).

We should also consider exporting them as something like

  add_library(myobjlib OBJECT IMPORTED)
  set_property(TARGET myobjlib PROPERTY IMPORTED_OBJECTS ...)

There is no reason it has to specifically be an INTERFACE library.
In fact if we don't also work out target_link_libraries semantics
for object libraries then we can't export them as INTERFACE libraries
or tll() with them would have to be defined.

-Brad


From tbperrotta at gmail.com  Fri Jan 20 20:51:15 2017
From: tbperrotta at gmail.com (Thiago Perrotta)
Date: Sat, 21 Jan 2017 01:51:15 +0000
Subject: [cmake-developers] [PATCH] CMAKE_DL_LIBS: fix typo
Message-ID: <CAHVDqtyhPXVXGRzaHx2L22DFGRvXvRSMXrydGkek7XuM-0ShGg@mail.gmail.com>

Hi list,

Since this is a very small fix (literally just one character) and this is
my first patch here, I didn't bother to read the instructions for
contributing / submitting patches. Therefore, feel free to use this patch
according to your own workflow.

- Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170121/d4bcfe98/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CMAKE_DL_LIBS-fix-typo.patch
Type: text/x-patch
Size: 754 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170121/d4bcfe98/attachment.bin>

From ben.boeckel at kitware.com  Mon Jan 23 08:51:36 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 23 Jan 2017 08:51:36 -0500
Subject: [cmake-developers] [PATCH] CMAKE_DL_LIBS: fix typo
In-Reply-To: <CAHVDqtyhPXVXGRzaHx2L22DFGRvXvRSMXrydGkek7XuM-0ShGg@mail.gmail.com>
References: <CAHVDqtyhPXVXGRzaHx2L22DFGRvXvRSMXrydGkek7XuM-0ShGg@mail.gmail.com>
Message-ID: <20170123135136.GA12042@megas.kitware.com>

On Sat, Jan 21, 2017 at 01:51:15 +0000, Thiago Perrotta wrote:
> Since this is a very small fix (literally just one character) and this is
> my first patch here, I didn't bother to read the instructions for
> contributing / submitting patches. Therefore, feel free to use this patch
> according to your own workflow.

Thanks, I've pushed up an MR here:

    https://gitlab.kitware.com/cmake/cmake/merge_requests/422

--Ben

From Sebastian.Boe at nordicsemi.no  Wed Jan 25 09:31:32 2017
From: Sebastian.Boe at nordicsemi.no (=?iso-8859-1?Q?B=F8e=2C_Sebastian?=)
Date: Wed, 25 Jan 2017 14:31:32 +0000
Subject: [cmake-developers] Eclipse CDT Managed build
Message-ID: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>

Hi,

I was wondering if anyone has given thought to if
it is feasible to have generator support for Eclipse CDT
Managed builds?

My motivation for managed build's instead of external Makefile
builds, is that after CMake generation the project can be
configured through the IDE UI. Which is a useful property in an
SDK context.

Sebastian B?e
Nordic Semiconductor ASA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170125/59b38c5a/attachment.html>

From ben.boeckel at kitware.com  Wed Jan 25 09:43:08 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 25 Jan 2017 09:43:08 -0500
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
Message-ID: <20170125144308.GA488@megas.kitware.com>

On Wed, Jan 25, 2017 at 14:31:32 +0000, B?e, Sebastian wrote:
> I was wondering if anyone has given thought to if
> it is feasible to have generator support for Eclipse CDT
> Managed builds?

It would likely be possible, but I don't know of any work towards this
goal.

> My motivation for managed build's instead of external Makefile
> builds, is that after CMake generation the project can be
> configured through the IDE UI. Which is a useful property in an
> SDK context.

This could be a problem though. Are the files that the IDE edits
separate from the ones that CMake generates? If not, how would CMake
know not to clobber the edited parts of the files it does generate?

--Ben

From Sebastian.Boe at nordicsemi.no  Wed Jan 25 09:51:26 2017
From: Sebastian.Boe at nordicsemi.no (=?utf-8?B?QsO4ZSwgU2ViYXN0aWFu?=)
Date: Wed, 25 Jan 2017 14:51:26 +0000
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <20170125144308.GA488@megas.kitware.com>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
Message-ID: <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>

You are right, this is a problem for the usual case of re-running
CMake when the project configuration changes.

But in this use-case CMake would only be run once and then the 
IDE project would take over project configuration for the rest
of the application lifetime.

It also allows the use-case of temporarily doing simple project
configuration through the IDE UI.

-----Original Message-----
From: Ben Boeckel [mailto:ben.boeckel at kitware.com] 
Sent: 25. januar 2017 15:43
To: B?e, Sebastian <Sebastian.Boe at nordicsemi.no>
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build

On Wed, Jan 25, 2017 at 14:31:32 +0000, B?e, Sebastian wrote:
> I was wondering if anyone has given thought to if it is feasible to 
> have generator support for Eclipse CDT Managed builds?

It would likely be possible, but I don't know of any work towards this goal.

> My motivation for managed build's instead of external Makefile builds, 
> is that after CMake generation the project can be configured through 
> the IDE UI. Which is a useful property in an SDK context.

This could be a problem though. Are the files that the IDE edits separate from the ones that CMake generates? If not, how would CMake know not to clobber the edited parts of the files it does generate?

--Ben

From ben.boeckel at kitware.com  Wed Jan 25 10:31:17 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 25 Jan 2017 10:31:17 -0500
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
Message-ID: <20170125153117.GA20925@megas.kitware.com>

On Wed, Jan 25, 2017 at 14:51:26 +0000, B?e, Sebastian wrote:
> But in this use-case CMake would only be run once and then the 
> IDE project would take over project configuration for the rest
> of the application lifetime.

CMake does not generally create relocatable build trees, so you cannot
commit the generated files. That means that unless the CMakeLists.txt
are never going to be changed (including via VCS branch changes), CMake
may rerun on its own and clobber the changes since everyone will need to
run it on their own once.

--Ben

From Sebastian.Boe at nordicsemi.no  Wed Jan 25 10:45:33 2017
From: Sebastian.Boe at nordicsemi.no (=?utf-8?B?QsO4ZSwgU2ViYXN0aWFu?=)
Date: Wed, 25 Jan 2017 15:45:33 +0000
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <20170125153117.GA20925@megas.kitware.com>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
Message-ID: <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>

Not modifying the CMakeListst.txt is acceptable for this use-case.

But not being able to share, or relocate, the build tree is a problem.

Would support for relocatable build trees need major changes throughout
CMake, or is this primarily a property of the generator?

-----Original Message-----
From: Ben Boeckel [mailto:ben.boeckel at kitware.com] 
Sent: 25. januar 2017 16:31
To: B?e, Sebastian <Sebastian.Boe at nordicsemi.no>
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build

On Wed, Jan 25, 2017 at 14:51:26 +0000, B?e, Sebastian wrote:
> But in this use-case CMake would only be run once and then the IDE 
> project would take over project configuration for the rest of the 
> application lifetime.

CMake does not generally create relocatable build trees, so you cannot commit the generated files. That means that unless the CMakeLists.txt are never going to be changed (including via VCS branch changes), CMake may rerun on its own and clobber the changes since everyone will need to run it on their own once.

--Ben

From ben.boeckel at kitware.com  Wed Jan 25 11:27:24 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 25 Jan 2017 11:27:24 -0500
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
Message-ID: <20170125162724.GA4076@megas.kitware.com>

On Wed, Jan 25, 2017 at 15:45:33 +0000, B?e, Sebastian wrote:
> Not modifying the CMakeListst.txt is acceptable for this use-case.
> 
> But not being able to share, or relocate, the build tree is a problem.
> 
> Would support for relocatable build trees need major changes throughout
> CMake, or is this primarily a property of the generator?

It'd need lots of changes. CMake generally uses absolute paths to the
source tree and sometimes to the build tree (I forget the cases where it
does, but that is somewhat generator-dependent). At least one is for the
Makefiles generator where it embed absolute paths in its `cd` commands
before running the compiler. It would likely not be trivial to get CMake
to generate relocatable builds.

--Ben

From brad.king at kitware.com  Wed Jan 25 11:38:06 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 25 Jan 2017 11:38:06 -0500
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <20170125162724.GA4076@megas.kitware.com>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
 <20170125162724.GA4076@megas.kitware.com>
Message-ID: <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>

On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> not be trivial to get CMake to generate relocatable builds.

This is also an explicit non-goal of CMake.

>> after CMake generation the project can be configured through the IDE UI.

That is likely not compatible with CMake's notion of maintaining
the build system.

This is why previous similar discussions resulted in the cmake server
mode and in identifying the value of a declarative spec format that
can be managed outside of CMake's language processor.

-Brad


From neundorf at kde.org  Wed Jan 25 15:24:23 2017
From: neundorf at kde.org (Alexander Neundorf)
Date: Wed, 25 Jan 2017 21:24:23 +0100
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125162724.GA4076@megas.kitware.com>
 <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
Message-ID: <4168374.lqA2x7x1ec@linux-l7nd>

On 2017 M01 25, Wed 11:38:06 CET Brad King wrote:
> On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> > not be trivial to get CMake to generate relocatable builds.
> 
> This is also an explicit non-goal of CMake.
> 
> >> after CMake generation the project can be configured through the IDE UI.
> 
> That is likely not compatible with CMake's notion of maintaining
> the build system.
> 
> This is why previous similar discussions resulted in the cmake server
> mode and in identifying the value of a declarative spec format that
> can be managed outside of CMake's language processor.

IOW, now that cmake has server-mode, the recommended approach is to implement 
a plugin for cmake-server mode in Eclipse.

Alex


From tobias.hunger at gmail.com  Thu Jan 26 04:45:49 2017
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Thu, 26 Jan 2017 10:45:49 +0100
Subject: [cmake-developers] CMake server-mode aborting
Message-ID: <CAMdWP3FRnQZcob1YQGsAJf=LftSEoYfjDNG6oEGOSsW1oRaStA@mail.gmail.com>

Hello CMake developers,

I have been using Qt Creator extensively with cmake server-mode for a
while now and am very happy with the results so far. Once the project
is initially configured by cmake it is really nice.

Today I started to look into a bug report that creator behaves
horribly when not all the dependencies of a project are available. In
that case the UI behaves entirely wrong (I just pushed a patch to
improve that on the Creator side into code review).

The root cause seems to be that during configure run CMake just
vanishes. Creator reports back that it crashed. I can unfortunately
not reproduce that problem with any of the CMakeLists.txt files I have
handy, so I am a bit lost at what to do.

Does any of you cmake experts have an idea what might go wrong? I
thought that maybe a MESSAGE(FATAL_ERROR ...) is triggered, causing
cmake server to terminate or something similar. Unfortunately that
does not seem to trigger the server to die for me:-/

Best Regards,
Tobias

From nilsgladitz at gmail.com  Thu Jan 26 05:08:31 2017
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Thu, 26 Jan 2017 11:08:31 +0100
Subject: [cmake-developers] CMake server-mode aborting
In-Reply-To: <CAMdWP3FRnQZcob1YQGsAJf=LftSEoYfjDNG6oEGOSsW1oRaStA@mail.gmail.com>
References: <CAMdWP3FRnQZcob1YQGsAJf=LftSEoYfjDNG6oEGOSsW1oRaStA@mail.gmail.com>
Message-ID: <27f55c33-7077-a701-68d1-b1454346e384@gmail.com>

On 01/26/2017 10:45 AM, Tobias Hunger wrote:

> Hello CMake developers,
>
> I have been using Qt Creator extensively with cmake server-mode for a
> while now and am very happy with the results so far. Once the project
> is initially configured by cmake it is really nice.
>
> Today I started to look into a bug report that creator behaves
> horribly when not all the dependencies of a project are available. In
> that case the UI behaves entirely wrong (I just pushed a patch to
> improve that on the Creator side into code review).
>
> The root cause seems to be that during configure run CMake just
> vanishes. Creator reports back that it crashed. I can unfortunately
> not reproduce that problem with any of the CMakeLists.txt files I have
> handy, so I am a bit lost at what to do.
>
> Does any of you cmake experts have an idea what might go wrong? I
> thought that maybe a MESSAGE(FATAL_ERROR ...) is triggered, causing
> cmake server to terminate or something similar. Unfortunately that
> does not seem to trigger the server to die for me:-/

I haven't really looked into server mode yet but for something that 
should crash cmake (server or otherwise):

     function(foo)
         foo()
     endfunction()

     foo()

Nils

From Sebastian.Boe at nordicsemi.no  Thu Jan 26 05:57:36 2017
From: Sebastian.Boe at nordicsemi.no (=?utf-8?B?QsO4ZSwgU2ViYXN0aWFu?=)
Date: Thu, 26 Jan 2017 10:57:36 +0000
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
 <20170125162724.GA4076@megas.kitware.com>
 <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
Message-ID: <8550C054D4A125499A4147653C70D48F01008D78C6@MBX05.nvlsi.no>

I was not aware that this was a non-goal. Thank you
for feedback.

I am sorry if my use-case sounds foreign, but I can't use cmake server mode,
because I can't modify the IDE.

I will investigate relocatable builds, because in spite of this not being
trivial, I think CMake still comes out as the best suited technology for my use-case.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: 25. januar 2017 17:38
To: B?e, Sebastian <Sebastian.Boe at nordicsemi.no>
Cc: ben.boeckel at kitware.com; cmake-developers at cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build

On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> not be trivial to get CMake to generate relocatable builds.

This is also an explicit non-goal of CMake.

>> after CMake generation the project can be configured through the IDE UI.

That is likely not compatible with CMake's notion of maintaining the build system.

This is why previous similar discussions resulted in the cmake server mode and in identifying the value of a declarative spec format that can be managed outside of CMake's language processor.

-Brad


From brad.king at kitware.com  Thu Jan 26 08:18:12 2017
From: brad.king at kitware.com (Brad King)
Date: Thu, 26 Jan 2017 08:18:12 -0500
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <8550C054D4A125499A4147653C70D48F01008D78C6@MBX05.nvlsi.no>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
 <20170125162724.GA4076@megas.kitware.com>
 <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D78C6@MBX05.nvlsi.no>
Message-ID: <2ae7c0c3-6526-1225-35e4-c2edf511ca4f@kitware.com>

On 01/26/2017 05:57 AM, B?e, Sebastian wrote:
> I will investigate relocatable builds, because in spite of this not being
> trivial, I think CMake still comes out as the best suited technology for my use-case.

We once had an option to produce relative paths in the build system
and it was a never ending mess of bugs.  Eventually it was ripped out.
It is unlikely we will accept changes to try to re-introduce such
an option.

-Brad


From Sebastian.Boe at nordicsemi.no  Thu Jan 26 09:01:40 2017
From: Sebastian.Boe at nordicsemi.no (=?utf-8?B?QsO4ZSwgU2ViYXN0aWFu?=)
Date: Thu, 26 Jan 2017 14:01:40 +0000
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <2ae7c0c3-6526-1225-35e4-c2edf511ca4f@kitware.com>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
 <20170125162724.GA4076@megas.kitware.com>
 <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D78C6@MBX05.nvlsi.no>
 <2ae7c0c3-6526-1225-35e4-c2edf511ca4f@kitware.com>
Message-ID: <8550C054D4A125499A4147653C70D48F01008D796A@MBX05.nvlsi.no>

Thank you for the warning and support. We would prefer to not maintain
a fork, but I have not been able to find any other technology
that is suitable.

For future reference. The intended use-case is for CMake to act 
as an engine in an IDE project generator solution similar to the below
solutions[0].

[0] 
http://start.atmel.com/
http://www.st.com/en/embedded-software/stm32cube-embedded-software.html



-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: 26. januar 2017 14:18
To: B?e, Sebastian <Sebastian.Boe at nordicsemi.no>
Cc: ben.boeckel at kitware.com; cmake-developers at cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build

On 01/26/2017 05:57 AM, B?e, Sebastian wrote:
> I will investigate relocatable builds, because in spite of this not 
> being trivial, I think CMake still comes out as the best suited technology for my use-case.

We once had an option to produce relative paths in the build system and it was a never ending mess of bugs.  Eventually it was ripped out.
It is unlikely we will accept changes to try to re-introduce such an option.

-Brad


From paul at mad-scientist.net  Thu Jan 26 11:41:21 2017
From: paul at mad-scientist.net (Paul Smith)
Date: Thu, 26 Jan 2017 11:41:21 -0500
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <8550C054D4A125499A4147653C70D48F01008D796A@MBX05.nvlsi.no>
References: <8550C054D4A125499A4147653C70D48F01008D7777@MBX05.nvlsi.no>
 <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
 <20170125162724.GA4076@megas.kitware.com>
 <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D78C6@MBX05.nvlsi.no>
 <2ae7c0c3-6526-1225-35e4-c2edf511ca4f@kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D796A@MBX05.nvlsi.no>
Message-ID: <1485448881.5642.79.camel@mad-scientist.net>

IMO the right place for managing relocatable builds is in the
compiler/linker, not in the build tool.

The compiler/linker should provide options that allow the output to be
relocatable regardless of the contents of the command line. ?GCC for
example has -fdebug-prefix-map that will allow you to remove prefixes
from pathnames in debug sections of the output. ?Unfortunately this is
only part of the solution since it doesn't help with __FILE__ (for
example). ?Nevertheless this is the right direction, rather than
modifying the build system.


On Thu, 2017-01-26 at 14:01 +0000, B?e, Sebastian wrote:
> Thank you for the warning and support. We would prefer to not
> maintain
> a fork, but I have not been able to find any other technology
> that is suitable.
> 
> For future reference. The intended use-case is for CMake to act?
> as an engine in an IDE project generator solution similar to the
> below
> solutions[0].
> 
> [0]?
> http://start.atmel.com/
> http://www.st.com/en/embedded-software/stm32cube-embedded-software.ht
> ml
> 
> 
> 
> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com]?
> Sent: 26. januar 2017 14:18
> To: B?e, Sebastian <Sebastian.Boe at nordicsemi.no>
> Cc: ben.boeckel at kitware.com; cmake-developers at cmake.org
> Subject: Re: [cmake-developers] Eclipse CDT Managed build
> 
> On 01/26/2017 05:57 AM, B?e, Sebastian wrote:
> > 
> > I will investigate relocatable builds, because in spite of this
> > not?
> > being trivial, I think CMake still comes out as the best suited
> > technology for my use-case.
> 
> We once had an option to produce relative paths in the build system
> and it was a never ending mess of bugs.??Eventually it was ripped
> out.
> It is unlikely we will accept changes to try to re-introduce such an
> option.
> 
> -Brad
> 

From ben.boeckel at kitware.com  Thu Jan 26 12:40:45 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 26 Jan 2017 12:40:45 -0500
Subject: [cmake-developers] Eclipse CDT Managed build
In-Reply-To: <1485448881.5642.79.camel@mad-scientist.net>
References: <20170125144308.GA488@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77A1@MBX05.nvlsi.no>
 <20170125153117.GA20925@megas.kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D77CB@MBX05.nvlsi.no>
 <20170125162724.GA4076@megas.kitware.com>
 <b2e01734-3632-4b6b-1266-2cbaaa3db828@kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D78C6@MBX05.nvlsi.no>
 <2ae7c0c3-6526-1225-35e4-c2edf511ca4f@kitware.com>
 <8550C054D4A125499A4147653C70D48F01008D796A@MBX05.nvlsi.no>
 <1485448881.5642.79.camel@mad-scientist.net>
Message-ID: <20170126174045.GA31104@megas.kitware.com>

On Thu, Jan 26, 2017 at 11:41:21 -0500, Paul Smith wrote:
> IMO the right place for managing relocatable builds is in the
> compiler/linker, not in the build tool.

This is about making the files CMake writes relocatable, not the
resulting binaries.

--Ben

From nicolasbertolo at gmail.com  Thu Jan 26 15:56:50 2017
From: nicolasbertolo at gmail.com (=?UTF-8?B?Tmljb2zDoXMgQsOpcnRvbG8=?=)
Date: Thu, 26 Jan 2017 17:56:50 -0300
Subject: [cmake-developers] What should the behaviour of
	NUMBER_OF_LOGICAL_CORES be?
Message-ID: <4850baa9-e2e1-f1a7-d66e-61157bf48262@gmail.com>

Hi,

This question comes from https://gitlab.kitware.com/cmake/cmake/issues/16594
Currently cmake_host_system_information(RESULT logical QUERY 
NUMBER_OF_LOGICAL_CORES) is buggy, some parts of the code that implement 
it assume it refers to the number of cores in the system and some assume 
it is the number of cores per physical core. The documentation implies 
it is the total number of cores, but in my system (AMD FX-8320) it is 
equal to 1 when it should be 8.

I have offered myself to fix this bug, but first I would like to know 
what is the correct return value of this call should be.
Should it return the number of cores per physical core or the total 
number of cores in the system?

I think it should be the latter, but I would like to hear your opinions.

Regards,
Nicol?s.

||



---
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170126/dd077652/attachment.html>

From daniel at pfeifer-mail.de  Thu Jan 26 16:10:38 2017
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Thu, 26 Jan 2017 22:10:38 +0100
Subject: [cmake-developers] What should the behaviour of
 NUMBER_OF_LOGICAL_CORES be?
In-Reply-To: <4850baa9-e2e1-f1a7-d66e-61157bf48262@gmail.com>
References: <4850baa9-e2e1-f1a7-d66e-61157bf48262@gmail.com>
Message-ID: <CANZMcXoDsoNOtrY2XtRFDFHx0eUjezqUz_DtEMyr0RD_ggHgMw@mail.gmail.com>

Hi,

I agree that it should be total number of cores. In addition,
cmake_host_system_information() might be extended to provide the number of
cores per physical core.
This aligns with the information in the XML procuded by CTest: The Site
element has the attributes NumberOfLogicalCPU, NumberOfPhysicalCPU, and
LogicalProcessorsPerPhysical.

Cheers, Daniel

On Thu, Jan 26, 2017 at 9:56 PM, Nicol?s B?rtolo <nicolasbertolo at gmail.com>
wrote:

> Hi,
>
> This question comes from https://gitlab.kitware.com/
> cmake/cmake/issues/16594
> Currently cmake_host_system_information(RESULT logical QUERY
> NUMBER_OF_LOGICAL_CORES) is buggy, some parts of the code that implement it
> assume it refers to the number of cores in the system and some assume it is
> the number of cores per physical core. The documentation implies it is the
> total number of cores, but in my system (AMD FX-8320) it is equal to 1 when
> it should be 8.
>
> I have offered myself to fix this bug, but first I would like to know what
> is the correct return value of this call should be.
> Should it return the number of cores per physical core or the total number
> of cores in the system?
>
> I think it should be the latter, but I would like to hear your opinions.
>
> Regards,
> Nicol?s.
>
>
>
> ------------------------------
> [image: Avast logo]
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> El software de antivirus Avast ha analizado este correo electr?nico en
> busca de virus.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170126/b0f636d4/attachment.html>

From eike at sf-mail.de  Sun Jan 29 06:56:10 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Sun, 29 Jan 2017 12:56:10 +0100
Subject: [cmake-developers] Recording compiler features for older gcc
	versions
In-Reply-To: <28540444.kHl9saaQ7y@devpool21>
References: <28540444.kHl9saaQ7y@devpool21>
Message-ID: <32300823.Disj7R06Ys@daneel.sf-tec.de>

Am Montag, 9. Januar 2017, 10:59:13 schrieb Rolf Eike Beer:
> I need for several projects the ability to set CMAKE_C_STANDARD on older
> compilers, at least gcc 4.2, but preferably also down to gcc 3.4. I have
> them available, so testing is not the issue. But there are some problems
> besides "just record them".
> 
> The problems that I know of:
> 
> -WriteCompilerDetectionHeader last time had problems when the features for
> the compiler were recorded only for C for a given version, i.e. I can't
> just tell CMake "gcc 3.4ff. know about C99" without also recording C++
> features for that versions

This is actually not true. What happens is that the testcases assume that when 
one of them is set, the other one is set, too. This is also what is causing 
the current test breakage. I'll come up with a patch shortly, but maybe not 
today. The solution is easy: sort the subtests in the CMakeLists.txt and check 
for both variables independently.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170129/7a847f80/attachment.sig>

From brad.king at kitware.com  Mon Jan 30 08:30:52 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 30 Jan 2017 08:30:52 -0500
Subject: [cmake-developers] CMake 3.8 feature freeze on 2017-02-01
In-Reply-To: <4f8bf366-cd4d-77e4-0cfc-70fbb3e3e938@kitware.com>
References: <4f8bf366-cd4d-77e4-0cfc-70fbb3e3e938@kitware.com>
Message-ID: <0658d846-54b8-3c21-f449-0aeab2e3a8cd@kitware.com>

On 01/09/2017 02:10 PM, Brad King wrote:
> The feature freeze in 'master' for CMake 3.8 will be on Feb 1, 2017.
> I may announce a freeze in 'next' sometime in the preceding week so
> that we can get any remaining dashboard trouble cleaned up.

In order to get 'master' ready to branch for 3.8, 'next' is now frozen
to new features.  After 3.8 is branched I'll announce when post-3.8
development in 'next' is open.

Meanwhile the following types of changes are still welcome in 'next':

* Documentation updates
* Regression fixes
* Fixes for bugs in features new to 3.8
* A few specific changes that have been in progress for a while in
  their respective merge requests.  I will handle such merges to 'next'.

Thanks,
-Brad


From j.david.berger at gmail.com  Mon Jan 30 11:09:30 2017
From: j.david.berger at gmail.com (Justin Berger)
Date: Mon, 30 Jan 2017 09:09:30 -0700
Subject: [cmake-developers] Debugger for CMake
Message-ID: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>

I've made a proof of concept for a debugger integrated into CMake. The code
and notes about the implementation are here:

* https://gitlab.kitware.com/cmake/cmake/merge_requests/447

It is still a work in progress and there is still a decent chunk of work to
be done. The general approach works though and seems sufficient. I'd like
feedback on a few things: a) Is this feature worthwhile for eventual merge
into CMake? b) Is there any functionality not addressed that would make
this sort of tool more useful? c) What is the best approach to make this
kind of feature appealing to IDE / UI tools which currently work with
CMake?

Have a good one,
Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170130/8e72009f/attachment.html>

From arankin at robarts.ca  Mon Jan 30 11:22:43 2017
From: arankin at robarts.ca (Adam Rankin)
Date: Mon, 30 Jan 2017 16:22:43 +0000
Subject: [cmake-developers] Debugger for CMake
In-Reply-To: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>
References: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>
Message-ID: <8c7cb199ddc840f7aff6f3959176aff9@dag2.robarts.ca>

+1

Wish this existed since forever.

Cheers,
Adam

From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Justin Berger
Sent: Monday, January 30, 2017 11:10 AM
To: cmake-developers at cmake.org
Subject: [cmake-developers] Debugger for CMake

I've made a proof of concept for a debugger integrated into CMake. The code and notes about the implementation are here:

* https://gitlab.kitware.com/cmake/cmake/merge_requests/447

It is still a work in progress and there is still a decent chunk of work to be done. The general approach works though and seems sufficient. I'd like feedback on a few things: a) Is this feature worthwhile for eventual merge into CMake? b) Is there any functionality not addressed that would make this sort of tool more useful? c) What is the best approach to make this kind of feature appealing to IDE / UI tools which currently work with CMake?

Have a good one,
Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170130/af1bec9d/attachment.html>

From joubert.sy at gmail.com  Mon Jan 30 14:03:46 2017
From: joubert.sy at gmail.com (Sylvain Joubert)
Date: Mon, 30 Jan 2017 20:03:46 +0100
Subject: [cmake-developers] Debugger for CMake
In-Reply-To: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>
References: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>
Message-ID: <b9e81fee-eaa5-9177-ba5d-41d3dc5c7fa2@gmail.com>

Le 30/01/2017 ? 17:09, Justin Berger a ?crit :
> a) Is this feature worthwhile for eventual merge into CMake?

No doubt! :-)

 > c) What is the best
> approach to make this kind of feature appealing to IDE / UI tools which
> currently work with CMake?
>

If I recall correctly, one of the initial use cases for the server mode 
was exactly that. The very first prototype of Stephen Kelly had this 
feature and could trace were a variable was last modified, make a diff 
of the CMake state between two locations in a CMake script,...

I didn't look at your code and I'll let the server mode maintainers give 
their feedback too but I guess the best way to go would be to jump in 
server mode to add that. Besides, the server mode is especially designed 
to be IDE friendly.

Sylvain

From tobias.hunger at gmail.com  Tue Jan 31 02:26:17 2017
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Tue, 31 Jan 2017 08:26:17 +0100
Subject: [cmake-developers] Debugger for CMake
In-Reply-To: <b9e81fee-eaa5-9177-ba5d-41d3dc5c7fa2@gmail.com>
References: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>
 <b9e81fee-eaa5-9177-ba5d-41d3dc5c7fa2@gmail.com>
Message-ID: <CAMdWP3HXQdcOjt9xf6NJX8jR=gYvi1XEie3NfA5Wc3pVXYrcbg@mail.gmail.com>

On Jan 30, 2017 20:03, "Sylvain Joubert" <joubert.sy at gmail.com> wrote:

> c) What is the best

> approach to make this kind of feature appealing to IDE / UI tools which
> currently work with CMake?
>
>
If I recall correctly, one of the initial use cases for the server mode was
exactly that. The very first prototype of Stephen Kelly had this feature
and could trace were a variable was last modified, make a diff of the CMake
state between two locations in a CMake script,...


I liked the snapshots that were in Stephen Kelly's daemon-mode patch much
better than an interactive debugger.

Those much easier to use and visualize for an IDE than having an
interactive debugger. And they make much more sense IMHO: You can see state
and how that changes in every line instead of just the current one.

I didn't look at your code and I'll let the server mode maintainers give
their feedback too but I guess the best way to go would be to jump in
server mode to add that. Besides, the server mode is especially designed to
be IDE friendly.


I want to add support for snapshots as soon as they are available in cmake.

Is somebody working on the snapshot infrastructure? That is way too deep in
core cmake components for me to feel comfortable to implement. I will of
course happily write the code to integrate that into server mode:-)

Best Regards,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170131/e8452be5/attachment.html>

From brad.king at kitware.com  Tue Jan 31 07:54:38 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 31 Jan 2017 07:54:38 -0500
Subject: [cmake-developers] Debugger for CMake
In-Reply-To: <CAMdWP3HXQdcOjt9xf6NJX8jR=gYvi1XEie3NfA5Wc3pVXYrcbg@mail.gmail.com>
References: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>
 <b9e81fee-eaa5-9177-ba5d-41d3dc5c7fa2@gmail.com>
 <CAMdWP3HXQdcOjt9xf6NJX8jR=gYvi1XEie3NfA5Wc3pVXYrcbg@mail.gmail.com>
Message-ID: <d1921b95-4c5b-b32a-8430-358d456b2919@kitware.com>

On 01/31/2017 02:26 AM, Tobias Hunger wrote:
> I liked the snapshots that were in Stephen Kelly's daemon-mode
> patch much better than an interactive debugger.
> 
> Is somebody working on the snapshot infrastructure?

Not that I'm aware.  Some of the infrastructure is already there.
See `Source/cmState.h`.  When first added it supported capturing
a snapshot of the state before every function call and at other
key points.  However, we had to remove some of that because it
led to unbounded memory accumulation.  If it were to be added as
a debugging mode that may be okay, but it would likely have to
do something besides keeping everything in memory.

-Brad


From j.david.berger at gmail.com  Tue Jan 31 14:55:45 2017
From: j.david.berger at gmail.com (Justin Berger)
Date: Tue, 31 Jan 2017 12:55:45 -0700
Subject: [cmake-developers] Debugger for CMake
In-Reply-To: <CAMdWP3HXQdcOjt9xf6NJX8jR=gYvi1XEie3NfA5Wc3pVXYrcbg@mail.gmail.com>
References: <CAPWb3NT5FVGLTvLUiwqiM+sYuP+kpyA7O2eVsCtMOwUyJ5cr0w@mail.gmail.com>
 <b9e81fee-eaa5-9177-ba5d-41d3dc5c7fa2@gmail.com>
 <CAMdWP3HXQdcOjt9xf6NJX8jR=gYvi1XEie3NfA5Wc3pVXYrcbg@mail.gmail.com>
Message-ID: <CAPWb3NTNmhnyqxzfAkvnA4rjLm72+kwzV+QtLq3zGPb0WK=rPg@mail.gmail.com>

> I liked the snapshots that were in Stephen Kelly's daemon-mode patch much
better than an interactive debugger.

I'm not sure these tools have that much use-case overlap. As far as I can
tell, snapshots has roughly the same overhead / functionality as reversible
interactive debuggers; which is non trivial. Which tool is best for a given
problem seems situational; and having both seems useful.

I looked through the code for cmServer, since it maintains an instance of
cmake in process, it could register as a debug listener and get events /
set breakpoints and all in response to different requests coming in. The
issue here though is that it seems like (and maybe this is wrong?) the
actual call out to configure blocks on the libuv loop thread so it can't
get or process any requests while configure is running; so maybe keeping
them as seperate services running on separate loops is better.

The only way I could see it making sense to use a completely different
protocol would be if there were a semi-standard debugger protocol used in
different IDE's for debugging interpreted code, and then I think it makes
sense to pursue those. However, I did some research into that and didn't
find anything especially relevant -- IDE maintainers would obviously have a
better sense of that though. Also, even if there is such a thing, there is
no reason not to support multiple debug protocols; it is just a matter of
prioritization.

It seems like QtCreator is the only IDE which currently has current support
for server-mode; are there any Qt people active on the mailing list who
could weigh in on what approach makes the most sense from an integrators
perspective?

On Tue, Jan 31, 2017 at 12:26 AM, Tobias Hunger <tobias.hunger at gmail.com>
wrote:

> On Jan 30, 2017 20:03, "Sylvain Joubert" <joubert.sy at gmail.com> wrote:
>
> > c) What is the best
>
>> approach to make this kind of feature appealing to IDE / UI tools which
>> currently work with CMake?
>>
>>
> If I recall correctly, one of the initial use cases for the server mode
> was exactly that. The very first prototype of Stephen Kelly had this
> feature and could trace were a variable was last modified, make a diff of
> the CMake state between two locations in a CMake script,...
>
>
> I liked the snapshots that were in Stephen Kelly's daemon-mode patch much
> better than an interactive debugger.
>
> Those much easier to use and visualize for an IDE than having an
> interactive debugger. And they make much more sense IMHO: You can see state
> and how that changes in every line instead of just the current one.
>
> I didn't look at your code and I'll let the server mode maintainers give
> their feedback too but I guess the best way to go would be to jump in
> server mode to add that. Besides, the server mode is especially designed to
> be IDE friendly.
>
>
> I want to add support for snapshots as soon as they are available in cmake.
>
> Is somebody working on the snapshot infrastructure? That is way too deep
> in core cmake components for me to feel comfortable to implement. I will of
> course happily write the code to integrate that into server mode:-)
>
> Best Regards,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170131/da668758/attachment.html>