Re: [cmake-developers] C++11 all features available?

[Daniel Pfeifer]

On Mon, Aug 21, 2017 at 4:32 PM, Sebastian Holtermann 
wrote:

> Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie:
> > On 08/21/2017 09:53 AM, Sebastian Holtermann wrote:
> > > it looks like C++11 is now a requirement for CMake itself.
> >
> > Yes.  We just merged this:
> >
> >   https://gitlab.kitware.com/cmake/cmake/merge_requests/1132
> >
> > but you beat us to the announcement.
>
> I saw the MR last week and was delighted. The iterator type naming in `for`
> loops drove me mad.


Feel free to use `auto`, but you will need to hold off range based for
loops.


> > > But does this mean *all* the nice features from the std library can be
> > > used?
> > Not all.  We're still limited by some of the older C++11 compilers.
> > We'll have to see how things go on nightly builds.  As limitations
> > are found they can be documented in `Help/dev/source.rst`.
>

Please have a look at the nightly testers on
https://open.cdash.org/index.php?project=CMake and compare the feature
availability here: Please see
http://en.cppreference.com/w/cpp/compiler_support

Currently CMake is still built with Visual Studio 2010, ie. MSVC 16.0.

That means we should be able to use auto, nullptr, lambdas, std::array,
std::function, type traits, trailing return types, r-values, ...

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Future of ccmake and cmake-gui

[Daniel Pfeifer]

Hi,

With !977 merged, it is possible to base ccmake and cmake-gui on top of the
cmake server.
For demonstration, I copied the contents of the Source/CursesDialog
directory and added a proxy implementation of the classes `cmake` and
`cmState`. The result is 100% compatible with `ccmake`. The same would be
possible with cmake-gui.

Shall we proceed in this direction?

To make the server available everywhere, we should backport the code from
C++14 to C++11. I think this is limited to replacing `std::make_shared`.

For cmake-gui, the proxies could use Qt functionality (QProcess,
QJsonDocument, etc.). As a result, cmake-gui would not have any build
dependencies apart from Qt.

It might be worth considering to move ccmake and cmake-gui to their own
repositories.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMake PCH Prototype

[Daniel Pfeifer]

Hi Julian,

I have rebased my old precompiled-headers branch on master and created a
work-in-progress merge-request here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/984

Cheers, Daniel


2017-06-15 13:38 GMT+02:00 Julian Landesberger :

> Hallo Daniel,
>
> wir hatten uns nach deinem Meetup-Vortrag letzte Woche kurz über die
> Verwaltung von precompiled headers in CMake unterhalten. Du meintest
> damals, du hättest bereits eine Art Prototyp dafür geschrieben, der aber
> noch nicht an "großen" Projekten getestet wurde, und, dass du ihn dafür zur
> Verfügung stellen könntest.
> Ich würde den Prototypen gerne am Simulationscode des Lehrstuhls für
> Computation in Engineering der TU München ausprobieren. Der hat immerhin
> über 6000 source- und header-Dateien, ist also kein kompaktes
> Beispielprojekt mehr.
>
> Würde mich freuen wenn wir da was machen könnten und beste Grüße!
>
> Julian Landesberger
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Splitting CMakeLib

[Daniel Pfeifer]

On Wed, May 10, 2017 at 4:56 PM, Egor Pugin  wrote:

> Hi!
>
> I'd like to re-use some CMake internal components, but CMakeLib looks too
> fat.
> Is it possible to split it into several libraries? Are such changes
> welcome to contribute?
>

Strongly in favor. Such a modularization will be a benefit for CMake. It
will require to cleanup CMake's internal inter-dependencies and it will
help to keep them clean afterwards.
It will make CMake's codebase easier to approach by new contributors. It
will allow experiments like replacing individual parts (eg. new frontend).
Let's learn from LLVM/Clang.


> Some rough plan:
> 1) Support library (if any stuff)
> 2) Core library (targets etc.)
> 3) Generators library
> 4) CMake syntax library (lexer, parser)
> 5) Commands implementation library (could be merged with 4)
>

Don't merge the commands with the command interpreter/vm.

5) Scripting commands
6) Project commands
7) CTest commands
8) Package generators
9) Server
...

True cmake power is in its generators. It's always possible to rip off
> all other stuff, but in order to be tied with mainstream and
> contribute back, I'm asking this.
>

Personally, I regard the generators as obsolete and see the future in the
server.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Can we please require TR1 to build CMake?

[Daniel Pfeifer]

On Mon, Jan 9, 2017 at 8:30 PM, Brad King <brad.k...@kitware.com> wrote:

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

I have pushed an updated branch to
https://gitlab.kitware.com/cmake/cmake/merge_requests/760/diffs

The necessary subset of boost can be generated with:

```
mkdir -p cm_boost
bcp --boost= \
  boost/bind.hpp \
  boost/function.hpp \
  boost/mem_fn.hpp \
  boost/ref.hpp \
  boost/unordered_map.hpp \
  boost/unordered_set.hpp \
  boost/shared_ptr.hpp \
  boost/weak_ptr.hpp \
  boost/enable_shared_from_this.hpp \
  cm_boost
```

The resulting directory is 6.5 MB, 2.6 MB of which are preprocessed headers
for Boost.MPL.
When we remove them, we get the size down to 3.9 MB.
Removing individual config headers is tedious and does not save much.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

[Daniel Pfeifer]

On Mon, Apr 24, 2017 at 3:03 PM, Brad King  wrote:

> On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote:
> > Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
> >
> > This would be very convenient for a small input.
> >
> > Why should I always write a file for input?
>
> I agree that the options should be there but they can't be easily
> implemented without choosing our own temporary file which will have
> its own problems.
>
> The reason is that our internal process execution implementation
> does not support communication from the parent on stdin.  Fixing
> that is not something I'm prepared to do or even accept as a
> contribution because I'd rather migrate to libuv than extend our
> own process management implementation further.


Brad, can you share what the current status is on this? If I remember
correctly, then libuv cannot be built yet on all necessary compilers. Is
that still the case? This sounds like the biggest impediment. Once we can
rely on libuv, we can also use it for filesystem operations. This would
help solve issues like #13162.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Support for version suffixes

[Daniel Pfeifer]

On Mon, Mar 27, 2017 at 11:03 PM, Roger Leigh  wrote:

> Hi folks,
>
> I'd like to bring this issue to your attention to canvas some feedback
> regarding the use of version suffixes:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16716
>
> This is basically a proposal to allow an optional version suffix like
> "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak
> pattern, for better interoperability with systems and software releases
> already using such suffixes, and also to permit the use of such suffixes by
> CMake projects for their own purposes.  A version suffix would be usable
> anywhere currently using 4 digit versions, with all the necessary
> functionality in CMake being updated to handle this.
>
> The proposal linked above contains a much more detailed rationale and
> suggested implementation strategy.  I'd be very happy to hear any thoughts
> anyone has regarding this either on the above issue, or here.
>

Hi Roger,

Thanks for starting this discussion!

I started a prototype for a PKGCONF mode for find_package in addition to
CONFIG and PACKAGE. In this mode, CMake parses .pc files and creates one
imported target per file where values from the .pc file are set as target
properties. It works pretty well and does not rely on pkg-config. To be
compatible with pkg-config, I needed to extend
`cmSystemTools::VersionCompare`, because pkg-config uses RPM version
comparison. This however breaks current tests because 1.2 != 1.2.0 in the
RPM version comparison.

It might be necessary to provide several version comparison algorithms like
Debian, RPM, Semver.
Also splitting the version string into components may depend on the
versioning scheme. Given OpenSSL version 1.0.2g, is that patch 2 suffix g,
or rather patch 2g?

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Build multiple CMake projects

[Daniel Pfeifer]

On Fri, Mar 24, 2017 at 7:35 PM,  wrote:

> Hi,
>
> I have some CMake projects which depend on each other. They provide Config
> scripts (all generated with the help of CMakePackageConfigHelpers) and the
> CMake projects find there dependencies with find_package(). Even the
> transitive dependencies are correctly modelled (exported to the Config
> scripts with find_dependency).
>
> The setup in general is fine. The only drawback is that I have to build
> and install them manually in the correct order. For example A depends on B
> depends on C, I have to build+install first C, than B, then A ...
>
> The number of projects are getting more and more and it's getting harder
> to build them.
>
> So my question:
> a) Is there a CMake way to generate a dependency graph and build them in
> the correct order, i.e., the same as CMake does within a project with the
> targets but this time on project level?
> b) What possiblities are provided by CMake to support this?
> c) Are there tools you can recommend?
>

Make sure that your projects can be used both as a sub-project and as a
installed package. That means: if the installed package provides a target
called C::C, create an alias target with that name, so that projects A and
B can use that name in target_link_libraries in both cases.
The next thing is to make sure that `find_package(C REQUIRED)` finds the
installed package when it supposed to be used, but does nothing when C is
used as a sub-project. This can be achieved by overriding the
`find_package` command. The original command can be called by prefixing it
with _. Your top-level project might look like this:

set(subprojects A B C)

macro(find_package name)
  if("${name}" IN_LIST subprojects)
set("${name}_FOUND" TRUE)
  else()
_find_package("${name}" ${ARGN})
  endif()
endmacro()

add_subdirectory(A)
add_subdirectory(B)
add_subdirectory(C)
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Debugger for CMake

[Daniel Pfeifer]

On Thu, Feb 2, 2017 at 12:02 PM, Milian Wolff  wrote:

> On Dienstag, 31. Januar 2017 20:55:45 CET Justin Berger wrote:
> > > 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.
>
> GDB's MI is a standard protocol used by both clang and LLDB but I think it
> will be overkill for something like CMake. From my POV, CMake is very
> different from a normal application that you may debug. I mean do you
> really
> expect people to go line-by-line through a cmake script to see how it gets
> evaluated?


It depends.

I don't. Rather, I want to see the effect a call has on the CMake
> state, i.e. the approach that Stephen took is far better in my eyes.


I personally could not agree more. But that answer greatly depends on the
way you use CMake. If you use it as a build system generator and write your
CMakeLists.txt files in a clean, modern way, then Steve's approach is
perfect.
However, if you (ab)use CMake as a general purpose scripting language, then
a debugger might be welcome. Have a look at ExternalProject.cmake. You find
even more complex examples in the wild if you google for "cmake package
management".

I am against a debugger in CMake. We should invest in making the clean,
modern approach more clean, more modern, and more pleasant. Using CMake as
a general purpose scripting language should be possible but painful. Like a
continuous question whether you are using the right tool for the job. But
that is just my opinion.

PS: Adding an interactive debugger to the CMake scripting language might
complicate adding new language front-ends. If we allow an alternative
language front-end, you might be able to use existing tools to debug
complicated scripts.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] What should the behaviour of NUMBER_OF_LOGICAL_CORES be?

[Daniel Pfeifer]

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 
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]
> 
>
> El software de antivirus Avast ha analizado este correo electrónico en
> busca de virus.
> www.avast.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/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Discussion] Add python support for CMakeLists

[Daniel Pfeifer]

On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H,  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
> .
>
> 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
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Can we please require TR1 to build CMake?

[Daniel Pfeifer]

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables

[Daniel Pfeifer]

On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy  wrote:

> Please consider the following patch for inclusion in cmake.
>
> The problem is that when a project contains a FOO.DLL and a FOO.EXE,
> the cmake generator tries to build FOO.LIB for both.
> The FOO.EXE does not need a FOO.LIB.
>
> $ diff -urp CMake-3.7.0-orig/ CMake-3.7.0
> Only in CMake-3.7.0: build
> diff -urp CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx
> CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx
> --- CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx
> 2016-11-11 15:24:18.0 +0100
> +++ CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx
> 2016-11-28 14:28:26.344898900 +0100
> @@ -2310,7 +2310,9 @@ bool cmVisualStudio10TargetGenerator::Co
>  imLib += "/";
>  imLib += targetNameImport;
>
> -linkOptions.AddFlag("ImportLibrary", imLib.c_str());
> +if (this->GeneratorTarget->GetType() != cmState::EXECUTABLE) {
> +linkOptions.AddFlag("ImportLibrary", imLib.c_str());
> +}
>  linkOptions.AddFlag("ProgramDataBaseFile", pdb.c_str());
>
>  // A Windows Runtime component uses internal .NET metadata,
> --
>
>
I am no windows expert, but I think the import library is required when you
want to link against the executable.
Please see https://cmake.org/cmake/help/v3.7/prop_tgt/ENABLE_EXPORTS.html
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Questions about C++ version and third party libraries

[Daniel Pfeifer]

On Sat, Nov 26, 2016 at 11:17 AM, mateusz janek 
wrote:

> Hello CMake community,
>
> First of all, I want to say "Hello" to everyone, I am new to the CMake
> developers community.
>

Hello and welcome!


> I have some questions about developing rules, before I'll start to write
> the code:
> -In which version of C++ is CMake written?
>

CMake can still be built with Visual Studio 2008. It is mostly written in
C++98 but built with C++14 where possible. We use some abstractions like
CM_NULLPTR or CM_OVERRIDE. The parts for the language server are written in
C++14.

-Am I right that it is forbidden to use third party libraries?
>

CMake uses several third party libraries. Have a look at the Utilities
directory.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] improved CodeBlocks group support

[Daniel Pfeifer]

On Mon, Nov 21, 2016 at 4:21 PM, Tobias Hunger 
wrote:

> Hi Tim,
>
> Am 21.11.2016 01:19 schrieb "tim cotter" :
> >
> > i've patched my local cmake to automatically add a virtual folder group
> option for every file in a code blocks project.
> >
> > it's not proper support for cmake source groups.
> > but it does what i want it to do.
> >
> > the patch is small.
> >
> > would the community be interested in such a thing?
>
> Have you tested this with the IDEs that user this extra generator?
> CodeBlocks and QtCreator are the ones I know to be using this.
>
> > if so, how would i go about submitting it?
>
> If you can create a merge request at gitlab.kitware.com, then that would
> be the best option. Not sure you can get an account there (that is able to
> create merge requests).
>
https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] iwyu and clang-tidy not working under mac os

[Daniel Pfeifer]

On Wed, Oct 26, 2016 at 11:27 AM, Roman Wüger  wrote:

> Hello,
>
> I set CMAKE_CXX_INCLUDE_WHAT_YOU_USE and CMAKE_CXX_CLANG_TIDY. Both work
> as expected with CMake 3.6.2 under linux. Under Mac OS with the same
> sources and the same CMake version doesn't produce any output.
>
> On Linux clang 3.8 is used, on Mac OS it is AppleClang 7.3.0 with
> clang-tidy installed from homebrew.
>
> Any hints?
>

When you run "make VERBOSE=1" and look at what is executed, do you see any
"cmake --iwyu" invocations?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

[Daniel Pfeifer]

On Wed, Oct 5, 2016 at 12:54 PM, Nils Gladitz  wrote:
> On 04.10.2016 11:20, Tobias Hunger wrote:
>>
>> On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote:

 The list we need would thus be built up to contain all COMMAND
 arguments to add_test that are also build targets in CMake.
>>>
>>> The list would also need to include targets mentioned in generator
>>> expressions such as `$`.  This will almost certainly
>>> be better done as a CMake feature implemented in C++.  This was actually
>>> an early design philosophy: do the hard stuff in C++ so that complex
>>> logic is not needed in CMake-language code.
>>
>> Access to the list of defined tests would be nice to have in the
>> server-mode,
>> too:-)
>>
>> If some work is done in that direction, please keep server-mode in mind
>> when
>> designing the APIs. I would love to reuse them to expose that information
>> to
>> clients.
>
>
> This might be rare but the tests that cmake knows about might differ from
> the tests that ctest knows about given that tests can be dynamically defined
> through TEST_INCLUDE_FILE[1].
>
> I've never used it that way but I was considering e.g. querying test
> binaries (produced at build time) for the tests they define and making those
> available dynamically when ctest processes CTestTestfile.cmake. This is in
> contrast to e.g. FindGTests.cmake's GTEST_ADD_TESTS() which tries to
> accomplish the same thing at configuration time by parsing test sources
> instead.

+1. I wrote about that approach here:
http://purplekarrot.net/blog/cmake-and-test-suites.html
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] semantics of ctest_build(APPEND)

[Daniel Pfeifer]

Hi,

the documentation of the ctest_build command states "Append semantics
are defined by the dashboard server in use." I think this is not
precise enough.

The client side effect of APPEND is that CTest creates an
Append="true" attribute in the XML. It does not append anything to the
already existing file. The existing file is overwritten.

For append to work as expected, it is necessary to call
ctest_submit(PARTS Build) between the ctest_build commands. This is
not documented.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Daniel Pfeifer]

On Thu, Sep 8, 2016 at 5:52 PM, Brad King  wrote:
> On 09/08/2016 10:15 AM, Craig Scott wrote:
>> the current behaviour of DEPENDS. At the moment, if test B depends
>> on test A, test B still executes if test A fails.
>> It is unexpected because I'd initially have thought of DEPENDS as
>> meaning I can't run test B if test A fails, after all, B depends
>> on A which I'd interpret to mean if A fails, then something B requires
>> isn't working. Conversely, this is also useful because until now,
>> DEPENDS was the only way to get cleanup functionality to run after
>> other tests, and if those other tests fail, we still want the
>> cleanup to occur.
>
> At one time we only had serial testing so the order of tests was
> fully controllable and based on the order of addition.  There were
> never any conditions for whether a test would run based on results
> of other tests.  Then when parallel testing was added we need a
> way to restore *order* dependencies, so DEPENDS was added just
> for that.  Maybe a better name would have been RUN_AFTER.
>
>> adding a DEPENDS_ON_SUCCESS test property or something similar
>> which would implement the perhaps more intuitive behaviour of not
>> running dependent tests when a dependee fails. If that was done,
>> then implementing the "don't run fixture tests if any fixture
>> setup fails" logic would be trivial.
>
> The semantics of this will have to be carefully though out, in
> particular with respect to enabling test dependencies.  Right now
> ctest arguments like -E can exclude tests.  What if those are
> dependencies of included tests?
>
> I think if we introduce the notion of tests requiring other tests
> then a new model of test selection and enablement needs to be
> designed.  Some kind of test DAG could be defined with various
> roots and subgraphs being selectable an causing all reachable
> tests to be included.

This could be expanded even further. If "tests requiring other tests"
is generalized to "tests requiring X", wouldn't this allow incremental
testing?  Say you change one file in your project. You rebuild only
the parts of the project that are affected by this change. Then you
rerun only the tests that are affected by the change. This really has
to be carefully thought out.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Daniel Pfeifer]

On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly  wrote:
> 3) Compute cmGeneratorTarget state non-lazily in its constructor.
> * Historically target state for generators was computed lazily because it
>   might need to be cleared and re-computed.  That is no-longer true.

SourceFilesMap is cleared in a call to AddSource. It is then
recomputed the next time GetSourceFiles is called.

> * For example, the LinkInformation is populated lazily in
>   cmGeneratorTarget::GetLinkInformation.
> * Instead the LinkInformation could be populated in the cmGeneratorTarget
>   constructor for all known configurations.  That is what generators will
>   request during generate-time anyway.
> * Doing this will make it possible to split a cmComputedTarget out of
>   cmGeneratorTarget.

I started splitting out a cmComputedTarget. It is initialized in its
constructor for one single configuration.
The entries of the ComputedTargets map are computed and recomputed
lazily because of the reason mentioned above.

Please review: https://github.com/purpleKarrot/CMake/commits/computed-target
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Security in CMake

[Daniel Pfeifer]

Hi Egor,

On Sat, Aug 20, 2016 at 1:48 PM, Egor Pugin  wrote:
> Hi,
>
> I'm working on a package manager based on cmake.

Please rethink that approach. Your package manager should support
CMake. It should not be based on it. Your design will be safer and
more flexible.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] variables for top level project version

[Daniel Pfeifer]

Hi!

The project() command currently sets some variables in both
PROJECT_ and _ form. So far good.

It also sets CMAKE_PROJECT_NAME to the top level project name.  This
is not documented.

It does not set any other variables of the form CMAKE_PROJECT_.
This would be useful for the version variables.

CPack.cmake initializes CPACK_PACKAGE_NAME with ${CMAKE_PROJECT_NAME},
but it initializes CPACK_PACKAGE_VERSION with "0.1.1".  It should
initialize all version variables with the values from the top level
project() command.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] QtAutoGenerators output in Ninja

[Daniel Pfeifer]

Hi,

CMake currently puts messages like "Generating moc source" into the
buildlog. This conflicts with the convention "no output == all good".
The messages blend nicely in the colorful output of Unix Makefiles,
but when using the Ninja generator, they create quite some noise.

How can this be improved?
* remove the messages (no output == all good)
* add an option to silence them
* add an option to show them and hide them per default
* ...

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

[Daniel Pfeifer]

On Fri, Jul 1, 2016 at 4:12 PM, Ben Boeckel  wrote:
> On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote:
>> 2. change GetEnv to return std::unique_ptr which will be
>>   automatically deleted once out of scope and we still can check if there
>>   wasn't such env if it's empty.
>
> Hrm. I'd rather use std::optional than relying on implicit nullptr
> semantics.

+1.

This class here should be renamed to cmOptional and moved to its own
file, so it may be reused:
http://public.kitware.com/gitweb?p=stage/cmake.git;a=blob;f=Source/cmArchiveWrite.h;h=f847d09b74922e800293e70c3171accb500c083c;hb=refs/heads/master#l22
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

[Daniel Pfeifer]

Hi Dāvis,

On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns  wrote:
> On Windows getenv uses ANSI codepage so it needs to be encoded to
> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> and encode that.

Your change to the SystemTools::GetEnv function introduces memory
leaks, since you return a pointer to a new[]-ed array.
It seems impossible to refactor SystemTools::GetEnv to use _wgetenv
and provide interface compatability.
You should probably introduce a function that returns std::string and
uses GetEnvironmentVariableW internally.

> Also typically Windows applications (eg. MSVC compiler) use current
> console's codepage for output to pipes so we need to encode that
> to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
>
> Next, when we're outputing to console need to use wide functions.
>
> This change allows that compilers such as MSVC on Windows can be
> installed in non-ASCII path and will work correctly for all
> console's codepages which supports that path's characters.

Sounds useful. I cannot really comment on this.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master

[Daniel Pfeifer]

On Wed, Jun 29, 2016 at 10:17 AM, Tobias Hunger  wrote:
> On Mi, 2016-06-29 at 09:54 +0200, Rolf Eike Beer wrote:
>> Am 2016-06-29 09:35, schrieb Tobias Hunger:
>> > Hello Brad,
>> >
>> > I currently get more than 2000 warnings when building cmake master, all
>> > about
>> > missing overrides.
>> >
>> > Could you please take the fix warning patch from
>> > https://github.com/hunger/CMake/commits/for-upstream and apply it to
>> > master?
>> > That fixes all those pesky override warnings.
>>
>> This should be CM_OVERRIDE.
>
> Changed.

Thanks. I merged it to next.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch for CM_OVERRIDE

[Daniel Pfeifer]

On Wed, Jun 29, 2016 at 7:15 AM, Roman Wüger  wrote:
> Hello,
>
> I've attached a patch for the CM_OVERRIDE commit

Hi Roman, I added "override" to the destructor on purpose. The intent
is to make the check fail in Visual Studio 10.

See the commit message here:
https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=9e2d6f0c4d19e1ae1652071ea783ad577ea93e28

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Script to update liblzma from upstream.

[Daniel Pfeifer]

Hi Brad,

I have attached a patch that adds a script to update liblzma from
upstream (closely modeled after the other update scripts).  I am not
sure how these kinds of scripts need to be run.

We currently have a copy of liblzma version 5.0.5. The latest version
on the 5.0 branch is 5.0.8. Once the script is introduced, we may
consider switching to the 5.2 branch.

Cheers, Daniel
From c0401e6f56fe5c9c77e9a80a2c2ab063930f70ed Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Tue, 28 Jun 2016 23:10:11 +0200
Subject: [PATCH] Add script to update liblzma from upstream

---
 Utilities/Scripts/update-liblzma.bash | 29 +
 1 file changed, 29 insertions(+)
 create mode 100755 Utilities/Scripts/update-liblzma.bash

diff --git a/Utilities/Scripts/update-liblzma.bash b/Utilities/Scripts/update-liblzma.bash
new file mode 100755
index 000..4933017
--- /dev/null
+++ b/Utilities/Scripts/update-liblzma.bash
@@ -0,0 +1,29 @@
+#!/usr/bin/env bash
+
+set -e
+set -x
+shopt -s dotglob
+
+readonly name="liblzma"
+readonly ownership="liblzma upstream <xz-de...@tukaani.org>"
+readonly subtree="Utilities/cmliblzma"
+readonly repo="http://git.tukaani.org/xz.git;
+readonly tag="v5.0"
+readonly shortlog=false
+readonly paths="
+  src/common/sysdefs.h
+  src/common/tuklib_integer.h
+  src/liblzma
+  COPYING
+"
+
+extract_source () {
+git_archive
+pushd "${extractdir}/${name}-reduced"
+mv src/common .
+mv src/liblzma .
+rmdir src
+popd
+}
+
+. "${BASH_SOURCE%/*}/update-third-party.bash"
-- 
2.9.0

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Status of pre-compiled headers

[Daniel Pfeifer]

On Mon, Jun 27, 2016 at 5:24 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
> On Mon, Jun 27, 2016 at 5:09 PM, Brad King <brad.k...@kitware.com> wrote:
>> On 06/24/2016 12:19 PM, Oleh Kravchenko wrote:
>>> As far as I can see from issue tracker and the mail list archives of
>>> "precompiled headers" feature we are still struggling for solution.
>>> https://cmake.org/Bug/view.php?id=1260
>>> https://gitlab.kitware.com/cmake/cmake/issues/1260
>>
>> Yes.  Currently we support some primitives that make it possible to use
>> PCH in some circumstances but it is not a first-class feature.  One
>> reason is that we (upstream) have never needed it for our own projects.
>>
>>> I'm ready to contribute to development, but have not idea where shall I 
>>> start :)
>>> I have in-depth knowledge of C/C++ development for different platforms
>>> (Windows, Linux), (arm, x86, amd64) and GCC/MSVC compilers.
>>
>> Great, thanks for stepping forward.
>>
>> The first step is to propose porcelain (e.g. a target property) to
>> enable and configure PCH settings, along with examples of how that
>> would map to the underlying generator behavior.  We need to find an
>> abstraction that works well for the way each native toolchain does
>> PCH.
>
> You may find this branch useful as a staring point:
> https://github.com/purpleKarrot/CMake/commits/pch
>
> The reason I never finished that is the same as Brad mentioned above:
> I currently don't need this feature for any project.

Please also see the discussion here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12589
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Status of pre-compiled headers

[Daniel Pfeifer]

On Mon, Jun 27, 2016 at 5:09 PM, Brad King  wrote:
> On 06/24/2016 12:19 PM, Oleh Kravchenko wrote:
>> As far as I can see from issue tracker and the mail list archives of
>> "precompiled headers" feature we are still struggling for solution.
>> https://cmake.org/Bug/view.php?id=1260
>> https://gitlab.kitware.com/cmake/cmake/issues/1260
>
> Yes.  Currently we support some primitives that make it possible to use
> PCH in some circumstances but it is not a first-class feature.  One
> reason is that we (upstream) have never needed it for our own projects.
>
>> I'm ready to contribute to development, but have not idea where shall I 
>> start :)
>> I have in-depth knowledge of C/C++ development for different platforms
>> (Windows, Linux), (arm, x86, amd64) and GCC/MSVC compilers.
>
> Great, thanks for stepping forward.
>
> The first step is to propose porcelain (e.g. a target property) to
> enable and configure PCH settings, along with examples of how that
> would map to the underlying generator behavior.  We need to find an
> abstraction that works well for the way each native toolchain does
> PCH.

You may find this branch useful as a staring point:
https://github.com/purpleKarrot/CMake/commits/pch

The reason I never finished that is the same as Brad mentioned above:
I currently don't need this feature for any project.

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] libuv in cmake (was: daemon-mode meeting last Tuesday)

[Daniel Pfeifer]

On Mon, Jun 27, 2016 at 5:02 PM, Brad King  wrote:
> On 06/24/2016 04:12 AM, Tobias Hunger wrote:
>>> Please think about adding libuv earlier. As Brad wrote before, libuv
>>> could replace some #ifdef code that we currently have
>>
>> Feel free to merge it at your own pace. I'll just use your copy then:-)
>>
>> Currently I just link to an external version of said library and have
>> not yet tried to figure out what the policy is wrt. 3rd party code in
>> cmake. Stephen suggested that we would need to include a copy into the
>> cmake repository and hinted at a script that keeps these copies
>> updated.
>
> I can take care of the details of getting libuv enabled as a third-party
> package within CMake.  I've just been waiting for time to do it and an
> initial use case.  Daniel, if you are interested in this I once started
> a prototype to convert cmSystemTools::RunSingleCommand over to libuv
> that you could take over finishing.  Once you have it working I can look
> at making libuv available in `master`.

I currently have some open topics that I want to finish first.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode meeting last Tuesday

[Daniel Pfeifer]

On Fri, Jun 24, 2016 at 5:24 PM, Tobias Hunger <tobias.hun...@gmail.com> wrote:
> Hi Daniel,
>
> On Fri, Jun 24, 2016 at 5:08 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> 
> wrote:
>>>> Currently cmake-gui supports switching generators, build trees, etc., so
>>>> there is some precedent for such switching within a single process.  If
>>>> we have (re-)initialization bugs they should simply be fixed.
>>>
>>> So you opt for enabling the cmake-server to switch between different
>>> build directories?
>>
>> Clients who need this feature could simply restart the server in the
>> new directory.
>
> yes, that was what Stephen and me thought, too. I understood Brad to
> imply that we should just do everything inside server-mode and fix any
> fallout we run into instead.

I just opened cmake-gui and checked what exactly can be changed. There
is no graphical option to change the generator (you can change the
option sting in the cache, of course). When you change the binary
directory, it reads the cache from that directory, with the effect
that the source directory is changed too. To me, that feels like a
hard reset/restart.

To me it feels like the only reason why there is precedent for such
switching within a single process, is that cmake-gui links against
libcmake instead of using the cmake-server. I don't see any technical
reason apart from that it hasn't been split into two processes yet.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode meeting last Tuesday

[Daniel Pfeifer]

On Fri, Jun 24, 2016 at 4:56 PM, Tobias Hunger  wrote:
> Hi Brad,
>
> On Thu, Jun 23, 2016 at 10:46 PM, Brad King  wrote:
>>>   * This is currently used to set sourcedirectory, builddirectory and
>>> generator.
>>>
>>> These three should be passed in via the command line instead, again
>>> to avoid trouble with users switching to different build 
>>> directories/etc.
>>> while the daemon is running, which might trigger problems with state
>>> cleanup, etc.
>>
>> Currently cmake-gui supports switching generators, build trees, etc., so
>> there is some precedent for such switching within a single process.  If
>> we have (re-)initialization bugs they should simply be fixed.
>
> So you opt for enabling the cmake-server to switch between different
> build directories?

Clients who need this feature could simply restart the server in the
new directory.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode meeting last Tuesday

[Daniel Pfeifer]

On Thu, Jun 23, 2016 at 2:27 PM, Tobias Hunger  wrote:
>   * We both think it only makes sense to merge the infrastructure part into
> cmake (if it passes review first of course) once we have some 
> functionality
> that is genuinely useful. So we want to aim at having the infrastructure
> and the codemodel merged in one go.

Please think about adding libuv earlier. As Brad wrote before, libuv
could replace some #ifdef code that we currently have (process
handling, file operations). I am currently refactoring the code around
the cmOutputConverter and I would like to introduce a cmPath class (I
will write more about that later, but I can already say that libuv
might come handy for some functionality).

>   2.7 cache (report contents of CMakeCache.txt file)
>
>   * Review by other potential users would be appreciated, but no obvious
> problems seen.

Is this needed? If the CMakeCache.txt file continues to be written,
clients could just parse that file. If clients want to make changes
(ie. cache editors), they can rewrite the file. Is that a problem? I
assume it is, because CMake needs to reconfigure when it rereads it.
In that case, the server should provide a way to report the contents,
but also ways to modify it.

Cheers, Daniel

PS: Next meeting in a Biergarten in Munich?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

On Tue, Jun 14, 2016 at 3:14 PM, Brad King  wrote:
> On 06/13/2016 10:16 AM, Brad King wrote:
>>> Can't `std::ifstream` and `std::ofstream` be used directly? It seams
>>> that kwsys does some workarounds
>>
>> Yes, std::{o,f}stream can be used directly.
>
> On second thought, std::{i,o}fstream should not be used to open files.
> The cmsys::{i,o}fstream interfaces are not about compatibility, they
> are about opening files on Windows using the wide character APIs by
> converting from UTF-8 to UCS-2.

I see.

There are a few uses of std::{i,o}fstream. I guess we should migrate
them all to kwsys.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] fixup! Remove redundant arguments from fstream constructors

[Daniel Pfeifer]

This is a fixup for the std-fstream topic.
From 1d52cfe88e98738a1f1172cd1723a07ac579d2eb Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Tue, 14 Jun 2016 09:47:46 +0200
Subject: [PATCH] fixup! Remove redundant arguments from fstream constructors

---
 Tests/AliasTarget/commandgenerator.cpp | 3 +--
 Tests/AliasTarget/targetgenerator.cpp  | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Tests/AliasTarget/commandgenerator.cpp b/Tests/AliasTarget/commandgenerator.cpp
index 57a9887..c4d80a1 100644
--- a/Tests/AliasTarget/commandgenerator.cpp
+++ b/Tests/AliasTarget/commandgenerator.cpp
@@ -5,8 +5,7 @@
 
 int main(int argc, char** argv)
 {
-  std::fstream fout;
-  fout.open("commandoutput.h");
+  std::ofstream fout("commandoutput.h");
   if (!fout)
 return 1;
   fout << "#define COMMANDOUTPUT_DEFINE\n";
diff --git a/Tests/AliasTarget/targetgenerator.cpp b/Tests/AliasTarget/targetgenerator.cpp
index 15cfc89..4de4792 100644
--- a/Tests/AliasTarget/targetgenerator.cpp
+++ b/Tests/AliasTarget/targetgenerator.cpp
@@ -3,8 +3,7 @@
 
 int main(int argc, char** argv)
 {
-  std::fstream fout;
-  fout.open("targetoutput.h");
+  std::ofstream fout("targetoutput.h");
   if (!fout)
 return 1;
   fout << "#define TARGETOUTPUT_DEFINE\n";
-- 
2.8.3

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

On Mon, Jun 13, 2016 at 2:09 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> On Mon, Jun 13, 2016 at 00:03:29 +0200, Daniel Pfeifer wrote:
>> Can you show an example? To be clear: We are looking for a function,
>> that has a code path for `str == NULL` and a *different* codepath for
>> `str[0] = '\0'`.
>
> As input to functions?

Either input or output. I am interested about both cases.

> Usually NULL means "unset". See properties,
> variable values, etc. As an output, any place which doesn't care should
> already be using GetSafeDefinition().

I know that, at the moment, NULL is used for "unset" in many places. I
am trying to figure out whether we could theoretically use "empy" to
mean "unset".
If there is a case where we distinguish between null and empty, this
will not be possible.

> As a concrete example, `set(CACHE)` cares about NULL versus *s == NULL:

Thanks for the example. I found the check for `s != NULL` in the
second line. Can you help me finding the check for `*s == NULL`?

> const char* existingValue = state->GetCacheEntryValue(variable);
> if (existingValue &&
> (state->GetCacheEntryType(variable) != cmState::UNINITIALIZED)) {
>   // if the set is trying to CACHE the value but the value
>   // is already in the cache and the type is not internal
>   // then leave now without setting any definitions in the cache
>   // or the makefile
>   if (cache && type != cmState::INTERNAL && !force) {
> return true;
>   }
> }
>
> // if it is meant to be in the cache then define it in the cache
> if (cache) {
>   this->Makefile->AddCacheDefinition(variable, value.c_str(), docstring,
>  type, force);
> } else {
>   // add the definition
>   this->Makefile->AddDefinition(variable, value.c_str());
> }
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

On Sun, Jun 12, 2016 at 4:26 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> On Fri, Jun 10, 2016 at 15:30:05 +0200, Daniel Pfeifer wrote:
>> Passing and returning strings: We have `const char*`, `std::string`,
>> and `std::string const&`. Unifying this can affect performance.
>> Storing `const char*` in a `std::string` creates a (potentially
>> unneded) copy (assuming it is not null).
>
> I went through and changed all `const char*` paramters to `std::string
> const&` where the pointer was given to a string within the function
> (unless it was an error path or such). This allows eliding another
> allocation.

I am aware of that. In case of passing `foo.c_str()`, this moved the
creation of the unnecessary copy from inside the function to the call
site, resulting in more allocations rather than less, assuming the
function is called more than once. It is important to run clang-tidy
after each such refactoring to remove the now unnecessary c_str()
calls.

>> `const char*` can distinguish
>> invalid from empty. Do we actually need this distinction?
>
> It's used all over the place.

Can you show an example? To be clear: We are looking for a function,
that has a code path for `str == NULL` and a *different* codepath for
`str[0] = '\0'`.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Dogfooding: clang-tidy, include-what-you-use, link-what-you-use

[Daniel Pfeifer]

Hi,

now that we have integrated include-what-you-use, clang-tidy, and just
recently also a mechanism for link-what-you-use, it is time we start
eating our own dog food.

https://en.wikipedia.org/wiki/Eating_your_own_dog_food

I have set up a dashboard build where all three mechanisms are enabled:

https://open.cdash.org/viewBuildError.php?type=1=4408215

The buildscript can be seen here:

https://github.com/purpleKarrot/dotfiles/blob/master/config/cmake/ci_cmake.cmake

I have already drastically reduced the number of clang-tidy warnings
in the last weeks. I am currently experimenting with
include-what-you-use and will push some changes in the coming days.
Who wants to resolve the link-what-you-use violations?

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 3:43 PM, Brad King <brad.k...@kitware.com> wrote:
> On 06/10/2016 09:30 AM, Daniel Pfeifer wrote:
>> By looking at the CMake source code, there are some inconsistencies
>> regarding coding conventions. This is not a big problem and fixing
>> them probably does not have a high priority.
>> I would like to know what conventions to follow for new code.
>
> Please look at documenting this in CONTRIBUTING.rst once we resolve
> this discussion.

ok.

>> Formatting: No longer an issue. A .clang-format is provided and most
>> inconsistencies have disappeared.
>
> Yes, and thanks for all your work on that.
>
>> Braces around single conditional statements: This is currently not
>> consistent. Should they be avoided? Should they be required? We could
>> add the missing ones with clang-tidy. If we want them.
>
> The intention has been to use braces for all blocks even with single
> statements.  Due to lack of documentation and enforcement this has
> not been maintained consistently.

I have added some missing ones:
https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=a16bf141bc5d393b27d13d8235d95a1b034052c2

>> Naming conventions: Classes are named  cmLikeThis. Member functions
>> and member variables are named LikeThis. Local variables are named
>> likeThis. Members are always accessed with `this->`.
>
> Yes, though there are also many local variables named `like_this` too.
> I have no strong feelings on enforcing local variable name conventions.
>
>> So far it is pretty consistent. But how to name free functions and
>> macros? I have seen all kinds of variations.
>
> No convention was ever established for those.

I see. Any strong opinion whether a convention should be established?
I would assume UPPER_CASE for macros. Any prefix?
Any opinions about free functions?

>> `const T` or `T const` (also: `const T&` or `T const&`): Currently,
>> CMake uses both. I have not analyzed which one dominates.
>
> I prefer `T const` always, except for `const char*` specifically.

Good.

>> Passing and returning strings: We have `const char*`, `std::string`,
>> and `std::string const&`. Unifying this can affect performance.
>> Storing `const char*` in a `std::string` creates a (potentially
>> unneded) copy (assuming it is not null). `const char*` can distinguish
>> invalid from empty. Do we actually need this distinction?
>
> Last year we had a few cleanup passes done along those lines, but
> it is far from consistent everywhere.  There  are cases where we
> need to distinguish invalid from empty, like GetDefinition().  It
> would be nice to have an optional or something like that
> so we can keep the distinction but avoid using `const char*` all
> over.  Any change like this should be introduced gradually, as
> many of the related areas are performance sensitive.

So the convention would be to use `std::string` or
`cmOptional` as return values. Should `std::string
const&` be allowed as return value?
Arguments should be preferred as `const&` I assume.


Some other questions:

Can't `std::ifstream` and `std::ofstream` be used directly? It seams
that kwsys does some workarounds for Visual Studio 2005 and newer.
That surprises me. Workarounds are usually used for older, not newer
compilers.

I see that `#include ` is preferred over `#include
`. Are there old compilers supported that prohibit the latter
or was it just not changed yet?

cmStandardIncludes.h includes many standard headers. That is against
the idea of include-what-you-use. Is there a particular requirement or
was it just not cleaned up yet?

Should we begin using newer language features optionally by providing
macros like CM_OVERRIDE?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 5:19 PM, Tobias Hunger <tobias.hun...@qt.io> wrote:
> On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote:
>> If used consistently, it indicates that you are dealing with a member.
>> I personally prefer `this->` over `m_`. With semantic syntax
>> highlighting you probably don't need either of them. But then again,
>> you often look at code that does not have semantic highlighting (eg.
>> inside diffs).
>
> So you optimize for teletype terminals and punish everybody that has invested 
> in
> new stuff like screens with *color* in the last couple of decades:-/
>
> /me is trapped in 1995!

In 2016, semantic highlighting is the exception rather than the norm.
I expect that to remain that way for some years to come.
Git diff output, compiler diagnostics, github, the woboc code browser
are all very colorful. Yet, members are not highlighted anywhere.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Review request: extract-cmMessenger branch

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 8:17 PM, Stephen Kelly  wrote:
> Tobias Hunger wrote:
>> Forcing messages into one consistent format will be a pain, agreed, but
>> continuing to add messages in whatever form the developer likes at the
>> time of writing the code is even worse. CMake has a lot of different error
>> message styles!
>
> This is something my branch addresses in part, which is why I drew attention
> to it in the context of the daemon.
>
>> If you were to unify on e.g.
>>
>> CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO):
>> MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES
>>
>> then you will probably hit existing code paths in IDEs.
>
> I don't think that's possible for all messages (not all messages have file
> or line information).
>
> However, that's not a problem when messages are delivered through the
> daemon, so I suggest that
>
>  https://github.com/steveire/cmake/tree/extract-cmMessenger
>
> and the daemon itself are good places to direct your attention to improve
> this situation.

I have reviewed the branch and wrote some inline comments on github.
Overall, I confirm this is the right approach. So, "approval" from my side.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

On Fri, Jun 10, 2016 at 4:16 PM, Tobias Hunger <tobias.hun...@qt.io> wrote:
> On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote:
>> Naming conventions: Classes are named  cmLikeThis. Member functions
>> and member variables are named LikeThis. Local variables are named
>> likeThis. Members are always accessed with `this->`. So far it is
>> pretty consistent. But how to name free functions and macros? I have
>> seen all kinds of variations.
>
> May I asked why "this->" is used so often? I find it totally annoying to skip
> this line noise all the time and I never encountered this convention before.

If used consistently, it indicates that you are dealing with a member.
I personally prefer `this->` over `m_`. With semantic syntax
highlighting you probably don't need either of them. But then again,
you often look at code that does not have semantic highlighting (eg.
inside diffs).
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Questions about coding conventions

[Daniel Pfeifer]

Hi,

By looking at the CMake source code, there are some inconsistencies
regarding coding conventions. This is not a big problem and fixing
them probably does not have a high priority.
I would like to know what conventions to follow for new code.

Formatting: No longer an issue. A .clang-format is provided and most
inconsistencies have disappeared.

Braces around single conditional statements: This is currently not
consistent. Should they be avoided? Should they be required? We could
add the missing ones with clang-tidy. If we want them.

Naming conventions: Classes are named  cmLikeThis. Member functions
and member variables are named LikeThis. Local variables are named
likeThis. Members are always accessed with `this->`. So far it is
pretty consistent. But how to name free functions and macros? I have
seen all kinds of variations.

`const T` or `T const` (also: `const T&` or `T const&`): Currently,
CMake uses both. I have not analyzed which one dominates.

Passing and returning strings: We have `const char*`, `std::string`,
and `std::string const&`. Unifying this can affect performance.
Storing `const char*` in a `std::string` creates a (potentially
unneded) copy (assuming it is not null). `const char*` can distinguish
invalid from empty. Do we actually need this distinction? Or should we
assume empty==invalid and always prefer `std::string const&`
arguments? Or should we introduce a C++17-like cmStringView?

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Review request: extract-cmMessenger branch

[Daniel Pfeifer]

On Thu, Jun 9, 2016 at 2:17 PM, Brad King  wrote:
> On 06/09/2016 05:06 AM, Tobias Hunger wrote:
>> CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target):
>>   Cannot find source file:
>>
>> unknownFile.qml
>>
>>   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
>>
>>
>> CMake Error at src/1/CMakeLists.txt:8 (add_subdirectory):
>>   add_subdirectory given source "app1" which is not an existing directory.
>
> This is meant to be the canonical style, and the IssueMessage
> infrastructure produces it.  Not everything has been converted
> to use it though.

I have rebased again and pushed to my github clone:
https://github.com/purpleKarrot/CMake/commits/extract-cmMessenger

If I am not mistaken, the second commit improves consistency of this
canonical style. The error messages became simpler. I for one never
understood what "include could not find load file" really meant.

However, the tests currently fail. I am unsure whether the
implementation should be "fixed" or whether the tests should be
adapted. Example:

  Expected stderr to match:

   expect-err> ^CMake Warning \(dev\) at
message-internal-warning.cmake:3 \(include\):
   expect-err>   A logical block opening on the line
   expect-err>
   expect-err>
.*Tests/RunCMake/message/message-internal-warning.cmake:4 \(macro\)
   expect-err>
   expect-err>   closes on the line
   expect-err>
   expect-err>
.*Tests/RunCMake/message/message-internal-warning.cmake:5 \(endmacro\)
   expect-err>
   expect-err>   with mis-matching arguments.
   expect-err> Call Stack \(most recent call first\):
   expect-err>   CMakeLists.txt:3 \(include\)
   expect-err> This warning is for project developers.  Use -Wno-dev
to suppress it.$

  Actual stderr:

   actual-err> CMake Warning (dev) in message-internal-warning.cmake:
   actual-err>   A logical block opening on the line
   actual-err>
   actual-err>
/home/daniel/Projects/CMake/Tests/RunCMake/message/message-internal-warning.cmake:4
(macro)
   actual-err>
   actual-err>   closes on the line
   actual-err>
   actual-err>
/home/daniel/Projects/CMake/Tests/RunCMake/message/message-internal-warning.cmake:5
(endmacro)
   actual-err>
   actual-err>   with mis-matching arguments.
   actual-err> Call Stack (most recent call first):
   actual-err>   CMakeLists.txt:3 (include)
   actual-err> This warning is for project developers.  Use -Wno-dev
to suppress it.


I assume the actual stderr is preferred and the expectation should be
changed. The mismatch is between line 4 and 5. It does not seem useful
to report an error in line 3.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Review request: extract-cmMessenger branch

[Daniel Pfeifer]

On Thu, Jan 28, 2016 at 10:42 PM, Stephen Kelly  wrote:
>
> Hi,
>
> I have pushed a extract-cmMessenger branch to my clone:
>
>  https://github.com/steveire/CMake/commits/extract-cmMessenger

I have rebased it to master and cherry-picked some minor changes.
Once those minor changes land in master, I will rebase again and then
have a closer look at the individual commits.

> The motivations are:
>
> * Decrease responsibilities of the cmake class. CMake uses too few
> classes for too many things

+1

> * Make it possible to make add first-class handling of messages about
> missing packages (for example) to cmake-gui by making methods on
> cmMessenger virtual and subclassing

That sounds useful. But long term, I would rather base ccmake and
cmake-gui on top of the daemon.

What I would like to have, is separate subclasses for gcc-style and
msvc-style messages. In gcc-style, messages look like this:

:row:column: error: 

In msvc-style, messages look like this:

(row,column): error: 

This would make it easier to jump to the location in IDEs (and
powerful editors).

> * Make it possible to emit messages through the daemon (also by
> subclassing) together with backtrace and message type, relieving clients
> from having to parse the text.

+1

> I'm interested in what you think of the approach.

Very useful overall. I'll write more once I had a closer look.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon-mode

[Daniel Pfeifer]

On Mon, Jun 6, 2016 at 7:24 PM, Brad King  wrote:
> On 06/06/2016 11:39 AM, Tobias Hunger wrote:
>
>> A big chunk of Stephen's work has not even landed in my branch yet. Since 
>> cmake
>> reformated all the source in the meantime it is a bit tedious to apply 
>> patches
>> from his tree and I have simply not yet needed the changes as I did not 
>> venture
>> where he went yet.
>
> See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
> how to rebase across the style transition.  If you rebase the original
> "cmake-daemon" branch on that then we can rewrite the style to make
> cherry-picking later easier.

When I rebased my own branches across the style transiton, I found the
process quite straight forward.
I can help with the style transition if someone rebases to 82df6deaaf.

When I tried to rebase steve's work, it was not the style transition
but changes like the following that I struggled with:
https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon-mode

[Daniel Pfeifer]

On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hunger  wrote:
> Please help to support your use-cases.

A while ago I wrote a graphical cache editor in GTK:
https://github.com/purpleKarrot/cmake-gtk
The tool reads the cache and provides a graphical view to modify it.
It can then write the cache, run cmake, and read it back.

I wanted to see how close we can get to ccmake or cmake-gui without
linking against CMakeLib.

Here is what I was *unable* to achieve:
* Separating Configure from Generate (two buttons).
* Progress bar.

Quite a short list, right?
If we have a daemon mode that provides this information (as your
implementation already does), we could let ccmake and cmake-gui use
the daemon instead of linking against CMakeLib.

cheers, Daniel

> Please report what information you would like to have available from your 
> cmake
> projects via daemon-mode.
>
> Patches are of course welcome at any time!
>
> Any help in getting any interesting information out of cmake is highly
> appreciated, too.
>
> At this time I think I will need to duplicate a chunk of code from one of the
> generators to find the flags. Is that really necessary? If so: Which generator
> should I copy the code from?
>
> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
> B
> --
>
> 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
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Daniel Pfeifer]

On Sun, Jun 5, 2016 at 2:15 PM, Stephen Kelly <steve...@gmail.com> wrote:
> On 05/19/2016 11:27 PM, Daniel Pfeifer wrote:
>> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly <steve...@gmail.com> wrote:
>>> 1) Make cmLocalGenerator not inherit cmOutputConverter
>>> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>>>
>>>https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298
>>>
>>>   for a similar sed command to achieve this.
>>>
>>> * Remove inheritance. Implement Convert() methods in cmLocalGenerator for
>>>   source compatibility which instantiate and use a cmOutputConverter as in
>>>
>>>https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad
>> That may change behavior because the LinkScriptShell member may have
>> the wrong value.
>> I am currently digging deeper.
>
> Yes, that looks like it requires deeper digging.
>
> In commit v3.3.0-rc1~29^2~1 (cmState: Host some state from the
> cmGlobalGenerator., 2015-05-24) I moved other things which are used by
> Convert() APIs to cmState, but the LinkScriptShell didn't seem to belong
> there.
>
> I was hoping the callers which need LinkScriptShell would manage that
> state themselves somehow, but it would take some deep digging and
> probably refactoring of the makefile generator to do that.
>
> Did your digging turn anything up?

Here is what I found.

* GetFortranFormat is called with an object, even though it is a
static member function. (That is easy to refactor.)
* SetLinkScriptShell is called from two places:
cmMakefileExecutableTargetGenerator::WriteExecutableRule and
cmMakefileLibraryTargetGenerator::WriteLibraryRules.
* We can instantiate a cmOutputConverter in those places and then pass
it along the call tree in all branches that contain calls to Convert.
* Doxygen's call-graphs and caller-graphs are not reliable. Doxygen
sometimes lies.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Some trivial patches

[Daniel Pfeifer]

On Thu, Jun 2, 2016 at 11:15 AM, Tobias Hunger  wrote:
> On Mi, 2016-06-01 at 11:18 -0400, Brad King wrote:
>> On 06/01/2016 05:04 AM, Tobias Hunger wrote:
>> > Attached you will find a couple of really small changes that add const to a
>> > method and fix a couple of typos in comments. Trivial stuff.
>>
>> Thanks.  I've applied the changes:
>>
>>  cmSearchPath: Fix typo in comment
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774e
>>
>>  cmSourceFileLocation: Fix typo in comment
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef64
>>
>>  cmGlobalGenerator: Make IsMultiConfig() const
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bf
>>
>> > This is mostly to figure out how to contribute code:-)
>>
>> Good job.  For large changes (e.g. cmake-daemon work) feel free
>> to publish your branch somewhere and post a link here.  For most
>> changes please post here.
>
> Why did the typo fixes end up in the master branch and the const fix in the 
> next
> branch?

Because of the code freeze for CMake 3.6:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16479

> Do I need to do something to get it from next to master at some point?

No.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] fixup! Simplify boolean expressions

[Daniel Pfeifer]

My "Simplify boolean expressions" refactoring caused  C4800 warnings
for MSVC builds. A fixup is attached, as I cannot ssh at the moment.
From ece15fe51c46cb93823ccd8a54243d35ebdc0d3c Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Thu, 2 Jun 2016 09:59:36 +0200
Subject: [PATCH] fixup! Simplify boolean expressions

---
 Source/cmDependsFortran.cxx  | 3 +--
 Source/cmELF.cxx | 6 +++---
 Source/cmGeneratedFileStream.cxx | 4 ++--
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/Source/cmDependsFortran.cxx b/Source/cmDependsFortran.cxx
index f7db417..a20fb98 100644
--- a/Source/cmDependsFortran.cxx
+++ b/Source/cmDependsFortran.cxx
@@ -654,8 +654,7 @@ bool cmDependsFortran::ModulesDiffer(const char* modFile,
 // but also do not include a date so we can fall through to
 // compare them without skipping any prefix.
 unsigned char hdr[2];
-finModFile.read(reinterpret_cast<char*>(hdr), 2);
-bool okay = static_cast(finModFile);
+bool okay = !finModFile.read(reinterpret_cast<char*>(hdr), 2).fail();
 finModFile.seekg(0);
 if (!okay || hdr[0] != 0x1f || hdr[1] != 0x8b) {
   const char seq[1] = { '\n' };
diff --git a/Source/cmELF.cxx b/Source/cmELF.cxx
index db32184..c7f8a2d 100644
--- a/Source/cmELF.cxx
+++ b/Source/cmELF.cxx
@@ -143,7 +143,7 @@ public:
   {
 this->Stream.seekg(pos);
 this->Stream.read(buf, size);
-return static_cast(this->Stream);
+return !this->Stream.fail();
   }
 
   // Lookup the SONAME in the DYNAMIC section.
@@ -497,7 +497,7 @@ private:
 this->NeedSwap) {
   ByteSwap(x);
 }
-return static_cast(this->Stream);
+return !this->Stream.fail();
   }
   bool Read(ELF_Dyn& x)
   {
@@ -505,7 +505,7 @@ private:
 this->NeedSwap) {
   ByteSwap(x);
 }
-return static_cast(this->Stream);
+return !this->Stream.fail();
   }
 
   bool LoadSectionHeader(ELF_Half i)
diff --git a/Source/cmGeneratedFileStream.cxx b/Source/cmGeneratedFileStream.cxx
index 562ff88..dee174b 100644
--- a/Source/cmGeneratedFileStream.cxx
+++ b/Source/cmGeneratedFileStream.cxx
@@ -42,7 +42,7 @@ cmGeneratedFileStream::~cmGeneratedFileStream()
   // stream will be destroyed which will close the temporary file.
   // Finally the base destructor will be called to replace the
   // destination file.
-  this->Okay = static_cast(*this);
+  this->Okay = !this->fail();
 }
 
 cmGeneratedFileStream& cmGeneratedFileStream::Open(const char* name,
@@ -71,7 +71,7 @@ cmGeneratedFileStream& cmGeneratedFileStream::Open(const char* name,
 bool cmGeneratedFileStream::Close()
 {
   // Save whether the temporary output file is valid before closing.
-  this->Okay = static_cast(*this);
+  this->Okay = !this->fail();
 
   // Close the temporary output file.
   this->Stream::close();
-- 
2.8.3

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Daniel Pfeifer]

On Thu, May 19, 2016 at 11:18 PM Daniel Pfeifer <dan...@pfeifer-mail.de>
wrote:

> On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly <steve...@gmail.com> wrote:
>
>> 1) Make cmLocalGenerator not inherit cmOutputConverter
>> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>
>
> Please see attached patch.
>

Revised patch attached. Please ignore the previous one.
This one also fully qualifies the enums that were used unqualified.
From d955e4257faae1cd5b6a1fc300583d74dce6c061 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Thu, 19 May 2016 23:11:40 +0200
Subject: [PATCH] Use enums defined in cmOutputConverter using their fully
 qualified name.

Mostly automated:

values=("RelativeRoot" "NONE" "FULL" "HOME" "START" "HOME_OUTPUT" "START_OUTPUT"
"OutputFormat" "UNCHANGED" "MAKERULE" "SHELL" "WATCOMQUOTE" "RESPONSE"
"FortranFormat" "FortranFormatNone" "FortranFormatFixed" "FortranFormatFree")
for i in "${values[@]}"; do git grep -l cmLocalGenerator::$i | xargs sed -i "s|cmLocalGenerator::$i|cmOutputConverter::$i|g"; done
---
 Source/cmCommonTargetGenerator.cxx |  18 ++--
 Source/cmCommonTargetGenerator.h   |   4 +-
 Source/cmDependsC.cxx  |  10 +--
 Source/cmDependsFortran.cxx|  40 -
 Source/cmExtraEclipseCDT4Generator.cxx |   2 +-
 Source/cmGlobalGenerator.cxx   |   2 +-
 Source/cmGlobalNinjaGenerator.cxx  |  10 +--
 Source/cmGlobalUnixMakefileGenerator3.cxx  |  24 ++---
 Source/cmGlobalVisualStudio7Generator.cxx  |   2 +-
 Source/cmGlobalXCodeGenerator.cxx  |   8 +-
 Source/cmLocalGenerator.cxx|   2 +-
 Source/cmLocalGenerator.h  |  12 +--
 Source/cmLocalNinjaGenerator.cxx   |  27 +++---
 Source/cmLocalNinjaGenerator.h |  12 +--
 Source/cmLocalUnixMakefileGenerator3.cxx   | 106 --
 Source/cmLocalUnixMakefileGenerator3.h |  12 +--
 Source/cmLocalVisualStudio7Generator.cxx   |  41 +
 Source/cmMakefileExecutableTargetGenerator.cxx |  55 ++--
 Source/cmMakefileLibraryTargetGenerator.cxx|  84 +-
 Source/cmMakefileTargetGenerator.cxx   | 118 -
 Source/cmMakefileUtilityTargetGenerator.cxx|   4 +-
 Source/cmNinjaNormalTargetGenerator.cxx|  22 ++---
 Source/cmNinjaTargetGenerator.cxx  |  12 +--
 Source/cmNinjaUtilityTargetGenerator.cxx   |   4 +-
 Source/cmVisualStudio10TargetGenerator.cxx |   4 +-
 25 files changed, 333 insertions(+), 302 deletions(-)

diff --git a/Source/cmCommonTargetGenerator.cxx b/Source/cmCommonTargetGenerator.cxx
index 6b2d1e3..c630971 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -43,8 +43,8 @@ std::string const& cmCommonTargetGenerator::GetConfigName() const
 }
 
 std::string cmCommonTargetGenerator::Convert(
-  std::string const& source, cmLocalGenerator::RelativeRoot relative,
-  cmLocalGenerator::OutputFormat output)
+  std::string const& source, cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output)
 {
   return this->LocalGenerator->Convert(source, relative, output);
 }
@@ -140,7 +140,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
   std::string mod_dir = this->GetFortranModuleDirectory();
   if (!mod_dir.empty()) {
 mod_dir =
-  this->Convert(mod_dir, this->WorkingDirectory, cmLocalGenerator::SHELL);
+  this->Convert(mod_dir, this->WorkingDirectory, cmOutputConverter::SHELL);
   } else {
 mod_dir =
   this->Makefile->GetSafeDefinition("CMAKE_Fortran_MODDIR_DEFAULT");
@@ -167,7 +167,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
  idi != includes.end(); ++idi) {
   std::string flg = modpath_flag;
   flg +=
-this->Convert(*idi, cmLocalGenerator::NONE, cmLocalGenerator::SHELL);
+this->Convert(*idi, cmOutputConverter::NONE, cmOutputConverter::SHELL);
   this->LocalGenerator->AppendFlags(flags, flg);
 }
   }
@@ -177,18 +177,18 @@ void cmCommonTargetGenerator::AppendFortranFormatFlags(
   std::string& flags, cmSourceFile const& source)
 {
   const char* srcfmt = source.GetProperty("Fortran_FORMAT");
-  cmLocalGenerator::FortranFormat format =
+  cmOutputConverter::FortranFormat format =
 this->LocalGenerator->GetFortranFormat(srcfmt);
-  if (format == cmLocalGenerator::FortranFormatNone) {
+  if (format == cmOutputConverter::FortranFormatNone) {
 const char* tgtfmt = this->GeneratorTa

Re: [cmake-developers] Developer tasks - Refactoring

[Daniel Pfeifer]

On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly  wrote:
> 1) Make cmLocalGenerator not inherit cmOutputConverter
> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>
>https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298
>
>   for a similar sed command to achieve this.
>
> * Remove inheritance. Implement Convert() methods in cmLocalGenerator for
>   source compatibility which instantiate and use a cmOutputConverter as in
>
>https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad

That may change behavior because the LinkScriptShell member may have
the wrong value.
I am currently digging deeper.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Daniel Pfeifer]

On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly <steve...@gmail.com> wrote:

> 1) Make cmLocalGenerator not inherit cmOutputConverter
> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See


Please see attached patch.
From 9e1203308ad79d62b24fe6930501e1013b4e52ec Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Thu, 19 May 2016 23:11:40 +0200
Subject: [PATCH] Use enums defined in cmOutputConverter using their fully
 qualified name.

Mostly automated:

values=("RelativeRoot" "NONE" "FULL" "HOME" "START" "HOME_OUTPUT" "START_OUTPUT"
"OutputFormat" "UNCHANGED" "MAKERULE" "SHELL" "WATCOMQUOTE" "RESPONSE"
"FortranFormat" "FortranFormatNone" "FortranFormatFixed" "FortranFormatFree")
for i in "${values[@]}"; do git grep -l cmLocalGenerator::$i | xargs sed -i "s|cmLocalGenerator::$i|cmOutputConverter::$i|g"; done
---
 Source/cmCommonTargetGenerator.cxx |  18 ++--
 Source/cmCommonTargetGenerator.h   |   4 +-
 Source/cmDependsC.cxx  |  10 +--
 Source/cmDependsFortran.cxx|  40 -
 Source/cmExtraEclipseCDT4Generator.cxx |   2 +-
 Source/cmGlobalGenerator.cxx   |   2 +-
 Source/cmGlobalNinjaGenerator.cxx  |  10 +--
 Source/cmGlobalUnixMakefileGenerator3.cxx  |  24 ++---
 Source/cmGlobalVisualStudio7Generator.cxx  |   2 +-
 Source/cmGlobalXCodeGenerator.cxx  |   8 +-
 Source/cmLocalGenerator.cxx|   2 +-
 Source/cmLocalGenerator.h  |  12 +--
 Source/cmLocalUnixMakefileGenerator3.cxx   |  50 +--
 Source/cmLocalUnixMakefileGenerator3.h |   6 +-
 Source/cmLocalVisualStudio7Generator.cxx   |  16 ++--
 Source/cmMakefileExecutableTargetGenerator.cxx |  55 ++--
 Source/cmMakefileLibraryTargetGenerator.cxx|  84 +-
 Source/cmMakefileTargetGenerator.cxx   | 118 -
 Source/cmMakefileUtilityTargetGenerator.cxx|   4 +-
 Source/cmNinjaNormalTargetGenerator.cxx|  22 ++---
 Source/cmNinjaTargetGenerator.cxx  |  12 +--
 Source/cmNinjaUtilityTargetGenerator.cxx   |   4 +-
 Source/cmVisualStudio10TargetGenerator.cxx |   4 +-
 23 files changed, 257 insertions(+), 252 deletions(-)

diff --git a/Source/cmCommonTargetGenerator.cxx b/Source/cmCommonTargetGenerator.cxx
index 6b2d1e3..c630971 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -43,8 +43,8 @@ std::string const& cmCommonTargetGenerator::GetConfigName() const
 }
 
 std::string cmCommonTargetGenerator::Convert(
-  std::string const& source, cmLocalGenerator::RelativeRoot relative,
-  cmLocalGenerator::OutputFormat output)
+  std::string const& source, cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output)
 {
   return this->LocalGenerator->Convert(source, relative, output);
 }
@@ -140,7 +140,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
   std::string mod_dir = this->GetFortranModuleDirectory();
   if (!mod_dir.empty()) {
 mod_dir =
-  this->Convert(mod_dir, this->WorkingDirectory, cmLocalGenerator::SHELL);
+  this->Convert(mod_dir, this->WorkingDirectory, cmOutputConverter::SHELL);
   } else {
 mod_dir =
   this->Makefile->GetSafeDefinition("CMAKE_Fortran_MODDIR_DEFAULT");
@@ -167,7 +167,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
  idi != includes.end(); ++idi) {
   std::string flg = modpath_flag;
   flg +=
-this->Convert(*idi, cmLocalGenerator::NONE, cmLocalGenerator::SHELL);
+this->Convert(*idi, cmOutputConverter::NONE, cmOutputConverter::SHELL);
   this->LocalGenerator->AppendFlags(flags, flg);
 }
   }
@@ -177,18 +177,18 @@ void cmCommonTargetGenerator::AppendFortranFormatFlags(
   std::string& flags, cmSourceFile const& source)
 {
   const char* srcfmt = source.GetProperty("Fortran_FORMAT");
-  cmLocalGenerator::FortranFormat format =
+  cmOutputConverter::FortranFormat format =
 this->LocalGenerator->GetFortranFormat(srcfmt);
-  if (format == cmLocalGenerator::FortranFormatNone) {
+  if (format == cmOutputConverter::FortranFormatNone) {
 const char* tgtfmt = this->GeneratorTarget->GetProperty("Fortran_FORMAT");
 format = this->LocalGenerator->GetFortranFormat(tgtfmt);
   }
   const char* var = 0;
   switch (format) {
-case cmLocalGenerator::FortranFormatFixed:
+case cmOutputConverter::FortranFormatFixed:
   var = "CMAKE_Fortran_FORMAT_FIXED_FLAG";
   break;
-case cmLocalGenerator::FortranFormatFre

Re: [cmake-developers] [ANNOUNCE] CMake C++ coding style transition

[Daniel Pfeifer]

On Thu, May 12, 2016 at 7:58 AM, Brad King  wrote:
> Hi Folks,
>
> As discussed previously on the developer list:
>
>  Code style auto-formatting
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=15001
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=16307
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=16358
>
> we've decided to change the C++ coding style within CMake to use a
> more modern style that can be automatically formatted.  We chose a
> style defined by clang-format:
>
>  ---
>  # This configuration requires clang-format 3.8 or higher.
>  BasedOnStyle: Mozilla
>  AlignOperands: false
>  AlwaysBreakAfterReturnType: None
>  AlwaysBreakAfterDefinitionReturnType: None
>  ColumnLimit: 79
>  Standard: Cpp03
>  ...
>
> A simple example of the layout is:
>
>  bool foo(int a, int b)
>  {
>if (a < b) {
>  return true;
>} else {
>  return false;
>}
>  }

In a next step, we can use clang-tidy to clean up the above to:

bool foo(int a, int b)
{
  return a < b;
}

:-)
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Code style auto-formatting

[Daniel Pfeifer]

On Mon, May 9, 2016 at 11:14 AM, Brad King  wrote:
> On 05/02/2016 10:08 AM, Brad King wrote:
>> Next I'll look at the style updates themselves.
>
> I've made some more preparatory commits:
>
>  Isolate formatted streaming blocks with clang-format off/on
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=64b55203
>
>  Move comments off of class access specifier lines
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85425a3e
>
>  Help clang-format wrap after braces on long initializer lists
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afca3735
>
>  Remove `//--...` horizontal separator comments
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ac18d40
>
> These changes improve the formatting output in some local
> experiments.
>
> With the earlier changes to the #include order we no longer need
> to use any custom `IncludeCategories`.
>
> Here is the `.clang-format` file I'd like to use:
>
>   ---
>   # This configuration requires clang-format 3.8 or higher.
>   BasedOnStyle: Mozilla
>   AlignOperands: false
>   AllowShortFunctionsOnASingleLine: Inline
>   AlwaysBreakAfterReturnType: None
>   AlwaysBreakAfterDefinitionReturnType: None
>   ColumnLimit: 79
>   IndentCaseLabels: false
>   Standard: Cpp03
>   ...
>

"AllowShortFunctionsOnASingleLine: Inline" is default in the Mozilla
preset. This line can be removed.

What is your rationale for "IndentCaseLabels: false"? I find that
indenting them increases readability when switch statements use
hanging braces. If the opening "{" is on a separate line, indenting
the labels does not improve readability that much.

What is the rationale for "ColumnLimit: 79"? To make a line fit on old
school terminals, 80 should be OK. To make a diff or an email response
fit on old school terminals, two extra spaces are reserved. That leads
to a column limit of 78. Where does 79 come from?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Code style auto-formatting

[Daniel Pfeifer]

On Mon, May 9, 2016 at 11:31 AM, Rolf Eike Beer  wrote:
> Am Montag, 9. Mai 2016, 13:14:17 schrieb Brad King:
>> On 05/02/2016 10:08 AM, Brad King wrote:
>> > Next I'll look at the style updates themselves.
>>
>> I've made some more preparatory commits:
>
> […]
>>  Remove `//--...` horizontal separator comments
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ac18d40
>
> This one did not remove the additional newlines if there was a blank line
> before and after the marker.

This is not a problem. The empty lines will be removed by clang-format.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Integration of clang-tidy

[Daniel Pfeifer]

FYI: I have set up a dashboard build that shows the integration in
action: https://open.cdash.org/buildSummary.php?buildid=4349265

Most of the issues have fix-it hints which can be applied
automatically by clang-tidy.

On Thu, Apr 28, 2016 at 3:44 PM, Brad King <brad.k...@kitware.com> wrote:
> On 04/27/2016 06:48 PM, Daniel Pfeifer wrote:
>> It is unrelated. Clang-Tidy picks the interesting pieces from the
>> compiler command line and ignores the rest. Whether cc is given or not
>> makes no difference.
>> But maybe we should leave the decision what to pick to Clang-Tidy? It
>> may be clearer to forward the original command line unmodified.
>
> Applied, thanks!
>
>  Clang-Tidy: Give entire compiler command line to clant-tidy tool
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=304ab71d
>
> -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

Re: [cmake-developers] Code style auto-formatting

[Daniel Pfeifer]

On Thu, Nov 19, 2015 at 3:26 PM, Brad King <brad.k...@kitware.com> wrote:
> On 11/19/2015 09:22 AM, Robert Dailey wrote:
>> Tonight I will do some testing and submit a patch + example files
>> converted to the style Brad suggested. We can fine-tune it as needed.
>
> Rather than a patch please work on a script to perform the conversion.
> Then at any time we can choose to run the script as the one-shot conversion
> and commit as a robot user.  Any sweeping patch would be too big to
> post to the list anyway.  Ideally the script should be simple enough
> to cut-n-paste into a shell so we can just record it in the commit
> message.
>
> See this commit for an example of this approach:
>
>  https://cmake.org/gitweb?p=cmake.git;a=commit;h=7bbaa428

It took a while, but i figured out .clang-format definitions (there
are two required) and a script that, after applying, does not break
compilation and unit tests.

The .clang-format for the root directory looks like this:

---
BasedOnStyle: Mozilla
AlignAfterOpenBracket: false
AlignOperands: false
AllowShortFunctionsOnASingleLine: None
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
ColumnLimit: 79
ContinuationIndentWidth: 4
IncludeCategories:
 - Regex: 'cmStandardIncludes'
   Priority: -1
Standard: Cpp03
...

This is the script to perform the reformatting of most C/C++ source code:

git ls-files -z -- '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' \
| egrep -z -v '(Lexer|Parser|ParserHelper)\.' \
| egrep -z -v '^(Utilities/(KW|cm).*/|Source/(kwsys|CursesDialog/form)/)' \
| egrep -z -v '^Tests/Module/GenerateExportHeader' \
| egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' \
| xargs -0 clang-format -i

I have attached a patch that adds the .clang-format and two other
patches that need to be applied before reformatting.
I have pushed all those changes (including reformatting) to github:
https://github.com/purpleKarrot/CMake/commits/clang-format


Notes:

* Trying to reformat
Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h makes
clang-format crash.

* Clang-Format dedents preprocessor directives. See also:
https://llvm.org/bugs/show_bug.cgi?id=17362

* I did not include '*.in' files in the list, because Clang-Format
does strange things to @VARIALES@.


Please feel free to add/remove options from the .clang-format files.
IncludeCategories and Standard should stay as they are.

cheers, Daniel
From 452087a4b9f05742aed38040ab8d9b970fd05719 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Wed, 27 Apr 2016 22:47:02 +0200
Subject: [PATCH 1/3] CursesDialog: add missing cmState include

---
 Source/CursesDialog/cmCursesMainForm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Source/CursesDialog/cmCursesMainForm.h b/Source/CursesDialog/cmCursesMainForm.h
index 255c823..d194168 100644
--- a/Source/CursesDialog/cmCursesMainForm.h
+++ b/Source/CursesDialog/cmCursesMainForm.h
@@ -13,6 +13,7 @@
 #define cmCursesMainForm_h
 
 #include "../cmStandardIncludes.h"
+#include "../cmState.h"
 #include "cmCursesForm.h"
 #include "cmCursesStandardIncludes.h"
 
-- 
2.8.0

From de7ca8575286bf995a771f894bf5087698686482 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Wed, 27 Apr 2016 23:29:43 +0200
Subject: [PATCH 2/3] StringFileTest: add blank line between includes

This test generates a header file which is not self-contained.
Since Clang-Format reorders includes alphabetically, this makes the test
fail.  Add a blank line to introduce a logical separation between two
blocks of include files.
---
 Tests/StringFileTest/StringFile.cxx | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Tests/StringFileTest/StringFile.cxx b/Tests/StringFileTest/StringFile.cxx
index 9eba6bf..073e30c 100644
--- a/Tests/StringFileTest/StringFile.cxx
+++ b/Tests/StringFileTest/StringFile.cxx
@@ -1,5 +1,6 @@
 #include 
 #include 
+
 #include "OutputFile.h"
 
 int main(int, char*[])
-- 
2.8.0

From 8feb2d2efc1287048ca66305db222bb197dcba4d Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Wed, 27 Apr 2016 20:31:23 +0200
Subject: [PATCH 3/3] add .clang-format configuration files

For most of the code, Standard must be set to Cpp03,
so that `A<A >` is not rewritten as `A<A>`.

For the code under Tests/CompileFeatures, Standard must be set to Cpp11,
so that `U"foo"` is not rewritten as `U "foo"`.

Priorize the "cmStandardIncludes.h" header,
so that it is always included first.
---
 .clang-format   | 14 ++
 Tests/CompileFeatures/.clang-format | 11 +++
 2 files changed, 25 insertions(+)
 create mode 100644 .clang-format
 create mode 100644 Tests/CompileFeatures/.clang-format

diff --git a/.clang-format b/.clang-format
new file mode 100644
index 000..4076bcd
--- /d

Re: [cmake-developers] Integration of clang-tidy

[Daniel Pfeifer]

On Wed, Apr 27, 2016 at 3:10 PM, Brad King <brad.k...@kitware.com> wrote:
> On 04/26/2016 05:32 PM, Daniel Pfeifer wrote:
>> This is a follow up patch:
>
> Thanks.
>
>> -tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin()+1, orig_cmd.end());
>> +tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin(), orig_cmd.end());
>
> What is the purpose of this hunk?  Does clang-tidy expect to be
> given the full compiler command line including "cc"?  This does
> not look related to the change described in the commit message.

It is unrelated. Clang-Tidy picks the interesting pieces from the
compiler command line and ignores the rest. Whether cc is given or not
makes no difference.
But maybe we should leave the decision what to pick to Clang-Tidy? It
may be clearer to forward the original command line unmodified.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Integration of clang-tidy

[Daniel Pfeifer]

On Wed, Apr 27, 2016 at 10:47 PM, Gregor Jasny <gja...@googlemail.com> wrote:
> Hallo Daniel,
>
> On 09/04/16 00:31, Daniel Pfeifer wrote:
>> I implemented the integration of `clang-tidy` along the lines of the
>> `include-what-you-use` integration.
>> There is a new `_CLANG_TIDY` target property that is initialized
>> with the value of the `CMAKE__CLANG_TIDY` variable.
>> It contains the command line for `clang-tidy` as a ;-list.
>
> I'm wondering what's the advantage of having this built-in support for
> clang tidy over using the generated compile command database instead?

The compile command database is just this: a database of compile
commands. It does not execute clang-tidy at all. To execute clang-tidy
for all source files that are listed in the database, you need a
separate tool.
There is this one, which requires Python:
https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py

Having this functionality built into CMake means:

* No additional dependencies.
* Warning messages inside your IDE.
* Warning messages on CDash.

Since clang-tidy is executed directly before the compiler for each
individual source file, you may set CMAKE_CXX_CLANG_TIDY to
"clang-tidy;-fix-errors" and successfully compile invalid code. :-)
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Integration of clang-tidy

[Daniel Pfeifer]

On Mon, Apr 11, 2016 at 5:26 PM, Brad King <brad.k...@kitware.com> wrote:
> On 04/08/2016 06:31 PM, Daniel Pfeifer wrote:
>> I implemented the integration of `clang-tidy` along the lines of the
>> `include-what-you-use` integration.
>> There is a new `_CLANG_TIDY` target property that is initialized
>> with the value of the `CMAKE__CLANG_TIDY` variable.
>> It contains the command line for `clang-tidy` as a ;-list.
>
> Nice.  The patch is very complete.  Applied:
>
>  Add options to run clang-tidy with the compiler
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2db0170

This is a follow up patch:

Clang-Tidy writes the number of warnings, the number of suppressed
warnings, and instructions on how to suppress warnings to stderr.  Since
each source file is checked individually, this repetitive information is
disturbing and should be suppressed.

The actual warning messages are written to stdout.  Some IDEs (eg.
QtCreator) analyze only stderr for issues.  Redirecting Clang-Tidy's
stdout to stderr makes sure the warnings are correctly displayed.
From 53dc5b84eb6e39a6dac6eb8fab13dcf92d04ed35 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Tue, 26 Apr 2016 22:50:54 +0200
Subject: [PATCH] Clang-Tidy: copy stdout to sterr; ignore original stderr

Clang-Tidy writes the number of warnings, the number of suppressed
warnings, and instructions on how to suppress warnings to stderr.  Since
each source file is checked individually, this repetitive information is
disturbing and should be suppressed.

The actual warning messages are written to stdout.  Some IDEs (eg.
QtCreator) analyze only stderr for issues.  Redirecting Clang-Tidy's
stdout to stderr makes sure the warnings are correctly displayed.
---
 Source/cmcmd.cxx | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 3c28c35..e9edac4 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -387,15 +387,19 @@ int cmcmd::ExecuteCMakeCommand(std::vector& args)
 cmSystemTools::ExpandListArgument(tidy, tidy_cmd, true);
 tidy_cmd.push_back(sourceFile);
 tidy_cmd.push_back("--");
-tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin()+1, orig_cmd.end());
+tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin(), orig_cmd.end());
 
-// Run the tidy command line.
-if(!cmSystemTools::RunSingleCommand(tidy_cmd, 0, 0, , 0,
-cmSystemTools::OUTPUT_PASSTHROUGH))
+// Run the tidy command line.  Capture its stdout and hide its stderr.
+std::string stdOut;
+if(!cmSystemTools::RunSingleCommand(tidy_cmd, , 0, , 0,
+cmSystemTools::OUTPUT_NONE))
   {
   std::cerr << "Error running '" << tidy_cmd[0] << "'\n";
   return 1;
   }
+
+// Output the stdout from clang-tidy to stderr
+std::cerr << stdOut;
 }
 
   // Now run the real compiler command and return its result value.
-- 
2.8.0

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Integration of clang-tidy

[Daniel Pfeifer]

Hi,

I implemented the integration of `clang-tidy` along the lines of the
`include-what-you-use` integration.
There is a new `_CLANG_TIDY` target property that is initialized
with the value of the `CMAKE__CLANG_TIDY` variable.
It contains the command line for `clang-tidy` as a ;-list.

Example use:

$ cmake -DCMAKE_CXX_CLANG_TIDY:STRING="clang-tidy;-checks=-*,readability-*" ..
$ cmake --build .

It is also possible to let `clang-tidy` apply fixit hints directly:

$ cmake 
-DCMAKE_CXX_CLANG_TIDY:STRING="clang-tidy;-checks=-*,readability-redundant-string-cstr;-fix"
..

The output is recognized by CTest's diagnostic parser. I haven't
checked how they look on CDash.

cheers, Daniel
From c1996b295d2e49134b6f5ef2be690588e5bf2732 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Fri, 8 Apr 2016 22:09:27 +0200
Subject: [PATCH] Provide integration for clang-tidy

---
 Help/manual/cmake-properties.7.rst |  1 +
 Help/manual/cmake-variables.7.rst  |  1 +
 Help/prop_tgt/LANG_CLANG_TIDY.rst  | 13 
 Help/release/dev/clang-tidy.rst|  7 ++
 Help/variable/CMAKE_LANG_CLANG_TIDY.rst|  6 ++
 Source/cmMakefileTargetGenerator.cxx   | 19 -
 Source/cmNinjaTargetGenerator.cxx  | 18 -
 Source/cmTarget.cxx|  2 +
 Source/cmcmd.cxx   | 80 --
 Tests/RunCMake/CMakeLists.txt  |  2 +
 Tests/RunCMake/ClangTidy/C-Build-stdout.txt|  1 +
 Tests/RunCMake/ClangTidy/C-launch-Build-stdout.txt |  1 +
 Tests/RunCMake/ClangTidy/C-launch.cmake|  3 +
 Tests/RunCMake/ClangTidy/C.cmake   |  3 +
 Tests/RunCMake/ClangTidy/CMakeLists.txt|  3 +
 Tests/RunCMake/ClangTidy/CXX-Build-stdout.txt  |  1 +
 .../RunCMake/ClangTidy/CXX-launch-Build-stdout.txt |  1 +
 Tests/RunCMake/ClangTidy/CXX-launch.cmake  |  3 +
 Tests/RunCMake/ClangTidy/CXX.cmake |  3 +
 Tests/RunCMake/ClangTidy/RunCMakeTest.cmake| 22 ++
 Tests/RunCMake/ClangTidy/main.c|  1 +
 Tests/RunCMake/ClangTidy/main.cxx  |  1 +
 Tests/RunCMake/pseudo_tidy.c   | 16 +
 23 files changed, 181 insertions(+), 27 deletions(-)
 create mode 100644 Help/prop_tgt/LANG_CLANG_TIDY.rst
 create mode 100644 Help/release/dev/clang-tidy.rst
 create mode 100644 Help/variable/CMAKE_LANG_CLANG_TIDY.rst
 create mode 100644 Tests/RunCMake/ClangTidy/C-Build-stdout.txt
 create mode 100644 Tests/RunCMake/ClangTidy/C-launch-Build-stdout.txt
 create mode 100644 Tests/RunCMake/ClangTidy/C-launch.cmake
 create mode 100644 Tests/RunCMake/ClangTidy/C.cmake
 create mode 100644 Tests/RunCMake/ClangTidy/CMakeLists.txt
 create mode 100644 Tests/RunCMake/ClangTidy/CXX-Build-stdout.txt
 create mode 100644 Tests/RunCMake/ClangTidy/CXX-launch-Build-stdout.txt
 create mode 100644 Tests/RunCMake/ClangTidy/CXX-launch.cmake
 create mode 100644 Tests/RunCMake/ClangTidy/CXX.cmake
 create mode 100644 Tests/RunCMake/ClangTidy/RunCMakeTest.cmake
 create mode 100644 Tests/RunCMake/ClangTidy/main.c
 create mode 100644 Tests/RunCMake/ClangTidy/main.cxx
 create mode 100644 Tests/RunCMake/pseudo_tidy.c

diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst
index 73d1142..3403dcd 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -197,6 +197,7 @@ Properties on Targets
/prop_tgt/JOB_POOL_COMPILE
/prop_tgt/JOB_POOL_LINK
/prop_tgt/LABELS
+   /prop_tgt/LANG_CLANG_TIDY
/prop_tgt/LANG_COMPILER_LAUNCHER
/prop_tgt/LANG_INCLUDE_WHAT_YOU_USE
/prop_tgt/LANG_VISIBILITY_PRESET
diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst
index 3f73b32..7cf3a3d 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -259,6 +259,7 @@ Variables that Control the Build
/variable/CMAKE_INSTALL_RPATH
/variable/CMAKE_INSTALL_RPATH_USE_LINK_PATH
/variable/CMAKE_IOS_INSTALL_COMBINED
+   /variable/CMAKE_LANG_CLANG_TIDY
/variable/CMAKE_LANG_COMPILER_LAUNCHER
/variable/CMAKE_LANG_INCLUDE_WHAT_YOU_USE
/variable/CMAKE_LANG_VISIBILITY_PRESET
diff --git a/Help/prop_tgt/LANG_CLANG_TIDY.rst b/Help/prop_tgt/LANG_CLANG_TIDY.rst
new file mode 100644
index 000..2887e23
--- /dev/null
+++ b/Help/prop_tgt/LANG_CLANG_TIDY.rst
@@ -0,0 +1,13 @@
+_CLANG_TIDY
+-
+
+This property is implemented only when  is ``C`` or ``CXX``.
+
+Specify a :ref:`;-list ` containing a command
+line for the ``clang-tidy`` tool.  The :ref:`Makefile Generators`
+and the :generator:`Ninja` generator will run this tool along with the
+compiler and report a warning if the tool reports any problems.
+
+This property is initialized by the value of
+the :variable:`CMAKE__CLANG_TIDY` variable if it is set
+when a tar

Re: [cmake-developers] more use of cmXMLWriter

[Daniel Pfeifer]

On Mon, Mar 21, 2016 at 3:39 PM Brad King <brad.k...@kitware.com> wrote:

> On 03/19/2016 05:08 PM, Daniel Pfeifer wrote:
> > I ported some more generators to cmXMLWriter.
>
> Thanks.  I've applied and merged to 'next' for testing:
>
> cmXMLWriter: overload Element() method for empty elements
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd27e313
>
> cmXMLWriter: add Doctype() method
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7407621
>
> cmExtraCodeBlocksGenerator: port to cmXMLWriter
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27e09764
>
> cmExtraCodeLiteGenerator: port to cmXMLWriter
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dcdc270e
>
> cmGlobalKdevelopGenerator: port to cmXMLWriter
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfd8b4d3


Oops, I saw this one failed the dashboard build. A fixup is attached.
Sorry for the noise.


> cmExtraEclipseCDT4Generator: port to cmXMLWriter
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9908f705
>
> CPack/IFW: port to cmXMLWriter
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8356001
>
> -Brad
>
From 3f5cb27c09719216c707ff6fdc68254ca4780260 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Tue, 22 Mar 2016 15:27:11 +0100
Subject: [PATCH] fixup: cmGlobalKdevelopGenerator: port to cmXMLWriter

---
 Source/cmGlobalKdevelopGenerator.cxx | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Source/cmGlobalKdevelopGenerator.cxx b/Source/cmGlobalKdevelopGenerator.cxx
index 3179625..b4f7670 100644
--- a/Source/cmGlobalKdevelopGenerator.cxx
+++ b/Source/cmGlobalKdevelopGenerator.cxx
@@ -665,9 +665,9 @@ void cmGlobalKdevelopGenerator
   sesxml.StartElement("View0");
   sesxml.Attribute("line", 0);
   sesxml.Attribute("Type", "Source");
-  xml.EndElement(); // View0
+  sesxml.EndElement(); // View0
 
-  xml.EndElement(); // Doc0
-  xml.EndElement(); // DocsAndViews
-  xml.EndElement(); // KDevPrjSession;
+  sesxml.EndElement(); // Doc0
+  sesxml.EndElement(); // DocsAndViews
+  sesxml.EndElement(); // KDevPrjSession;
 }
-- 
2.7.4

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon for user tools

[Daniel Pfeifer]

On Wed, Jan 20, 2016 at 10:03 PM, Stephen Kelly  wrote:
> Milian Wolff wrote:
>
>>> I'm concerned that the memory usage of a daemon implementing the proposed
>>> capabilities may be too large to be practical (at least without a major
>>> redesign of certain structures that tend to duplicate substrings, or
>>> some kind of out-of-core approach).
>>
>> This sounds like optimizations to that daemon will benefit CMake.
>
> FYI I merged a reduce-allocations branch to next for testing. It came from
> Milian here:
>
>  https://github.com/steveire/CMake/pull/1

Very nice! It is impressive what kind of an impact a simple 'const&'
can have. Also, nice work identifying the hotspots.

> Milian also mentioned the possibility of using something like a sqlite
> database (probably what you meant by out-of-core above) for definitions for
> querying by the daemon.
>
> I also mentioned some possibile optimization possibilities, such as removing
> the closure of definitions created for all directories. I wrote a branch
> which does that some months ago, but it resulted in a slow down. I'll see if
> I can rebase the commit to master and push it to github, together with a
> patch for avoiding computing the hash multiple times in cmDefinitions.

What do you think about string interning? I started a cmString class
[2] that stores short strings inplace and puts long strings into a
pool. Copies never allocate extra memory and equality comparison is
always O(1).
In addition to `operator<` (which is lexicographical) there is a O(1)
comparison that can be used where lexicographical ordering is not
required (ie. for lookup tables).

[1] https://en.wikipedia.org/wiki/String_interning
[2] https://github.com/purpleKarrot/CMake/commits/string-pool

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Profile Cmake scripts

[Daniel Pfeifer]

On Tue, Jan 5, 2016 at 9:18 AM, Bartosz Kosiorek <gan...@poczta.onet.pl> wrote:
>
> Hi Ben.
>
> 2016-01-04 17:39 GMT+01:00 Ben Boeckel <ben.boec...@kitware.com>:
>>
>> The
>> big remaining problem is passing char* as an argument where functions do
>> std::string(arg) right away. I fixed all of those which did explicit
>> std::string conversions (via assignment or otherwise), but those which
>> are conditional should get std::string overloads to avoid a
>> malloc/copy/free penalty. There is a *lot* of work here though. The
>> branch I had been working on (which is now woefully out-of-date) is 100
>> commits long.

This improvement should be semi-automated with clang-tidy. We have
many functions that take `const char*` and are called by passing a
`string.c_str()`. The function signature should be changed to `const
std::string&` manually, but changing all the call sites should be done
automatically (ideally by kwrobot, periodically, on multiple
platforms).

Here is how to run clang-tidy on projects built with CMake:

$ cd 
$ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
$ run-clang-tidy.py -p  -fix
-checks='-*,readability-redundant-string-cstr' /Source/

The run-clang-tidy.py script is here:
https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py
The `-fix` argument tells clang-tidy to fix the violations inplace.
Without this argument the diagnostics are just printed.

I wanted to demonstrage the ability of the `redundant-string-cstr`
checker, but apparently there are no violations found.
I have attached a patch that was generated by the
`container-size-empty` checker.
Please don't apply it. Such changes should be performed by kwrobot.

You can output all possible checks with:

$ clang-tidy -p  -checks='*' -list-checks 

> That's great news.
> What is the branch name/link to these improvement?
> Is it possible to push these improvements partially?
>
> Maybe CMake community could continue working on that improvement?
> It will be great to create ticket, in which propose solution will be
> described.
>
> BTW: Do you know why the Xcode and MS Visual Studio is slower than CMake one
> ?
>
> Here is the benchmarks for my internal project:
>
> Xcode generation:
>real 6m31.733s
>user 4m51.862s
>sys 0m20.268s
>
> Make generation:
>real 4m45.089s
>user 2m56.117s
>sys 0m17.481s
>
> Ninja generation:
>   real 2m48.585s
>   user 2m30.712s
>   sys 0m6.313s

Generators for Xcode and Visual Studio have to generate more files.
From 46a5639a27bab0b227b457e1224c702dd143af33 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer <dan...@pfeifer-mail.de>
Date: Tue, 5 Jan 2016 13:28:16 +0100
Subject: [PATCH] demonstrate clang-tidy

---
 Source/CTest/cmCTestRunTest.cxx | 4 ++--
 Source/CTest/cmCTestTestHandler.cxx | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Source/CTest/cmCTestRunTest.cxx b/Source/CTest/cmCTestRunTest.cxx
index d108592..87e9f62 100644
--- a/Source/CTest/cmCTestRunTest.cxx
+++ b/Source/CTest/cmCTestRunTest.cxx
@@ -207,7 +207,7 @@ bool cmCTestRunTest::EndTest(size_t completed, size_t total, bool started)
 {
 bool success =
   !forceFail &&  (retVal == 0 ||
-  this->TestProperties->RequiredRegularExpressions.size());
+  !this->TestProperties->RequiredRegularExpressions.empty());
 if(this->TestProperties->SkipReturnCode >= 0
   && this->TestProperties->SkipReturnCode == retVal)
   {
@@ -584,7 +584,7 @@ void cmCTestRunTest::ComputeArguments()
  << std::endl);
 
   // Print any test-specific env vars in verbose mode
-  if (this->TestProperties->Environment.size())
+  if (!this->TestProperties->Environment.empty())
 {
 cmCTestLog(this->CTest, HANDLER_VERBOSE_OUTPUT, this->Index << ": "
<< "Environment variables: " << std::endl);
diff --git a/Source/CTest/cmCTestTestHandler.cxx b/Source/CTest/cmCTestTestHandler.cxx
index a8f983f..df91ac5 100644
--- a/Source/CTest/cmCTestTestHandler.cxx
+++ b/Source/CTest/cmCTestTestHandler.cxx
@@ -1318,7 +1318,7 @@ void cmCTestTestHandler::AttachFiles(cmXMLWriter& xml,
  cmCTestTestResult* result)
 {
   if(result->Status != cmCTestTestHandler::COMPLETED
- && result->Properties->AttachOnFail.size())
+ && !result->Properties->AttachOnFail.empty())
 {
 result->Properties->AttachedFiles.insert(
   result->Properties->AttachedFiles.end(),
-- 
2.6.4

-- 

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 o

Re: [cmake-developers] Restriction on target types for GraphViz dependency graph generation

[Daniel Pfeifer]

On Wed, Dec 16, 2015 at 5:20 AM, Andrey Mishchenko  wrote:
> Hi,
>
> I noticed that the automatic dependency graph generation in CMake targeting
> GraphViz only considers targets of certain types. In particular, it only
> adds nodes for executables and shared, static, and module libraries.
>
> Is this deliberate?

There are open issues about that:

https://cmake.org/Bug/view.php?id=13809
https://cmake.org/Bug/view.php?id=15636
https://cmake.org/Bug/view.php?id=15638

> If I submit a patch extending this functionality to (optionally, via
> configuration variables) work with more target types, would it be received
> well?

Absolutely. Thanks for working on this!

-- Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[Daniel Pfeifer]

> On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
>>
>> My working branch is here:
>> https://github.com/purpleKarrot/CMake/commits/pch
>>
>> Feel free to comment, evaluate, contribute.
>>
>> I am nut fully decided regarding these two questions:
>> - Do we want to support different pch per CONFIG? I think no, but I
>> might be wrong.
>> - Do we want to support different pch per LANGUAGE? I first thought
>> yes, but I am no longer certain about that.

On Fri, Dec 4, 2015 at 2:42 PM, David Cole <dlrd...@aol.com> wrote:
> With Visual Studio, you definitely **need** separate pch for each CONFIG.
> Every pch is going to include headers which have Debug/Release differences
> in them, and it is not safe to mix and match compiler output from separate
> configs together.

Maybe we are confusing two things here.

Visual Studio compiles a pch-binary for each configuration. That
pch-binary is probably incompatible with other configurations.
In my current implementation, the header file that is used to compile
the pch-binary is generated by CMake, using information provided by
the user.

This approach is very powerful, as it supports usage requirements. See
here for an example:
You can see here:
https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt

My question actually boils down to whether CMake should
(a) generate a header file for each configuration/language, or
(b) generate a **single** header file which is then precompiled for
all configurations/languages.

Both approaches are possible, because we can use #ifdef __cplusplus etc.

More importantly: Do we want the user to
(c) tell CMake about different headers-to-be-precompiled per
config/language so CMake can write the appropriate #ifdefs into the
generated file, or
(d) put #ifdefs into the provided file so that CMake can #include it
in the generated file without any additional logic?

Again both approaches are technically possible. It is not about what
we **need**, but what we **want**. And there, I am undecided.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[Daniel Pfeifer]

On Fri, Dec 4, 2015 at 9:19 PM, David Cole  wrote:
> Right, I was talking about the pch-binary.
>
> Why would CMake even need to generate a header file for pre-compiled
> headers? Why not just allow the user to say which of his header files
> should be the one to use for precompiled headers?

Generating a header file is necessary for two reasons:

1. In GCC, the compiled pch-binary has to be located in the same
directory as the pch-source header. For out-of-source-builds, we
certainly do not want to clutter the source directory, so we need a
header file inside the binary directory. We could create a copy
(fragile), a symlink (not portable), or a forward-#include
(preferred).

2. There can be only one pch per target. See below.

> I have a project I work on which is a VS-only non-CMake based project,
> where we name the pch input header files as "${libraryName}PCH.h" and
> anything we want included in the pch-binary we can just add to that
> file.
>
> Personally, I would prefer to have a manually edited file as the input
> to precompiled header so I can add whatever I want in there.

That is perfectly reasonable. This is also the reason why I think the
config/language specific differences should **not** be handled by
CMake, but by the user.

> What would be in the contents of the generated header? How do you know
> how much or how little is reasonable to put in there? Seems like a
> per-library / per-project sort of decision.

If you look at the example I referred to, there is a library `foo`
with a pch `foo.h` as a usage requirement. There is also an interface
library `bar` with a pch `bar.h` as a usage requirement. Then there is
an executable `foobar` which links against both `foo` and bar`. So the
generated pch-source for the `foobar` target will contain:


/* This file is generated by CMake */
#include 
#include 


Making sense?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[Daniel Pfeifer]

On Fri, Dec 4, 2015 at 11:32 PM, David Cole  wrote:
> Makes sense.
>
> Can I inject my own "#include " into
> the generated stream, or otherwise inject something into it?

You should be able to do:

target_include_directories(your_target
  PUBLIC public
  PRIVATE private
  )
target_precompile_headers(your_target
  PUBLIC
public_header1.h
public_header2.h
  PRIVATE
private_header1.h
private_header2.h
  )

Does that answer your question? Do you think this could solve your use-case?

> Specifically, for me, I want to include some, but not ALL VTK headers
> for a VTK-based project.

I don't see a problem for that.

> Thanks for working on this.

You are welcome. :-)

> Let me know if you want me to be a Visual Studio tester for you.

Yes, please. My main working environment is Linux. I appreciate any
feedback from different platforms.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Code style auto-formatting

[Daniel Pfeifer]

On Tue, Nov 17, 2015 at 10:12 PM, Robert Dailey
 wrote:
> On Tue, Nov 17, 2015 at 6:57 AM, Paul Smith  wrote:
>> On Tue, 2015-11-17 at 08:14 +, Stuermer, Michael SP/HZA-ZSEP wrote:
>>> In short, there is no fully automated style checking. If someone would
>>> come up with a tool & configuration I would love to use this. So far I
>>> tested astyle and the C++ edition of ReSharper (unfortunately quite
>>> expensive).
>>
>> We've used uncrustify with excellent results in the past, FWIW.
>>
>> It is a major hassle though.  We did a complete code reformat with a
>> well-defined process, and then had all developers apply reformatting to
>> their personal branches using a particular set of steps to minimize the
>> insanity.
>>
>
> I'm willing to assist with a clang format file, I've worked with them
> in the past. This means contributions will likely come with multiple
> patch files, some containing only whitespace fixups per the clang
> format.
>
> How did you guys want to approach reformatting inconsistently
> formatted source files?

I would say: As a byproduct.

Adding a .clang-format file to CMake would be greatly appreciated. It
can be used to ensure that refactorings and new contributions follow
exactly the predefined style. However, changing existing code simply
because it does not match the style is something that should be
refused.

git-clang-format can fix the formatting of staged hunks without
changing the rest of the files.

-- Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[Daniel Pfeifer]

On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones
<tay...@braun-jones.org> wrote:
> What's the status of this PCH feature? Does it need testers? More design
> input? I'd love to see this feature in a future CMake release. Willing to
> help.

I haven't worked on it for quite some time as I currently don't have a
project which needs it.
But I agree that we should get it into CMake, even if it does not
support all generators yet.
Support for additional generators can be added successively.

I will rebase my branch to master on the weekend, ie port it to
cmGeneratorTarget.
Then you are free to help with review, testing, and additional generators.

Which generators are the most important for you?

-- Daniel

> Cheers,
> Taylor
>
> On Fri, Mar 20, 2015 at 3:56 PM, Daniel Pfeifer <dan...@pfeifer-mail.de>
> wrote:
>>
>> On Fri, Mar 20, 2015 at 6:35 PM, Amine Khaldi <amine.kha...@reactos.org>
>> wrote:
>> > Two requests please:
>> >
>> > * The option to use existing headers instead of autogenerated ones.
>>
>> That is an implementation detail. It should not make a difference
>> whether the precompiled header is used through your existing header or
>> through an autogenerated header that forward includes your existing
>> header. This forward inclusion is important at least for GCC: The
>> compiler searches for a .gch file in the same directory as the header
>> file. Since we do not want this .gch file to be generated in the
>> source directory for out-of-source builds, we need to put the header
>> file into the build directory.
>>
>> Did I misunderstand your request and you meant "use an existing
>> *precompiled* header", ie. provide a .pch or .gch file?
>> My approach currently does not support that. Please let me know if
>> that is what you meant.
>>
>> > * Implementing PCH support without additional targets. ReactOS already
>> > has like 1000+ targets, and we currently use PCH on almost all of them, so
>> > imagine if this official implementation doubles our targets number.
>>
>> I completely agree.
>>
>> One request that I can add:
>>
>> * It shall be visible in the IDE's settings that precompiled headers are
>> used.
>>
>> Cheers, Daniel
>> --
>>
>> 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
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CTest XML outputs unsafe content

[Daniel Pfeifer]

On Thu, Aug 27, 2015 at 3:34 PM, Brad King brad.k...@kitware.com wrote:
 On 08/27/2015 07:20 AM, Mathieu MARACHE wrote:
 I'm maintaining a CTest output parser for Bamboo. It was reported to me that
 CMake 3.3.1 produced parsing issues in my plugin. After digging into CMake
 source code, it seems that a bug was introduced with the replacement of
 direct use of cmXMLSafe and std::ostream in favor of cmXMLwriter.

 For reference, the changes were here:

  Merge topic 'ctest-xml-refactor'
  http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c24c231

 cmXMLWriter is, I assume wrongly, output Safe content without
 (quotes, etc.) escaping.

 The SafeContent method is for text inside an element like

  ElementContentHere/Element

 The SafeAttribute method is for text inside an element attribute

  Element attr=AttributeHere/

 The latter needs quotes to be encoded as quot; but the former
 does not:

  http://www.w3.org/TR/xml11/#syntax

 Have you found an attribute value that does not enocde quotes?

The proposed patch enables the encoding of quotes in content. This
does not seem correct to me.

I saw cmXMLSafe is used in some places inside CTest.
Since escaping is handled by cmXMLWriter, this may lead to some double
encodings.

I have attached two patches that remove all uses of cmXMLSafe from CTest.

-- Daniel
From 6a5962c671373f0c4e90080abc7b7fe7cf731f77 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer dan...@pfeifer-mail.de
Date: Thu, 16 Jul 2015 21:47:29 +0200
Subject: [PATCH 01/10] remove unused cmXMLSafe includes

---
 Source/CTest/cmCTestBZR.cxx| 1 -
 Source/CTest/cmCTestGIT.cxx| 1 -
 Source/CTest/cmCTestP4.cxx | 1 -
 Source/cmExtraKateGenerator.cxx| 1 -
 Source/cmExtraSublimeTextGenerator.cxx | 1 -
 5 files changed, 5 deletions(-)

diff --git a/Source/CTest/cmCTestBZR.cxx b/Source/CTest/cmCTestBZR.cxx
index 3014a93..587b583 100644
--- a/Source/CTest/cmCTestBZR.cxx
+++ b/Source/CTest/cmCTestBZR.cxx
@@ -14,7 +14,6 @@
 #include cmCTest.h
 #include cmSystemTools.h
 #include cmXMLParser.h
-#include cmXMLSafe.h
 
 #include cmsys/RegularExpression.hxx
 
diff --git a/Source/CTest/cmCTestGIT.cxx b/Source/CTest/cmCTestGIT.cxx
index 5b9208a..bbb3b9d 100644
--- a/Source/CTest/cmCTestGIT.cxx
+++ b/Source/CTest/cmCTestGIT.cxx
@@ -14,7 +14,6 @@
 #include cmCTest.h
 #include cmSystemTools.h
 #include cmAlgorithms.h
-#include cmXMLSafe.h
 
 #include cmsys/RegularExpression.hxx
 #include cmsys/Process.h
diff --git a/Source/CTest/cmCTestP4.cxx b/Source/CTest/cmCTestP4.cxx
index 5ce431a..5e0c54a 100644
--- a/Source/CTest/cmCTestP4.cxx
+++ b/Source/CTest/cmCTestP4.cxx
@@ -13,7 +13,6 @@
 
 #include cmCTest.h
 #include cmSystemTools.h
-#include cmXMLSafe.h
 
 #include cmsys/RegularExpression.hxx
 #include cmsys/Process.h
diff --git a/Source/cmExtraKateGenerator.cxx b/Source/cmExtraKateGenerator.cxx
index 578e7d3..f83b5cf 100644
--- a/Source/cmExtraKateGenerator.cxx
+++ b/Source/cmExtraKateGenerator.cxx
@@ -19,7 +19,6 @@
 #include cmGeneratedFileStream.h
 #include cmTarget.h
 #include cmSystemTools.h
-#include cmXMLSafe.h
 
 #include cmsys/SystemTools.hxx
 
diff --git a/Source/cmExtraSublimeTextGenerator.cxx b/Source/cmExtraSublimeTextGenerator.cxx
index 4e721d4..163a75b 100644
--- a/Source/cmExtraSublimeTextGenerator.cxx
+++ b/Source/cmExtraSublimeTextGenerator.cxx
@@ -21,7 +21,6 @@
 #include cmSourceFile.h
 #include cmSystemTools.h
 #include cmTarget.h
-#include cmXMLSafe.h
 
 #include cmsys/SystemTools.hxx
 
-- 
2.5.0

From 0e640887f75bb354674129bb743753fb2b6e64fc Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer dan...@pfeifer-mail.de
Date: Thu, 16 Jul 2015 21:48:00 +0200
Subject: [PATCH 02/10] remove all usage of cmXMLSafe from CTest escaping is
 handled by cmXMLWriter

---
 Source/CTest/cmCTestMemCheckHandler.cxx | 16 ++--
 Source/CTest/cmCTestTestHandler.cxx |  2 +-
 Source/cmCTest.cxx  |  5 +
 3 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/Source/CTest/cmCTestMemCheckHandler.cxx b/Source/CTest/cmCTestMemCheckHandler.cxx
index 8f26716..acf527a 100644
--- a/Source/CTest/cmCTestMemCheckHandler.cxx
+++ b/Source/CTest/cmCTestMemCheckHandler.cxx
@@ -80,8 +80,8 @@ public:
   int i = 0;
   for(; atts[i] != 0; i+=2)
 {
-ostr   cmXMLSafe(atts[i])
-   -   cmXMLSafe(atts[i+1])  \n;
+ostr   atts[i]
+   -   atts[i+1]  \n;
 }
   ostr  \n;
   this-Log += ostr.str();
@@ -856,7 +856,7 @@ bool cmCTestMemCheckHandler::ProcessMemCheckSanitizerOutput(
   defects++;
   ostr  b   this-ResultStrings[idx]  /b ;
   }
-ostr  cmXMLSafe(*i)  std::endl;
+ostr  *i  std::endl;
 }
   log = ostr.str();
   if(defects)
@@ -908,7 +908,7 @@ bool cmCTestMemCheckHandler::ProcessMemCheckPurifyOutput(
   results[failure] ++;
   defects ++;
   }
-ostr  cmXMLSafe(*i)  std::endl;
+ostr  *i  std::endl;
 }
 
   log = ostr.str();
@@ -1056,7 +1056,7

[cmake-developers] [PATCH] fixup: CTest-side support for compiler version

[Daniel Pfeifer]

Commit a5aa23 added support for reporting a compiler version to CDash
(but with a hardcoded version number: the version of the compiler that
was used to compile CMake).
From 594c46c8f25e520d0fad984a4a00c228132cdea1 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer dan...@pfeifer-mail.de
Date: Tue, 11 Aug 2015 09:52:51 +0200
Subject: [PATCH] fixup: CTest-side support for compiler version

Don't show the version of the compiler that was used to compile cmake.
This was broken since a5aa23.
---
 Modules/DartConfiguration.tcl.in | 1 +
 Source/cmCTest.cxx   | 5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Modules/DartConfiguration.tcl.in b/Modules/DartConfiguration.tcl.in
index 918b407..2da8354 100644
--- a/Modules/DartConfiguration.tcl.in
+++ b/Modules/DartConfiguration.tcl.in
@@ -69,6 +69,7 @@ UpdateType: @UPDATE_TYPE@
 
 # Compiler info
 Compiler: @CMAKE_CXX_COMPILER@
+CompilerVersion: @CMAKE_CXX_COMPILER_VERSION@
 
 # Dynamic analysis (MemCheck)
 PurifyCommand: @PURIFYCOMMAND@
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index f65bd29..b976469 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -1546,9 +1546,8 @@ void cmCTest::StartXML(cmXMLWriter xml, bool append)
 xml.Attribute(Append, true);
 }
   xml.Attribute(CompilerName, this-GetCTestConfiguration(Compiler));
-#ifdef _COMPILER_VERSION
-  xml.Attribute(CompilerVersion, _COMPILER_VERSION);
-#endif
+  xml.Attribute(CompilerVersion,
+this-GetCTestConfiguration(CompilerVersion));
   xml.Attribute(OSName, info.GetOSName());
   xml.Attribute(Hostname, info.GetHostname());
   xml.Attribute(OSRelease, info.GetOSRelease());
-- 
2.5.0

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] topic 'ctest-change-id'

[Daniel Pfeifer]

Hi,

The new element `ChangeId` is added to Build.xml and Test.xml.
Did you consider adding it as an attribute in `cmCTest::StartXML` instead?
That would make this (very useful) information available in all xml files.

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] PATCH: add subcommand string(APPEND)

[Daniel Pfeifer]

On Mon, Jul 6, 2015 at 8:41 PM, Brad King brad.k...@kitware.com wrote:
 On 07/04/2015 06:27 PM, Daniel Pfeifer wrote:
 Attached is a patch that adds a subcommand string(APPEND).
 This allows to write

 string(APPEND string_variable some string)

 instead of

 set(string_variable ${string_variable}some string)

 Thanks.  Please extend the first patch to also add explicit coverage
 of the feature in the test suite, perhaps in Tests/RunCMake/string
 similar to the Concat test case.  I'd prefer to get the implementation,
 documentation, and tests of the new command integrated and working
 before considering use of the command everywhere else.

OK, now with tests and release notes.

There is a debatable edge case:
When a variable is not-set and zero elements are appended, do we
expect the result to be a) not-set or b) an empty string?
My current implementation considers appending zero elements a no-op,
i.e. it follows approach a).

cheers, Daniel
From f257b6098443295d9874ddc02df298ecd70af34b Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer dan...@pfeifer-mail.de
Date: Mon, 6 Jul 2015 22:28:04 +0200
Subject: [PATCH] add subcommand string(APPEND)

---
 Help/command/string.rst   |  3 ++
 Help/release/dev/string-append.rst|  4 ++
 Source/cmStringCommand.cxx| 32 +++
 Source/cmStringCommand.h  |  1 +
 Tests/RunCMake/string/Append.cmake| 58 +++
 Tests/RunCMake/string/AppendNoArgs-result.txt |  1 +
 Tests/RunCMake/string/AppendNoArgs-stderr.txt |  4 ++
 Tests/RunCMake/string/AppendNoArgs.cmake  |  1 +
 Tests/RunCMake/string/RunCMakeTest.cmake  |  3 ++
 9 files changed, 107 insertions(+)
 create mode 100644 Help/release/dev/string-append.rst
 create mode 100644 Tests/RunCMake/string/Append.cmake
 create mode 100644 Tests/RunCMake/string/AppendNoArgs-result.txt
 create mode 100644 Tests/RunCMake/string/AppendNoArgs-stderr.txt
 create mode 100644 Tests/RunCMake/string/AppendNoArgs.cmake

diff --git a/Help/command/string.rst b/Help/command/string.rst
index 34c1b61..bc4399c 100644
--- a/Help/command/string.rst
+++ b/Help/command/string.rst
@@ -15,6 +15,7 @@ String operations.
   string(REPLACE match_string
  replace_string output variable
  input [input...])
+  string(APPEND string variable [input...])
   string(CONCAT output variable [input...])
   string(MD5|SHA1|SHA224|SHA256|SHA384|SHA512
  output variable input)
@@ -55,6 +56,8 @@ through argument parsing.
 ``REPLACE`` will replace all occurrences of ``match_string`` in the input
 with ``replace_string`` and store the result in the output.
 
+``APPEND`` will append all the input arguments to the string.
+
 ``CONCAT`` will concatenate all the input arguments together and store
 the result in the named output variable.
 
diff --git a/Help/release/dev/string-append.rst b/Help/release/dev/string-append.rst
new file mode 100644
index 000..190b51e
--- /dev/null
+++ b/Help/release/dev/string-append.rst
@@ -0,0 +1,4 @@
+string-append
+-
+
+* The :command:`string` command learned a new ``APPEND`` subcommand.
diff --git a/Source/cmStringCommand.cxx b/Source/cmStringCommand.cxx
index edc6afc..efc1f16 100644
--- a/Source/cmStringCommand.cxx
+++ b/Source/cmStringCommand.cxx
@@ -74,6 +74,10 @@ bool cmStringCommand
 {
 return this-HandleLengthCommand(args);
 }
+  else if(subCommand == APPEND)
+{
+return this-HandleAppendCommand(args);
+}
   else if(subCommand == CONCAT)
 {
 return this-HandleConcatCommand(args);
@@ -730,6 +734,34 @@ bool cmStringCommand
 }
 
 //
+bool cmStringCommand::HandleAppendCommand(std::vectorstd::string const args)
+{
+  if(args.size()  2)
+{
+this-SetError(sub-command APPEND requires at least one argument.);
+return false;
+}
+
+  // Skip if nothing to append.
+  if(args.size()  3)
+{
+return true;
+}
+
+  const std::string variable = args[1];
+
+  std::string value;
+  const char* oldValue = this-Makefile-GetDefinition(variable);
+  if(oldValue)
+{
+value = oldValue;
+}
+  value += cmJoin(cmRange(args).advance(2), std::string());
+  this-Makefile-AddDefinition(variable, value.c_str());
+  return true;
+}
+
+//
 bool cmStringCommand
 ::HandleConcatCommand(std::vectorstd::string const args)
 {
diff --git a/Source/cmStringCommand.h b/Source/cmStringCommand.h
index 9c75095..3ed17eb 100644
--- a/Source/cmStringCommand.h
+++ b/Source/cmStringCommand.h
@@ -67,6 +67,7 @@ protected:
   bool HandleReplaceCommand(std::vectorstd::string const args);
   bool HandleLengthCommand(std::vectorstd::string const args);
   bool HandleSubstringCommand(std::vectorstd::string const args);
+  bool HandleAppendCommand(std::vectorstd::string const args);
   bool HandleConcatCommand(std::vectorstd

Re: [cmake-developers] PATCH: add subcommand string(APPEND)

[Daniel Pfeifer]

On Mon, Jul 6, 2015 at 10:55 PM, James Bigler jamesbig...@gmail.com wrote:
 list(APPEND) requires at least one element argument, right?

No, see 
https://github.com/Kitware/CMake/blob/master/Source/cmListCommand.cxx#L236
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CTest: hide progress ticks in verbose output

[Daniel Pfeifer]

Hi,

The progress ticks and information about the length of the output are
useful when the actual output is not visible.

When the output is printed, the progress ticks

* add no useful information
* do not look pretty
* make the output hard to parse for tools.

The attached patch hides the progress ticks when the output is shown (-VV).

Cheers, Daniel
From 31290dd36fff5fd88a66069d962a9e3c80746525 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer dan...@pfeifer-mail.de
Date: Fri, 3 Jul 2015 22:52:23 +0200
Subject: [PATCH] CTest: hide progress ticks in verbose output

---
 Source/CTest/cmCTestBuildHandler.cxx | 10 +-
 Source/cmCTest.cxx   | 14 ++
 Source/cmCTest.h |  1 +
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/Source/CTest/cmCTestBuildHandler.cxx b/Source/CTest/cmCTestBuildHandler.cxx
index e141b60..6dbb245 100644
--- a/Source/CTest/cmCTestBuildHandler.cxx
+++ b/Source/CTest/cmCTestBuildHandler.cxx
@@ -920,7 +920,7 @@ int cmCTestBuildHandler::RunMakeCommand(const char* command,
 
   char* data;
   int length;
-  cmCTestOptionalLog(this-CTest, HANDLER_OUTPUT,
+  cmCTestOptionalLog(this-CTest, HANDLER_PROGRESS_OUTPUT,
Each symbol represents   tick_len   bytes of output.
  std::endl
  (this-UseCTestLaunch?  :
@@ -968,7 +968,7 @@ int cmCTestBuildHandler::RunMakeCommand(const char* command,
   this-ProcessBuffer(0, 0, tick, tick_len, ofs, this-BuildProcessingQueue);
   this-ProcessBuffer(0, 0, tick, tick_len, ofs,
 this-BuildProcessingErrorQueue);
-  cmCTestOptionalLog(this-CTest, OUTPUT,  Size of output: 
+  cmCTestOptionalLog(this-CTest, HANDLER_PROGRESS_OUTPUT,  Size of output: 
  ((this-BuildOutputLogSize + 512) / 1024)  K  std::endl,
 this-Quiet);
 
@@ -1175,12 +1175,12 @@ void cmCTestBuildHandler::ProcessBuffer(const char* data, int length,
   while ( this-BuildOutputLogSize  (tick * tick_len) )
 {
 tick ++;
-cmCTestOptionalLog(this-CTest, HANDLER_OUTPUT, this-LastTickChar,
-  this-Quiet);
+cmCTestOptionalLog(this-CTest, HANDLER_PROGRESS_OUTPUT,
+  this-LastTickChar, this-Quiet);
 tickDisplayed = true;
 if ( tick % tick_line_len == 0  tick  0 )
   {
-  cmCTestOptionalLog(this-CTest, HANDLER_OUTPUT,   Size: 
+  cmCTestOptionalLog(this-CTest, HANDLER_PROGRESS_OUTPUT,   Size: 
  ((this-BuildOutputLogSize + 512) / 1024)  K  std::endl
  , this-Quiet);
   }
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index 5887ba8..5676dda 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -1220,7 +1220,7 @@ int cmCTest::RunMakeCommand(const char* command, std::string output,
 
   char* data;
   int length;
-  cmCTestLog(this, HANDLER_OUTPUT,
+  cmCTestLog(this, HANDLER_PROGRESS_OUTPUT,
Each . represents   tick_len   bytes of output  std::endl
std::flush);
   while(cmsysProcess_WaitForData(cp, data, length, 0))
@@ -1236,10 +1236,10 @@ int cmCTest::RunMakeCommand(const char* command, std::string output,
 while ( output.size()  (tick * tick_len) )
   {
   tick ++;
-  cmCTestLog(this, HANDLER_OUTPUT, .  std::flush);
+  cmCTestLog(this, HANDLER_PROGRESS_OUTPUT, .  std::flush);
   if ( tick % tick_line_len == 0  tick  0 )
 {
-cmCTestLog(this, HANDLER_OUTPUT,
+cmCTestLog(this, HANDLER_PROGRESS_OUTPUT,
  Size: 
 int((double(output.size()) / 1024.0) + 1)
 K  std::endl
@@ -1252,7 +1252,7 @@ int cmCTest::RunMakeCommand(const char* command, std::string output,
   ofs  cmCTestLogWrite(data, length);
   }
 }
-  cmCTestLog(this, OUTPUT,  Size of output: 
+  cmCTestLog(this, HANDLER_PROGRESS_OUTPUT,  Size of output: 
  int(double(output.size()) / 1024.0)  K  std::endl);
 
   cmsysProcess_WaitForExit(cp, 0);
@@ -3101,6 +3101,7 @@ static const char* cmCTestStringLogType[] =
   DEBUG,
   OUTPUT,
   HANDLER_OUTPUT,
+  HANDLER_PROGRESS_OUTPUT,
   HANDLER_VERBOSE_OUTPUT,
   WARNING,
   ERROR_MESSAGE,
@@ -3139,6 +3140,11 @@ void cmCTest::Log(int logType, const char* file, int line, const char* msg,
 {
 return;
 }
+  if ( logType == cmCTest::HANDLER_PROGRESS_OUTPUT 
+  ( this-Debug || this-ExtraVerbose ) )
+{
+return;
+}
   if ( this-OutputLogFile )
 {
 bool display = true;
diff --git a/Source/cmCTest.h b/Source/cmCTest.h
index 47245ae..73c2807 100644
--- a/Source/cmCTest.h
+++ b/Source/cmCTest.h
@@ -382,6 +382,7 @@ public:
 DEBUG = 0,
 OUTPUT,
 HANDLER_OUTPUT,
+HANDLER_PROGRESS_OUTPUT,
 HANDLER_VERBOSE_OUTPUT,
 WARNING,
 ERROR_MESSAGE,
-- 
2.4.5

-- 

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

Re: [cmake-developers] A policy for Policies

[Daniel Pfeifer]

On Sun, Jun 7, 2015 at 7:09 PM, Mike Gelfand mike...@mikedld.com wrote:
 On Sat, June 6, 2015 13:36, Stephen Kelly wrote:
 Code for Policies is also often complex. I often encounter Policies which
  are ancient and which get in the way of code clean up generally.

 Exactly the reason I don't understand why you'd want to add another policy
 to affect policies.

If you carefully re-read Steve's proposal, you'll notice the
distinction between policy and Policy.
Policies (upper case P) are represented in code; policies aren't.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Composability of INTERFACE properties and custom targets

[Daniel Pfeifer]

Hi,

in a project, I have to generate some C++ header files at build time.
Targets that use these header files need to know the directory of the
generated files and depend on the custom target that in turn depends
on the generated files. Example:

  target_include_directories(lib PRIVATE ${gen_dir})
  add_dependency(lib gen_target)

I would like to modernize that to:

  target_link_libraries(lib PRIVATE gen_interface)

However, there is afaik no way of combining INTERFACE properties and
custom targets.
I think CMake needs one of the following alternatives:

1. Allow adding target-level dependencies to INTERFACE library:

  add_library(interface INTERFACE)
  target_include_directories(interface INTERFACE ...)
  add_custom_target(custom DEPENDS ...)
  add_dependencies(interface custom)

2. Allow INTERFACE properties on custom targets:

  add_custom_target(custom DEPENDS ...)
  target_include_directories(custom INTERFACE ...)

3. Allow file level dependencies for INTERFACE libraries

  add_library(interface INTERFACE DEPENDS ...)

Any of these three solutions satisfies my requirements, option 3 being
my favorite.

A similar question was left unanswered here:
http://public.kitware.com/pipermail/cmake/2014-April/057456.html

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] cmXMLWriter

[Daniel Pfeifer]

Hi,

I wrote a simple XML writer (cmXMLWriter) that takes care of
indentation, escaping, and balancing of end tags. I also ported all of
CTest's  XML generation to cmXMLWriter.

https://github.com/purpleKarrot/CMake/commits/xmlwriter

Please review and potentially apply.

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Regarding the 'run-include-what-you-use' topic

[Daniel Pfeifer]

On Wed, May 20, 2015 at 7:34 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
 I looked quickly at the clang-tidy docs and it looks interesting.  I see it
 is setup to use the compile_commands.json file.  Originally we looked at
 running iwyu using that file.  However, it became quickly evident that this
 would be a pain to do.

I can confirm that it is a pain for clang-tidy too.

 By using it as pre-compile command  we can capture
 its output as compiler warnings and report them on the dashboard.  In
 addition, it can be run in parallel by the build tool (make or ninja).  I
 will take a look at clang-tidy as it might fit into the iwyu setup we
 created in a similar way.

Thanks, I am pretty sure it does.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Regarding the 'run-include-what-you-use' topic

[Daniel Pfeifer]

Hi Brad, Hi Bill,

I think it is great that CMake gains support for IWYU.

Without having tested it, I think the current implementation is
compatible with other static analyzers like for examle clang-tidy.

I think this is not good. If the options can be used for other tools
than IWYU, the option name and its documentation should not be IWYU
specific.

It also would be great to have more than one static analyzer enabled
at a time. Like IWYU and clang-tidy and KWStyle and ...

Just my € 0.02.

-- Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[Daniel Pfeifer]

On Fri, Mar 20, 2015 at 6:35 PM, Amine Khaldi amine.kha...@reactos.org wrote:
 Two requests please:

 * The option to use existing headers instead of autogenerated ones.

That is an implementation detail. It should not make a difference
whether the precompiled header is used through your existing header or
through an autogenerated header that forward includes your existing
header. This forward inclusion is important at least for GCC: The
compiler searches for a .gch file in the same directory as the header
file. Since we do not want this .gch file to be generated in the
source directory for out-of-source builds, we need to put the header
file into the build directory.

Did I misunderstand your request and you meant use an existing
*precompiled* header, ie. provide a .pch or .gch file?
My approach currently does not support that. Please let me know if
that is what you meant.

 * Implementing PCH support without additional targets. ReactOS already has 
 like 1000+ targets, and we currently use PCH on almost all of them, so 
 imagine if this official implementation doubles our targets number.

I completely agree.

One request that I can add:

* It shall be visible in the IDE's settings that precompiled headers are used.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[Daniel Pfeifer]

On Wed, Mar 4, 2015 at 8:53 PM, Brad King brad.k...@kitware.com wrote:

 On 03/03/2015 07:43 AM, Adam Strzelecki wrote:
  On 03/01/2015 08:02 PM, Ben Boeckel wrote:
  On 02/28/2015 11:59 AM, Adam Strzelecki wrote:
   target_precompiled_header(target path/to/precompiled_header.h)
 
   target_precompiled_header(target path/to/precompiled_header.h
 SHARED
 
 other_target_to_share_precompiled_header_with)
  Could we rename this? Currently target_* functions are all related to
  usage requirements and these are not usage requirements.
 
  Honestly I don't understand your request. What would be then the name
  that better represents what the function does.

 Currently the target_* commands are:

  target_compile_definitions
  target_compile_features
  target_compile_options
  target_include_directories
  target_link_libraries
  target_sources

 They all have the general signature

  target_command(target [options] [SCOPE items...]...)

 where SCOPE is INTERFACE, PUBLIC, or PRIVATE and affects whether the
 settings apply to sources in the target itself and/or its dependents.
 The proposed target_precompiled_header signature does not fit into
 this layout.  Either a different command name is needed or one needs
 to define the command signature and semantics to fit the above layout.
 Do PCHs fit into usage requirements in any way?


That would be nice, right?
I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch
Expect it to be incomplet and incorrekt. It certainly needs a couple of
iterations, but the direction should be clear:


add_library(foo foo.c)
target_include_directories(foo PUBLIC include)
target_precompile_headers(foo PUBLIC foo.h)

add_library(bar INTERFACE)
target_include_directories(bar INTERFACE include)
target_precompile_headers(bar INTERFACE bar.h)

add_executable(foobar foobar.c)
target_link_libraries(foobar foo bar)


There is a new command called target_precompile_headers. This name is
chosen carefully.
* It says precompile headers, not precompiled header. This command is
used to set a list of headers to precompile. It is not used to specify a
single prebuilt file.
* It has a target_ prefix, and the expectations about usage requirements
should be satisfied.


Things to keep in mind:
* We probably want to precompile headers based on configuration.
* For generators that support it (Makefile + Ninja), we want to precompile
headers based on the compile language.
* We probably want to enable/disable the use of PCH globally, on a
per-target-level, and on a per-source-level.

 In meantime https://github.com/nanoant/CMakePCHCompiler is just an
implementation that emulates desired behavior using many tricks. But I
don't want this to be a part of CMake, but instead I want this to be
handled natively adding some extra variables:

Good. That means we are on the same page. I was a little confused when I
first saw your approach. :-)

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Minimal compiler requirements for CMake itself

[Daniel Pfeifer]

Hi,

I would like to know what the oldest versions of GCC and Visual Studio are
that should be able to compile the CMake source code. I was unable to find
any information about that.

I expected the oldest supported version of Visual Studio to be 6.0, but
that one fails to build CMake.

Don't get me wrong. I would not be unhappy if building CMake required the
latest and greatest compilers and language features. I just want to know
which compilers I need to be support when I contribute code.

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] target_include_directories target issue

[Daniel Pfeifer]

FWD to developers list. I think this is a documentation issue.

Luis Felipe Dominguez Vega lfdoming...@estudiantes.uci.cu schrieb am Mon
Nov 17 2014 at 5:42:55 PM:

 I can't see into the source code of cmake, into the
 cmTargetIncludeDirectoriesCommand.cxx somethink like import the
 INCLUDE_DIRECTORIES from target passed to target_include_directories, may
 an
 error in the documentation?
 ---
 On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote:
  Hello,
 
  the docs claim:
 
  Specify include directories or targets to use when compiling a given
  target.
 
  Here is a little test of it. Project directory:
 
  Foo
CMakeLists.txt
FooSrc
  a.h
  a.cpp
Bar
  main.cpp
 
  And CMakeLists.txt:
 
  cmake_minimum_required(VERSION 3.0)
 
  project(FooBar)
 
  add_library(Foo FooSrc/a.h FooSrc/a.cpp)
 
  target_include_directories(Foo PUBLIC G:/some_directory)
 
  if (TARGET Foo)
  message(Foo is a target!)
  endif()
 
  add_executable(Bar Bar/main.cpp)
 
  target_include_directories(Bar PRIVATE Foo)
 
  According to the docs, Bar's include directories should contain at
  least G:/some_directory, but it contains
  ${PROJECT_SOURCE_DIR}/Foo. Why?
 
  If I replace the last line with target_link_libraries(Bar PRIVATE
  Foo), then Bar's include directories meet my expectations.
 
  regards

 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake-gui icons

[Daniel Pfeifer]

2014-10-27 21:33 GMT+01:00 Ben Boeckel ben.boec...@kitware.com:

 On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote:
  Trying to bring a bit more attention to this:
 
  Fedora is pushing to have higher resolution icons for the applications.
 There
  already is CMakeSetup128.png, but these would need to get installed into
 the
  proper /usr/share/icons/ hierarchy and named appropriately for the
 correct
  size to be automatically found and used. It would be good to have
 cmake-gui be
  conformant to the current desktop standards.
 
  Related -
 
  http://www.cmake.org/Bug/view.php?id=13504
  http://www.cmake.org/Bug/view.php?id=14315
 
  Also might want to consider shipping AppData information.
 
  http://people.freedesktop.org/~hughsient/appdata/

 I think there's a bug about this too (or at least for appdata). My
 question is: does it really make sense to have appdata for CMake's GUI?
 It isn't an end user application and I feel that developers know
 about CMake's Qt UI (or at least wouldn't look for it in the application
 tool thing).

 (I'm not against AppData overall; just wondering whether it makes sense
 for development tools such as cmake-gui.)

 Others' thoughts?


I wouds say: Yes, it makes sense.

There is AppData for Anjuta, Eclipse, KDevelop, QtCreator and the like.
Those too are tools for developers rather than end users. cmake-gui would
perfectly fit into that crowd.

-- Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Modern cross-platform buildsystem design requirements

[Daniel Pfeifer]

Hi Steve,

2014-09-10 0:32 GMT+02:00 Stephen Kelly steve...@gmail.com:


 I wonder what a cmake-based buildsystem would look like for a collection of
 executables/targets which should be built for multiple ...


I would generalize even more and finish the sentence with options at once.
This includes Debug/Release, Shared/Static, PlatformA/PlatformB, etc.


With usage-requirements we now can propagate properties from dependees to
dependents. What about the other direction? Imagine this:

 add_library(foo STATIC foo.cpp)
 add_library(bar SHARED bar.cpp)
 target_link_libraries(bar foo)
 add_executable(myexe main.cpp)
 target_link_libraries(myexe foo)

A static library foo is used both in a shared library and in an executable.
Depending on the platform it should be build twice: once with PIC, once
without.


Another example: We sometimes run code generators as custom buildsteps.

 add_library(foo foo.cpp)
 add_executable(codegen codegen.cpp)
 # set_target_properties(codegen PROPERTIES BUILD_FOR_HOST 1)
 target_link_libraries(codegen foo)
 add_custom_command(OUTPUT source.cpp COMMAND codegen)
 add_executable(myexe source.cpp)
 target_link_libraries(myexe foo)

When crosscompiling, we need the codegenerator for the host platform (This
would need some target property).
But more interestingly, the library foo should be built for both the host
and the target(s).


Thank you for starting that discussion!

-- Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] LZMA support

[Daniel Pfeifer]

2014-07-30 15:58 GMT+02:00 Brad King brad.k...@kitware.com:

 On 07/23/2014 10:43 AM, Brad King wrote:
  I've merged the topic to 'next' for testing, but without the CPack
  or ExternalProject pieces.  Likely some more portability fixes
  will be required after testing on the dashboard.  Once that is clean
  I will add the other changes again on top of the revised topic.

 This is all now in master as of commit 6370c90f.  I've updated
 issues 13072, 13515, 14504, and 14519 accordingly.


Great!

I think we should add packaging options like 'CPACK_BINARY_7Z' to
'Modules/CPack.cmake'.
Maybe the options should be reordered alphabetically, to make it obvious
where to add new package generators.

By the way: CPACK_BINARY_IFW should be added to the 'mark_as_advanced' list
too.

cheers, Daniel
diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake
index b58f944..8b07cea 100644
--- a/Modules/CPack.cmake
+++ b/Modules/CPack.cmake
@@ -426,6 +426,7 @@ if(NOT CPACK_GENERATOR)
   option(CPACK_BINARY_STGZ Enable to build STGZ packagesON)
   option(CPACK_BINARY_TGZ  Enable to build TGZ packages ON)
   option(CPACK_BINARY_TBZ2 Enable to build TBZ2 packagesOFF)
+  option(CPACK_BINARY_TXZ  Enable to build TXZ packages OFF)
   option(CPACK_BINARY_DEB  Enable to build Debian packages  OFF)
   option(CPACK_BINARY_RPM  Enable to build RPM packages OFF)
   option(CPACK_BINARY_NSIS Enable to build NSIS packagesOFF)
@@ -434,6 +435,7 @@ if(NOT CPACK_GENERATOR)
 option(CPACK_BINARY_NSIS Enable to build NSIS packages ON)
 option(CPACK_BINARY_WIX  Enable to build WiX packages OFF)
 option(CPACK_BINARY_ZIP  Enable to build ZIP packages OFF)
+option(CPACK_BINARY_7Z   Enable to build 7-Zip packages OFF)
   endif()
   option(CPACK_BINARY_IFW Enable to build IFW packages OFF)
 
@@ -448,10 +450,12 @@ if(NOT CPACK_GENERATOR)
   cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_STGZ STGZ)
   cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_TGZ  TGZ)
   cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_TBZ2 TBZ2)
+  cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_TXZ  TXZ)
   cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_TZ   TZ)
   cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_WIX  WIX)
   cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_ZIP  ZIP)
   cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_IFW  IFW)
+  cpack_optional_append(CPACK_GENERATOR  CPACK_BINARY_7Z   7Z)
 
 endif()
 
@@ -463,26 +467,32 @@ if(NOT CPACK_SOURCE_GENERATOR)
 else()
   option(CPACK_SOURCE_TBZ2 Enable to build TBZ2 source packages ON)
   option(CPACK_SOURCE_TGZ  Enable to build TGZ source packages  ON)
+  option(CPACK_SOURCE_TXZ  Enable to build TXZ source packages  ON)
   option(CPACK_SOURCE_TZ   Enable to build TZ source packages   ON)
   option(CPACK_SOURCE_ZIP  Enable to build ZIP source packages  OFF)
 endif()
   else()
 option(CPACK_SOURCE_ZIP Enable to build ZIP source packages ON)
+option(CPACK_SOURCE_7Z  Enable to build 7-Zip source packages ON)
   endif()
 
   cpack_optional_append(CPACK_SOURCE_GENERATOR  CPACK_SOURCE_CYGWIN  CygwinSource)
   cpack_optional_append(CPACK_SOURCE_GENERATOR  CPACK_SOURCE_TGZ TGZ)
   cpack_optional_append(CPACK_SOURCE_GENERATOR  CPACK_SOURCE_TBZ2TBZ2)
+  cpack_optional_append(CPACK_SOURCE_GENERATOR  CPACK_SOURCE_TXZ TXZ)
   cpack_optional_append(CPACK_SOURCE_GENERATOR  CPACK_SOURCE_TZ  TZ)
   cpack_optional_append(CPACK_SOURCE_GENERATOR  CPACK_SOURCE_ZIP ZIP)
+  cpack_optional_append(CPACK_SOURCE_GENERATOR  CPACK_SOURCE_7Z  7Z)
 endif()
 
 # mark the above options as advanced
 mark_as_advanced(CPACK_BINARY_CYGWIN CPACK_BINARY_PACKAGEMAKER CPACK_BINARY_OSXX11
  CPACK_BINARY_STGZ   CPACK_BINARY_TGZ  CPACK_BINARY_TBZ2
  CPACK_BINARY_DEBCPACK_BINARY_RPM  CPACK_BINARY_TZ
+ CPACK_BINARY_TXZCPACK_BINARY_7Z
  CPACK_BINARY_NSIS CPACK_BINARY_WIX CPACK_BINARY_ZIP CPACK_BINARY_BUNDLE
  CPACK_SOURCE_CYGWIN CPACK_SOURCE_TBZ2 CPACK_SOURCE_TGZ
+ CPACK_SOURCE_TXZCPACK_SOURCE_7Z
  CPACK_SOURCE_TZ CPACK_SOURCE_ZIP CPACK_BINARY_DRAGNDROP)
 
 # Set some other variables
-- 

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:

[cmake-developers] LZMA support

[Daniel Pfeifer]

Hi,

In my liblzma branch (https://github.com/purpleKarrot/CMake/commits/liblzma),
I did the following:

* add the liblzma source from XZ Utils
* make it compile with CMake (by adding CMakeLists.txt etc.)
* make it compile in VC6 (by porting the source from C99 to C90)
* make cmlibarchive use cmliblzma (using cm_lzma.h)
* add cpack generators for .7z and .tar.xz

This should solve the following issues:

http://www.cmake.org/Bug/view.php?id=13072
http://www.cmake.org/Bug/view.php?id=13515
http://www.cmake.org/Bug/view.php?id=14504
http://www.cmake.org/Bug/view.php?id=14519

Please review, comment, pull.

Cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Optional dependencies in target INTERFACE

[Daniel Pfeifer]

2014-06-30 10:18 GMT+02:00 Stephen Kelly steve...@gmail.com:


 Hello,

 QtSQL provides abstracted access to database data. It does not depend on
 QtGui or QtWidgets.

 It also provides the header-only qsqlrelationaldelegate.h. The contents of
 that header depend on QtWidgets, and are wrapped in an ifdef
 QT_WIDGETS_LIB.
 That means that the QSqlRelationalDelegate class is only available if that
 macro is defined, which is an effect of linking to Qt5Widgets anyway. This
 seems to be a good and well-working way to have an optional INTERFACE
 dependency.

 Unfortunately most projects do not have something similar to QT_WIDGETS_LIB
 macros.

 If a target is only a dependency if the depender uses a particular header,
 then should that target appear in the INTERFACE_LINK_LIBRARIES? If using
 QtGui but not using #include qopengl you do not depend on the GL
 libraries. If you add that include, you do depend on the GL libraries. Do
 the GL libraries belong in the INTERFACE_LINK_LIBRARIES of QtGui? That is
 the subject of

  https://bugreports.qt-project.org/browse/QTBUG-39859

 In the case of modularized-Boost header-only libraries with INTERFACE
 targets, what criteria should be used to determine whether to put a
 dependency in the INTERFACE_LINK_LIBRARIES and make component packages? The
 actual dependencies required are determined by what the user #includes, not
 by what headers are #included by 'my' headers.


... or what the user uses *in addition*.

When my project depends on Boost.UUID but not on Boost.Serialization, then
I certainly don't need the optional serialization support of UUIDs.
If I want to use serialization, then Boost.Serialization has to be a direct
dependency of my project as I need to #include some of its headers directly.

I conclude that the optional dependency from Boost.UUID to
Boost.Serialization does not have to be represented at all.
Does that make sense?

-- Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Compiler features/extensions remaining/future issues

[Daniel Pfeifer]

2014-06-15 22:24 GMT+02:00 Stephen Kelly steve...@gmail.com:

 Brad King wrote:

  On 06/13/2014 05:19 AM, Stephen Kelly wrote:
  11) WriteCompilerDetectionHeader vs GenerateExportHeader
 
  IMO these two modules are solving orthogonal problems and should not
  be mixed.

 I'm not sure I agree.

 GenerateExportHeader needs to know about deprecation in order to generate
 FOO_EXPORT_DEPRECATED and similar macros. So, they're not fully orthogonal.


Both provide macros depending on the compiler. From a users perspective
they are not orthogonal at all.
Furthermore, I would prefer export headers to be compiler independent.

cheers, Daniel
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Daniel Pfeifer]

2014/1/14 Brad King brad.k...@kitware.com:
 On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
 does this require a policy now ?

 Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
 project(Foo)
 call in a subdir, which would now unset Foo_VERSION_MAJOR.
 The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.

 I don't think project(Foo) needs to affect Foo_VERSION_* when no
 VERSION argument is given (but should handle empty VERSION ).
 It should still handle PROJECT_VERSION_* to ensure consistency
 with PROJECT_NAME.

What about CMAKE_PROJECT_VERSION_* for consistency with CMAKE_PROJECT_NAME?

  That may need a policy, but it will be tricky
 because we need to know if the value came from a previous project()
 call or a user set() in order to know when to trigger compatibility.

 Perhaps project(... VERSION ...) can set some cmMakefile variable
 internally that says the project knows about versions so it is okay
 project(Foo) calls to unset them in subdirs.  Then we won't need any
 policy because there is no change in behavior without modifying the
 project to add at least one VERSION to a project() command.
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Daniel Pfeifer]

2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net:
 On 2014-01-14 10:37, Brad King wrote:

 On 01/13/2014 01:38 PM, Alexander Neundorf wrote:

 does this require a policy now ?

 Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
 project(Foo)
 call in a subdir, which would now unset Foo_VERSION_MAJOR.
 The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.


 I don't think project(Foo) needs to affect Foo_VERSION_* when no
 VERSION argument is given (but should handle empty VERSION ).
 It should still handle PROJECT_VERSION_* to ensure consistency
 with PROJECT_NAME.  That may need a policy, but it will be tricky
 because we need to know if the value came from a previous project()
 call or a user set() in order to know when to trigger compatibility.

 Perhaps project(... VERSION ...) can set some cmMakefile variable
 internally that says the project knows about versions so it is okay
 project(Foo) calls to unset them in subdirs.  Then we won't need any
 policy because there is no change in behavior without modifying the
 project to add at least one VERSION to a project() command.


 While that sounds good for 99.9% of cases, what about the case of project A
 that includes project B, where B is not updated, but A decides to start
 using project(...VERSION...). Now if B was using PROJECT_VERSION internally,
 it is broken. (Note that I'm implying that B is e.g. a separate repository
 that may not be as easy to update/fix as A.)

 That's an edge case though... not sure it's worth worrying about, but just
 saying...

 @Daniel, there is a CMAKE_PROJECT_NAME? I've always used just
 PROJECT_NAME... (Is PROJECT_NAME deprecated?) Anyway, while *hopefully* no
 one is setting e.g. CMAKE_PROJECT_VERSION there's still risk that they are.

http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_PROJECT_NAME
http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:PROJECT_NAME

The documentation for both variables is misleading. As far as I
understand it, PROJECT_NAME is the name of the current project, while
CMAKE_PROJECT_NAME us the name of the top-level project.
This comes in handy when projects are added with 'add_subdirectory()'.
If NOT CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME, the current project
is not built independently.
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Additional properties for PCH support

[Daniel Pfeifer]

2013/11/26 Stephen Kelly steve...@gmail.com:
 Peter Kuemmel wrote:
 So, is this the right way to improve the pch situation?

 I don't know anything about PCH, but Daniel Pfeifer has a branch here:

  https://github.com/purpleKarrot/CMake/tree/WIP-PCH-Support

Thanks for pointing at this branch. I currently don't have much time
to invest into this.
But I want to share some of my thoughts:

PCH shall be non-intrusive: Projects that are created with the Visual
Studio Wizard often require that all sources include the stdafx.h
file as the first header. This affects include dependencies when
precompiled headers are not used (bad!). In a non-intrusive approach,
the source code is not PCH-aware. Instead, the appropriate header is
force-included via command line iff PCH is enabled. This can be done
via /FI for MSVC and -include for GCC.

Some compilers (MSVC) require a source file to precompile the header,
others (GCC) use the header directly as input. This difference shall
be abstracted. If a source file is required, it shall be generated
internally in CMake.

It should be possible to define multiple headers to be precompiled.
While some compilers (GCC) allow only one PCH per compilation unit, it
is always possible to generate a single header that #includes the
files to be precompiled. This single header then can be used as input
for precompilation.

It would be nice to define headers to be precompiled as target usage
requirements. Like, when you link against boost::asio, you will
precompile boost/asio.hpp.
The two target proverties probably would be called PRECOMPILE_HEADERS
and INTERFACE_PRECOMPILE_HEADERS. Maybe a
target_precompile_headers(...PUBLIC/PRIVATE/INTERFACE...) makes sense
too.

If precompiled headers are usage requirements, linking against a
target that has the INTERFACE_PRECOMPILE_HEADERS property set will
enable precompiled headers for your target. This might not be
intended. Therefore, It shall be possible to disable precompiled
headers both globally and on a target level.

cheers, Daniel
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Converting CMake documentation to reStructuredText and Sphinx

[Daniel Pfeifer]

2013/10/11 Brad King brad.k...@kitware.com:
 On 10/11/2013 01:09 AM, Daniel Pfeifer wrote:
 Will it still be able to generate DocBook, so companies can include
 the documentation in their handbook?

 It can generate whatever Sphinx can generate.  IIRC Sphinx does not
 currently support DocBook output but I see no reason it couldn't be
 taught to do so.  That would be re-usable for many other packages that
 use Sphinx too.

Comparing the expressiveness, extensability, and supported backends,
can you explain why you would prefer rST over AsciiDoc?

Somewhere I read the analogy markdown == child, docbook == adult w/
garb, asciidoc == adult w/ jeans  t-shirt and I think that nails it
pretty well.
I thinks it was somewhere on http://asciidoctor.org/

cheers, Daniel
--

Powered by www.kitware.com

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

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

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

[cmake-developers] (naming-)convention for ALIAS and INTERFACE targets

[Daniel Pfeifer]

Hi Steve and all,

we restarted the CMake-ification of molularized Boost with modern
CMake features here: https://github.com/boost-cmake/boost-cmake

We want to be able to build all Boost libraries together, but also
each library on its own.
Am I correct that in both cases we use the :: name in tll()?

The :: target name is an ALIAS in the first use case and an imported
INTERFACE in the second, right?

I assume that, for the INTERFACE case, the interfaces need to be
imported with find_package(). How can we make sure that calling
find_package() does not get in the way when Boost is built as a whole?

Boost also provides some tools for building documentation. To simplify
using these tools with CMake, we want to make them provide also some
CMake modules. Note that we don't want to put these modules in a
common location, but let each Boost tool bring its own module.

Since those modules will be used by Boost itself, they should be
usable from both the install dir and the source dir.

What would be better?
1) Let Boostbook provide a module UseBoostbook.cmake
2) Put all Boostbook related functions into FindBoostbook.cmake

cheers, Daniel
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] confusing documentation: VS_WINRT_EXTENSIONS

[Daniel Pfeifer]

2013/9/3 Daniel Pfeifer dan...@pfeifer-mail.de:
 2013/9/3 Brad King brad.k...@kitware.com:
 On 09/03/2013 03:39 AM, Daniel Pfeifer wrote:
 According to http://www.cmake.org/Bug/view.php?id=12930#c30721,
 WindowsAppContainer will not pass /ZW to the command line.
 Hence, setting VS_WINRT_EXTENSIONS will not enable C++/CX and the
 documentation is incorrect. But that is good.

 Maybe also the name of that property is misleading. It might be better
 to use the same name that is used as a define, which means
 WINAPI_FAMILY as property with the possible values
 WINAPI_PARTITION_APP and WINAPI_PARTITION_DESKTOP (and maybe more,
 once Microsoft adds new partitions of the winapi).

 It is also important that WINAPI_PARTITION_DESKTOP is not supported
 when compiling for ARM. Here, WINAPI_PARTITION_APP should be the
 default, especially for the initial compile checks.

 Visual Studio generators should set WindowsAppContainer if
 WINAPI_FAMILY is set to WINAPI_PARTITION_APP.
 Makefile generators should pass  -DWINAPI_FAMILY=${WINAPI_FAMILY} to
 the command line.

 As I don't do development in this area I have to depend on contributors
 for knowledge.  If you have time, please prepare a patch series:

 1. Add the better-named property you propose.
 2. Fix the docs of VS_WINRT_EXTENSIONS and perhaps suggest using
the alternative name instead.

 OK, I will do that.

Brad,

I pushed my work here:
https://github.com/purpleKarrot/CMake/compare/WIP-VS11-ARM

There are some TODOs in the commit messages, but I would like to hear
your feedback before I continue. Is that the right direction?

To execute the tests, I set CMAKE_TEST_GENERATOR to Visual Studio 11
ARM and CMAKE_TEST_MAKEPROGRAM to devenv.
The test output shows that configuring and compiling works when my
patches are applied to CMake. Many testcases still fail because they
try to run the produced .exe files. Those files are for ARM and
obviously fail to execute on Win32.

cheers, Daniel
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] confusing documentation: VS_WINRT_EXTENSIONS

[Daniel Pfeifer]

2013/9/2 Brad King brad.k...@kitware.com:
 On 09/02/2013 11:42 AM, Daniel Pfeifer wrote:
 The target property VS_WINRT_EXTENSIONS is documented as: Can be set
 to enable C++/CX language extensions.
 Is that really what this property does?
 [snip]
 So my question again: Does VS_WINRT_EXTENSIONS really enable C++/CX? I hope 
 not.

 This was contributed here:

  http://www.cmake.org/Bug/view.php?id=12930
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e01aefd
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c9ae472
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0ae381c

 I don't know more than that.

According to http://www.cmake.org/Bug/view.php?id=12930#c30721,
WindowsAppContainer will not pass /ZW to the command line.
Hence, setting VS_WINRT_EXTENSIONS will not enable C++/CX and the
documentation is incorrect. But that is good.

Maybe also the name of that property is misleading. It might be better
to use the same name that is used as a define, which means
WINAPI_FAMILY as property with the possible values
WINAPI_PARTITION_APP and WINAPI_PARTITION_DESKTOP (and maybe more,
once Microsoft adds new partitions of the winapi).

It is also important that WINAPI_PARTITION_DESKTOP is not supported
when compiling for ARM. Here, WINAPI_PARTITION_APP should be the
default, especially for the initial compile checks.

Visual Studio generators should set WindowsAppContainer if
WINAPI_FAMILY is set to WINAPI_PARTITION_APP.
Makefile generators should pass  -DWINAPI_FAMILY=${WINAPI_FAMILY} to
the command line.

cheers, Daniel
--

Powered by www.kitware.com

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

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

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