Re: [cmake-developers] How to speed up CMake configuration on macOS

[Ben Boeckel via cmake-developers]

On Sat, Mar 23, 2019 at 15:07:39 +0100, Gregor Jasny via cmake-developers wrote:
> in the past when building CMake (itself) I spent long times waiting for 
> configuration of the embedded libraries. Mostly libcurl send / receive 
> signature detection. Today I had the idea of using system libraries 
> installed with Homebrew and the speedups are quite noticeable:

One thing I'd like to see here is to take a survey of what `send` and
`recv` signatures actually exist in the wild today. We can then remove
those `try_compile` runs from CMake's import. Further work would be to
have `libcurl` upstream do this survey too (though this is a wider set
of platforms than even CMake supports) and remove those which don't
actually appear in the wild today. In addition, the attempts can be
ordered based on platform and short circuit once one is found since
`send` can have only one actual definition.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Question about fetching big repositories with ExternalProject_Add

[Ben Boeckel via cmake-developers]

On Mon, Mar 11, 2019 at 16:50:21 +0100, workbe...@gmx.at wrote:
> i play around much with ExternalProject_Add and i found some kind of
> "error". When fetching big repositories like llvm cmake don't show any
> output when cloning the repository which makes the user believe cmake
> stucks, is there a way to show the clone process with
> ExternalProject_Add() so the user does not believe cmake is stuck ??
> It's find with normal repositories, but for example with llvm it's a
> nightmare.

There's the `GIT_PROGRESS 1` argument you can pass.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] $LIST_LENGTH{} syntax

[Ben Boeckel via cmake-developers]

On Tue, Jan 22, 2019 at 19:31:43 +0100, tors...@robitzki.de wrote:
> Currently, the Code that evaluates the ${}-Syntax only evaluates the key, if 
> the key is not an empty string:
> 
> const char* cmCommandArgumentParserHelper::ExpandSpecialVariable(
>   const char* key, const char* var)
> {
>   if (!key) {
> return this->ExpandVariable(var);
>   }
>   if (!var) {
> return "";
>   }
>   if (strcmp(key, "ENV") == 0) {
> std::string str;
> if (cmSystemTools::GetEnv(var, str)) {
>   if (this->EscapeQuotes) {
> return this->AddString(cmSystemTools::EscapeQuotes(str));
>   }
>   return this->AddString(str);
> }
> return "";
>   }
>   if (strcmp(key, „CACHE") == 0) {
> 
> …
> 
> so, there seems to be no risk to slow down the ExpandVariable()-Path (but of 
> cause, I would measure the difference).

That's the old (pre-CMP0053) parser. The new code for handling the
`$XXX{` parse switching is in `Source/cmMakefile.cxx:2810` (or so). The
method is `cmMakefile::ExpandVariablesInStringNew`. It is very
performance sensitive (i.e., the old parser is so slow compared to the
new one that running the new one beside it doesn't really affect
performance much and is what allows for CMP0053 warning messages).

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Referencing all sources in compile command

[Ben Boeckel via cmake-developers]

On Mon, Dec 31, 2018 at 15:30:28 -0800, Saleem Abdulrasool wrote:
> AFAIK, the driver interface is supposed to be stable.  The frontend options
> are not, but, the same holds true for clang as well.  The driver options
> are stable, and we (as the clang developer community) aim to not break
> that.  However, the frontend flags are entirely in the purview of the
> compiler developers and those change as needed.

OK, that's good to hear.

> swiftc -c -primary-file  -o  -emit-module-path
> .swiftmodule -emit-module-doc-path .swiftdoc
> 
> 
> This allows the compiler to look through the other sources which will be
> part of the module and perform semantic analysis across them if/when
> necessary.
> 
> Adding per file properties would still be possible, and, IMO, desired.
> That is part of the reason for doing the compilation in this mode rather
> than a single pass over the complete file set.  That said, most of the
> options really should be at a module level.

Ah, I see. This is also news to me. I think adding ``
would be suitable. However, it might need to be ``
since I suspect `swiftc` won't take kindly to C++, C, or their headers
files sneaking in on its commandline.

> On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel  wrote:
> > Other questions which spring to mind:
> >
> >   - Does it support making just the compile artifacts from the source
> > files or does it always do the link step?
> 
> The approach that I am taking does a separate compile and link step.  This
> allows for a better behavior when it comes to incremental builds which I
> care about.
> 
> >   - If the latter, how do mixed language libraries work?
> 
> The latter is what I believe most people have done, partially due to lack
> of understanding of how the build model works with swift which is
> completely understandable given that it is relatively opaque and it has not
> been documented as thoroughly as C/C++.
> 
> >   - Also, if linking is done by Swift, how would one add a manifest or
> > .rc file on Windows (e.g., to get an application icon)?
> 
> Well, you would still want to link using the swift driver, not the linker
> directly much like you use the driver to link C/C++.  I believe the changes
> have also been back ported to the 5.0 release to pass options from the
> [swift] driver to the [clang] driver to have them be translated
> appropriately for the linker in use.  But, the manifest and resource file
> handling is done by the linker IIRC, so this is largely unchanged beyond
> the need to pass along the right flags.

It sounds like `swiftc` is now much closer to the C++ separate TU
compilation model that CMake kind of assumes now (or at least supports
it). This should be fine then.

> > The list of restrictions would need to be well-defined here first I
> > think.
> 
> I think that there aren't very many restrictions that come to mind.  The
> biggest one is that it would be *extremely* helpful to have language
> specific properties that can be set, but, I really was hoping that there
> was a way to do this with a backwards compatible manner.  It would be
> helpful to have a property to indicate things like the swift version and
> the module name.

Language-specific properties are fine for a new language. The only
backwards compat I can think of is if people were using the
now-important property names before, but I think that since doing
`enable_language(Swift)` is an explicit action, developers can ensure
that their conflicting property names are not an issue.

> I'm happy to go into more detail, but, I'm really not sure I have an
> understanding of what things you may be thinking of as restrictions here.

I haven't thought too deeply on it either, but experience has shown that
there are always corner cases. As long as the initial implementation is
explicit about its use cases and errors on anything not tested, relaxing
it for future use cases is easier than allowing everything and using
policies to fix what is broken.

Thanks,

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Referencing all sources in compile command

[Ben Boeckel via cmake-developers]

On Sun, Dec 30, 2018 at 13:09:23 -0800, Saleem Abdulrasool wrote:
> I was looking at supporting Swift as a language in CMake.  I know that
> CMake has some preliminary support that assumes that you are building on
> macOS with Xcode.  I am trying to support building swift libraries and
> executables on Linux and Windows.

IIRC, the issue before was that the command line interface to swiftc was
basically treated as a black box and not stable (i.e., whatever Xcode
wanted drove the interface, backwards compat was not guaranteed). Is
that different now?

> There is some preliminary work on this that I have put up on GitHub [1].
> One place that I am hitting a roadblock in is the need to reference all the
> target sources in the compile rule for a single object.  AFAICT, there is
> no placeholder that will expand to the target sources.  Would it be
> acceptable to add a `` place holder?  Or is there another
> approach that would be better?

The problem with that is that per-source file properties cannot be
applied (compile definitions, flags, etc.). I don't know whether or not
this is important for Swift.

Other questions which spring to mind:

  - Does it support making just the compile artifacts from the source
files or does it always do the link step?
  - If the latter, how do mixed language libraries work?
  - Also, if linking is done by Swift, how would one add a manifest or
.rc file on Windows (e.g., to get an application icon)?

The list of restrictions would need to be well-defined here first I
think.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Preferred case for macro names?

[Ben Boeckel]

On Tue, Nov 13, 2018 at 11:36:24 +0100, Eric Noulard wrote:
> > My personal tendency is to use lower case for local variables and upper
> > case for global variables. May be we can normalize variables to upper case
> > regarding global variables used by CMake itself (which is globally the
> > current rule).
> 
> Having a convention for local is nice and I tend to prefix with _ (single
> or double) variables that should be local.
> lowercasing locals is fine too, however I think that enforcing casing on
> "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and
> CPACK_
> I guess they already are all UPPERCASE so we may stick with this as a
> convention?

My personal style is to use lowercase for derived or internal variables
(and properties). Uppercase is left for environment (e.g., CMake) or
user variables. Note that CMake also defines some un-namespaced
variables including:

  - BUILD_SHARED_LIBS
  - BUILD_TESTING
  - many CTest variables (*_COMMAND, DART_TESTING_TIMEOUT, etc.)

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Preferred case for macro names?

[Ben Boeckel]

On Tue, Nov 13, 2018 at 06:11:26 -0500, David Cole via cmake-developers wrote:
> I would just like to point out that some modules (ExternalData,
> ExternalProject, to name two specific examples) adopted the convention
> to prefix all their provided function names with the module name and
> an underscore: for example, ExternalProject_Add and
> ExternalData_Expand_Arguments.
> 
> These functions adopt a mixed-case function naming convention, since
> the module name is mixed case, and since module names are file names,
> and some file systems have case sensitive file names .. they
> should stay that way regardless of any convention you may like to try
> to adopt elsewhere.

Agreed. I use lower case everywhere I can, but externalproject_add just
looks worse than ExternalProject_add (though I'd really prefer
external_project_add, that ship sailed long ago).

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] option to prevent in-source builds

[Ben Boeckel]

On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote:
> A lot of projects that use CMake already have a `./cmake` directory, I
> would think `./cmake/init.json` would fit nicer as opposed to the hidden
> directory. I'm not a fan of hidden directories in software projects anyway.

There are also `./CMake` directories. HDF5 uses `./config/cmake`. I
think just claiming a "hidden" directory with exact casing is better.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Python bindings for CTest

[Ben Boeckel]

On Fri, Oct 19, 2018 at 12:33:34 -0400, Brad King wrote:
> If your goal is to submit to CDash, one could generate the .xml
> files directly from python and not need CTest at all.

There is some code in Spack which does this already (though it is very
Spack-specific, it might provide some help):


https://github.com/spack/spack/blob/1e1ea54bada54ae783198823c7f8fe0430ac41cb/lib/spack/spack/reporters/cdash.py

https://github.com/spack/spack/tree/e5a68327608d6a5e6c0709237517238e0de96c27/share/spack/templates/reports/cdash

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] BundleUtilities question

[Ben Boeckel]

On Fri, Aug 24, 2018 at 12:24:39 +, Kinga Kasa wrote:
> Error: copying file (when tries to copy the framework to the correct place)
> and
> "warning: cannot resolve item @rpath/QtNetwork.framework/Versions/5/QtNetwork
> warning: gp_resolved_file_type non-absolute file 
> '@rpath/QtNetwork.framework/Versions/5/QtNetwork' returning type 'other' - 
> possibly incorrect"

It appears that the libraries linking to Qt (and the other third party
library) are missing rpath entries which would allow them to find Qt.
When using `@rpath` as a library ID on macOS, rpath entries *must* be
added in order to use them.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ctest parallelism for --repeat-until-failure

[Ben Boeckel]

On Fri, Mar 23, 2018 at 09:33:28 -0700, Jupp Müller wrote:
> I have a question regarding the behavior of ctest with regard to the
> --repeat-until-failure option. It seems that this option
> sequentializes test execution for single tests in a test suite, while
> different tests can be run parallel to each other.
> 
> Is this the desired behavior? This is causing delays for my test
> suite, because some long-running tests are sequentialized. Would you
> be willing to accept a contribution that changes this? I realize this
> would be a backwards compatibility issue, because running the same
> test in parallel would break some tests, so I'd propose adding a new
> flag to ctest that would be disabled by default. Maybe
> --parallelize-repetitions ?

I'd say that this would be better handled by a test property that marks
tests as `CONCURRENT_WITH_SELF` (feel free to bikeshed on the name).
Many tests which use resources (primarily writing to paths on the
filesystem) are not parameterized over the invokation number of the run.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] RfD: deprecate link_directories() and link_libraries()

[Ben Boeckel]

On Tue, Aug 21, 2018 at 09:14:37 +0200, Gregor Jasny via cmake-developers wrote:
> How would one deal with '#pragma comment lib' w/o link_directories()?

I usually disable it with `-DBOOST_ALL_NO_LIB` (for Boost). In addition,
I find them to be not useful because Boost library names change between
static and shared (so they can live beside each other) and if you don't
set the preprocessor definitions right, they're not going to even use
the right filename anyways. Easier to just turn off autolinking and have
CMake do the right thing.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] How to obtain a list of target dependencies

[Ben Boeckel]

On Mon, Mar 12, 2018 at 15:11:28 -0500, Robert Dailey wrote:
> I'm going to add the CMake Dev group as well, since I asked this same
> question last year around May and I didn't get any response. Hoping
> for some help this time around. I don't see anything documented, so
> maybe the developers know the best approach here.

There's an issue for this here:

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

There has been extensive discussion on the feature and previous mailing
list threads about it. I'm not intimately familiar with that discussion
myself, but it has more details at least.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cmake-server question

[Ben Boeckel]

On Wed, Feb 14, 2018 at 19:19:39 +0100, Paweł Rutka wrote:
> I would like to ask about some important feature:
> Is there any possibility to provide form Cmake Server side location of
> command that generate the target? The Use Case is as follow:
> In IDE you want  to, after Class creation, automatically add CPP file into
> proper add_executable or extend some variable passed to  add_executable or
> any other case that lead to target creation.

Note that this is a very hard problem. Take the following examples:

===
add_executable(myexe a.c b.c)
===

===
set(sources a.c b.c)
add_executable(myexe ${sources})
===

===
set(sources a.c b.c)

add_subdirectory(foo) # does a `set(sources PARENT_SCOPE)`

add_executable(myexe ${sources})
===

===
set(sources a.c b.c)

if (some_option)
  list(APPEND sources c.c)
endif ()

add_executable(myexe ${sources})
===

===
set(sources a.c b.c)

add_executable(myexe ${sources})
set_property(TARGET myexe APPEND SOURCES d.c)
===

What would the IDE be expected to do for each of these cases?

Personally, I think it would be best to just get where the target is
declared. This should have a backtrace available so that this pattern is
supported:

===
function (wrap_add_library)
add_library(${ARGN})
# Project-specific bits.
endfunction ()

# Somewhere else...
wrap_add_library(mylib STATIC ...)
===

Once the main location is found, I think just having the "your cursor is
on FOO, I'll highlight other instances of FOO" feature should be enough
to get one to the right place.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake_format

[Ben Boeckel]

On Wed, Feb 07, 2018 at 13:27:28 +0100, Cristian Adam wrote:
> I don't remember seeing this tool advertised on the CMake mailing lists:
> 
> https://github.com/cheshirekow/cmake_format/tree/master/cmake_format

Cool! I have some feature requests, but I'll add them over there :) .

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding backtraces to every command

[Ben Boeckel]

On Wed, Jan 31, 2018 at 18:53:39 +, Rich Chiodo via cmake-developers wrote:
> We're (Microsoft) investigating tighter integration with CMake -Server
> and the IDE.
> 
> One of the things we need is to be able to get the location of where a
> property is set.
> 
> CMake has a backtracing capability but it looks to me like properties
> don't actually keep track of their set location.
> 
> I think the easiest way for me to do this would be to add a backtrace
> to every command execute (not 100% sure yet), but I wanted to query
> the alias for advice
> 
>   1.  Is this a good approach for getting the location of every Set,
>   Link_Libraries, etc?

I don't think it'd be sufficient. What would the backtrace for the
`custom_prop` variable be in this case?

b/CMakeLists.txt:

add_library(foo ...)
set_property(TARGET foo PROPERTY custom_prop value1)

c/CMakeLists.txt (later):

set_property(TARGET foo APPEND PROPERTY custom_prop value2)

There could be multiple backtraces for each property and when it is
overwritten or deleted, should the previous backtraces be cleared out?
If appending was done manually using get_property(), list(APPEND), and
set_property() that approach would toss information out.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Undocumented command line flags (-H, -B) why?

[Ben Boeckel]

On Tue, Jan 16, 2018 at 14:42:32 +0100, Cristian Adam wrote:
> I don't know why it wasn't a pull request on gitlab though.

> Thu, 30 Jun 2016 12:24:02 -0700

This predates Gitlab usage for patch submission (which started around
July 2016).

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Undocumented command line flags (-H, -B) why?

[Ben Boeckel]

On Tue, Jan 16, 2018 at 13:10:07 +0100, Eric Noulard wrote:
> I came accross -H and -B undocumented command line flags for cmake:
> https://stackoverflow.com/questions/24460486/cmake-build-type-not-being-used-in-cmakelists-txt/24470998#24470998
> 
> Is there any reason to keep those undocumented?

They're internal and not meant for use outside of CMake itself. There
have been threads on this before. Here's one with a patch to document it
that was rejected as-is:

https://www.mail-archive.com/cmake-developers@cmake.org/msg16693.html

For those who want to submit a patch, there's a TODO list here:

https://www.mail-archive.com/cmake-developers@cmake.org/msg16720.html

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] kwsysProcess threadsafety

[Ben Boeckel]

On Fri, Jan 05, 2018 at 20:34:53 +0100, Sebastian Holtermann wrote:
> 2) Use libuv instead

libuv for process management is on the list. I think it is waiting for
porting to all of CMake's platforms to actually happen. I'm seeing this
PR hung up on process:

https://github.com/libuv/libuv/pull/1527

I don't know how much followup work there is. I thought there was a
CMake issue tracking it, but I don't see one.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Build failure due to {cd bindir} failed on Windows/Ninja

[Ben Boeckel]

On Fri, Dec 29, 2017 at 13:32:54 -0800, Jom O'Fisher wrote:
> >> Ninja should be using relative paths for the build tree and absolute
> for anything outside of it.
> That appears to be the case, so I need a better theory. I noticed another
> difference between compilation phase and link phase. The link phase is
> bracketed by cmd.exe /C "cd . &&  && cd .".
> I'm wondering problem those "cd ." calls are solving? Their presences is
> what's causing everything to be wrapped in "cmd /C"

They're the "no-op" of the PRE_LINK and POST_LINK commands for targets.

> Here's the error that encapsulates the failure
> 
> CMake Error at D:/Android/sdk/cmake/3.6.3155560/share/cmake-3.6/
> Modules/CMakeTestCCompiler.cmake:61 (message):
>   The C compiler
>   "D:/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/
> windows-x86_64/bin/clang.exe"
>   is not able to compile a simple test program.
>   It fails with the following output:
>Change Dir: D:/src/MyApplication/app/.externalNativeBuild/cmake/
> debug/armeabi/CMakeFiles/CMakeTmp
> 
>   Run Build Command:"D:\Android\sdk\cmake\3.6.3155560\bin\ninja.exe"
>   "cmTC_0dcd8"
>   [1/2] Building C object CMakeFiles/cmTC_0dcd8.dir/testCCompiler.c.o
>   [2/2] Linking C executable cmTC_0dcd8
>   FAILED: cmd.exe /C "cd .  &&
>   D:\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\
> windows-x86_64\bin\clang.exe
>   --target=armv5te-none-linux-androideabi
>   --gcc-toolchain=D:/Android/sdk/ndk-bundle/toolchains/arm-
> linux-androideabi-4.9/prebuilt/windows-x86_64
>   --sysroot=D:/Android/sdk/ndk-bundle/sysroot -isystem
>   D:/Android/sdk/ndk-bundle/sysroot/usr/include/arm-linux-androideabi
>   -D__ANDROID_API__=14 -g -DANDROID -ffunction-sections -funwind-tables
>   -fstack-protector-strong -no-canonical-prefixes -march=armv5te
>   -mtune=xscale -msoft-float -fno-integrated-as -mthumb -Wa,--noexecstack
>   -Wformat -Werror=format-security -Wl,--exclude-libs,libgcc.a --sysroot
>   D:/Android/sdk/ndk-bundle/platforms/android-14/arch-arm -Wl,--build-id
>   -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined
>   -Wl,-z,noexecstack -Qunused-arguments -Wl,-z,relro -Wl,-z,now
>   -Wl,--gc-sections -Wl,-z,nocopyreloc
>   CMakeFiles/cmTC_0dcd8.dir/testCCompiler.c.o -o cmTC_0dcd8 -lm && cd ."
>   clang.exe: error: no such file or directory:
>   'CMakeFiles/cmTC_0dcd8.dir/testCCompiler.c.o'
>   ninja: build stopped: subcommand failed.

You can pass `--debug-trycompile` to keep the output of the try compile
step. Running the command manually may help to narrow down the problem.
The tools mentioned here may also help:

https://stackoverflow.com/questions/3847745/systrace-for-windows

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Build failure due to {cd bindir} failed on Windows/Ninja

[Ben Boeckel]

On Thu, Dec 28, 2017 at 12:51:20 -0800, Jom O'Fisher wrote:
> (1) Invoke cmake to generate ninja project. Success.
> * Note that generated rules.ninja has .o compilation dependencies with
> absolute paths and .so link dependencies with relative paths.

Ninja should be using relative paths for the build tree and absolute for
anything outside of it.

> (3) CMake changes tries to change it's working directory here:
> https://github.com/Kitware/CMake/blob/08ce62bee5bee6805fbb01c1821c43
> 8028e858dc/Source/cmGlobalGenerator.cxx#L1811

What would cause `ChangeDirectory` to fail? Is there some non-ASCII in
the directory path?

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] PLplot contract test

[Ben Boeckel]

On Wed, Nov 08, 2017 at 12:39:15 -0800, Alan W. Irwin wrote:
> software@raven> time (nice -19 ctest -S 
> ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16)
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> 
> The only thing I can find in ctest.out16 corresponding to these
> warnings is
> 
> 264: application-specific initialization failed: couldn't connect to display 
> "localhost:10.0"
> 264: Error in startup script: couldn't connect to display "localhost:10.0"

The Xauthority file is not available to the nightly build job. You can
share it using the XAUTHORITY environment variable and putting it in a
place that both the user running the X server and the job know about and
can access.

See also the `xhost` tool for managing the file itself. You may need to
authorize other users to use the X server, but I've only needed that for
a setup here where the host provides a VNC server for a Docker image to
use (which also needs cross-host authentication allowances).

--Ben
-- 

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 PCH Prototype

[Ben Boeckel]

On Sat, Sep 02, 2017 at 12:15:28 +0200, Máté Ferenc Nagy-Egri via 
cmake-developers wrote:
> Do I understand correctly, that this work is not going to be
> mainlined? I was very much hoping it would.

Development stalled. We close MRs which need work and haven't been
actively developed in order to keep the MR queue free of stalled work
(that is what `workflow:expired` indicates). When work is ready to
continue, it can be reopened.

--Ben
-- 

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] C++11 all features available?

[Ben Boeckel]

On Mon, Aug 21, 2017 at 15:53:11 +0200, Sebastian Holtermann wrote:
>  - std::array

I don't see why not.

>  - std::basic_regex (and friends)

Note that we require backwards compat with the old regex engine, so this
one needs to be used carefully and only on internal uses.

>  - std::thread (and friends)
>  - std::atomic_flag

CMake uses threads? ;)

--Ben
-- 

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] List of commands

[Ben Boeckel]

On Thu, Aug 17, 2017 at 14:34:27 -0300, Ivam Pretti wrote:
> Hi there I am new at coding with cmake and I would like to know if there is
> a list of commands avaiable. Thanks anyway.

The cmake-commands(7) manpage has a listing of the builtin commands.
They're also available in the HTML documentation:

https://cmake.org/cmake/help/latest/manual/cmake-commands.7.html

--Ben
-- 

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] Undocumented change in behavior in cmake 3.9.X (SWIG)

[Ben Boeckel]

On Thu, Aug 17, 2017 at 17:41:35 +0930, Simon Lees wrote:
> We at openSUSE have noticed a change in behavior presumably in
> swig_link_libraries in one package cproton_perl.so is now being
> generated rather then libcproton_perl.so I presume the lines generating
> the library are below (I am not familiar with the package)
> 
> swig_add_module(cproton_perl perl perl.i)
> swig_link_libraries(cproton_perl ${BINDING_DEPS} ${PERL_LIBRARY}
> -lpthread -lm)
> 
> changing to the non depreciated swig_add_libraries caries this same
> change. I have a full build log available at [1] and a build on my
> system should you require more info.
> 
> I guess the question we have is was this change intentional and
> accidentally undocumented (unless I missed it) or is there a deeper
> issue with cmake that needs fixing here.

Looks like it was added here:

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

as part of this commit:


https://gitlab.kitware.com/brad.king/cmake/commit/8ed663791bdda4e726f7b3764bc75f8856724d6f

--Ben
-- 

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] Future of ccmake and cmake-gui

[Ben Boeckel]

On Wed, Aug 16, 2017 at 23:02:52 +0200, Jean-Michaël Celerier wrote:
> @Ben Boeckel :
> > The idea for process creation is to migrate to libuv once all of the
> dependencies are supported.
> Quick question : why not asio instead ? it's bound to end up in the
> standard library at some point (e.g.
> https://github.com/chriskohlhoff/networking-ts-impl) and already has an
> event loop.

CMake uses curl for networking (all sync), but libuv was added for the
server mode's event loop. It also comes with process execution, some
filesystem helpers and other things that kwsys does today that we can
drop once we move to it. AFAICT, asio looks like it's mostly a
networking library and doesn't overlap well with libuv and CMake's
requirements.

> Or even Qt's event loop since it's already here.

Qt isn't required by core CMake, just cmake-gui.

--Ben
-- 

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] Future of ccmake and cmake-gui

[Ben Boeckel]

On Wed, Aug 16, 2017 at 09:16:24 -0700, Eric Wing wrote:
> It has native backends for Windows, GTK2, GTK3, Motif, Haiku. Because
> it historically didn't have a Mac OS X backend, most people overlooked
> it. However...I've been implementing a native Mac OS X backend. It's
> not finished, but there is a lot implemented and I'm actually shipping
> a simple app with it this week. Since CMake's GUI usage is also pretty
> simple, I *think* there might already be enough implemented to do the
> CMake-GUI...or it's close enough that I probably could finish those
> needed features.

How easy is it to ship binaries which work on any platform without also
shipping all of the necessary platform backends as well?

> Now IUP only does GUI (which is another reason it stays small), so you
> will need to fill in the JSON and Process requirements. But there are
> tons of JSON libraries. Off the top of my head, cJSON is a really
> fast, tiny, and simple to use JSON library. It's a single C file and
> header, so you can drop it right in the project. (Also MIT). It also
> has a CMake build system if you really want it.

There's already a JSON library in CMake: jsoncpp.

> And a cross-platform create process...those I've seen everywhere and
> I've actually written my own too. I think Apache Runtime is only
> measured in hundreds of kilobytes even with all the stuff you don't
> need.
> A quick Google search turned up this one C++ (MIT)
> https://github.com/eidheim/tiny-process-library

The idea for process creation is to migrate to libuv once all of the
dependencies are supported. Looking at the implementation here it
is…naïve at best. It uses `sh -c` instead of `exec` to do its work which
means that CMake would need to do manual pipe management anyways.

--Ben
-- 

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] Future of ccmake and cmake-gui

[Ben Boeckel]

On Tue, Aug 15, 2017 at 22:33:04 +0200, Daniel Pfeifer wrote:
> 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.

Well, not sure that I want *100%* compatible with ccmake if we're
rewriting bits of it; there are lots of improvements that could be made
;) .

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

The make_shared function is there, but make_unique is missing in C++11.

--Ben
-- 

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: [CMake] cmake-gui on windows and qt5 dlls

[Ben Boeckel]

On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote:
> It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but
> as reported on the CMake users mailing list, it can be a problem when the
> directory cmake-gui is in is on the PATH. If CMake's bin directory appears
> on the PATH, the Qt DLL's bundled with it can take precedence over other
> applications' own Qt DLLs. The cmake and ccmake executables have a
> reasonable case for being on the PATH, but cmake-gui is typically going to
> be started via a desktop or menu icon and doesn't really need to be on the
> PATH.
> 
> Rather than forcing static Qt libs to be used (I'm not aware of the reason
> for the change from static to dynamic Qt libs), we could instead move
> cmake-gui out of the bin directory so that it isn't in the same directory
> as the cmake and ccmake executables. This top level directory should never
> be added to the PATH, so it would resolve problems like the above. It is
> not unusual for the main executable to be in the top level directory of an
> installation rather than in a bin subdirectory. What do people think of
> moving cmake-gui and the Qt DLL's up to the top level? This may just be for
> Windows, other platforms could stay as they are now. Would obviously have
> to adjust not just the install location but also any internal code that
> tries to work out where other files are located relative to the cmake-gui
> executable. Things like the qt.conf file would also probably need some
> adjustment.
> 
> Thoughts?

Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH.
Then the structure doesn't need to change either.

--Ben
-- 

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] Signing of DEB and RPM packages

[Ben Boeckel]

On Tue, Jul 25, 2017 at 17:43:03 +0200, Roman Wüger wrote:
> is the signing of DEB packages (debsigs) and RPM packages (rpmsign or
> rpm --addsign) supported at the moment?

It doesn't appear to be supported right now (no results from grep'ing
for "debsig" or "addsign").

--Ben
-- 

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] FindPNG.cmake doesn't return a LIBRARY_DIR variable

[Ben Boeckel]

On Wed, Jul 12, 2017 at 14:22:40 +0200, Rolf Eike Beer wrote:
> First, FindPNG.cmake doesn't care about pkg-config files, if that is bug 
> or feature depends on your personal things. CMake will detect the 
> library using the full path (as it has done), and construct proper -L 
> and -l from that.

CMake prefers using full paths to libraries it finds, so I don't think
it would turn a full path into a `-L` and `-l` flag pair.

--Ben
-- 

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] Making your regular expression engine more reliable

[Ben Boeckel]

On Thu, May 18, 2017 at 12:44:57 -0700, Alan W. Irwin wrote:
> So your unit tests for regular expressions obviously missed at least
> this issue. I have no idea what those unit tests are (or even if they
> exist), but one possibility for attempting to wring most of the bugs out
> of your regular expression processor is to adapt some other project's
> regexp test suite. See
> 
> for a rather large list of such test suites.

This would be a great addition to CMake and would help with a future
replacement to ensure that we are compatible with what is being used
now.

> Another possibility is simply to forget supporting your own regexp
> engine and adopt someone else's very well regarded regexp engine (such
> as libprng).  I vaguely recall that has been suggested before, but
> since that hasn't happened I presume inertia or NIH syndrome won or
> else there was some strong reason why you didn't go that route.

This has been brought up before. The regex engine used in CMake is *old*
and, after my performance fixes a few years ago, is (or, at least, was)
near the top of that list for various reasons.

The biggest problem facing a replacement is the backwards compatibility.
Do we want to just use a standard set of features (C++14?) and break
unknown number of `MATCHES` expressions? This would require a policy and
the old code would still lurk so that we can support the OLD policy.

Or do we translate from what we support now into a standard language and
then use another engine for that? This is probably the better solution
for CMake, but is probably more code than the current engine.

> From my perspective as a strongly interested CMake user (but not a
> CMake developer or regexp guru) that wants a completely reliable
> regular expression engine for CMake, I don't care which of these two
> approaches you use to achieve that goal.  But I hope my starting
> this topic here will facilitate reaching that goal.

I understand the want for a better engine, but just replacing it
outright isn't really an option.

Thanks,

--Ben
-- 

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] Compile targets affected by changeset

[Ben Boeckel]

On Thu, May 18, 2017 at 17:48:26 -0400, Robert Patterson via cmake-developers 
wrote:
> 'make' has a limitation where if 'make target1 target2 target3' is
> invoked, target1, target2, and target3 are built serially, not in
> parallel.

Well, this makes sense since there's no `-j` flag given. Are you passing
a `-j` flag to make too?

>   To get around this, we decided that the best option was to
> dynamically create a new [cmake] target which depends on the affected
> targets. This is where we could use some guidance as we have two
> possible approaches: 1. This could either be implemented in cmake
> code; by supplying a command line argument, specifying the "dynamic"
> target which in turn would create a target during the generation
> process. 2. Explicitly specify the "dynamic" target in our project's
> CMakeLists.txt file, and allow cmake to simply add the affected
> targets as a dependency to the dynamic target.

Have you considered using the Ninja generator? It does have dependency
information right from the compiler (via the `-M` flag family).

--Ben
-- 

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] Does JOB_POOL_[COMPILE|LINK] work with custom_target?

[Ben Boeckel]

On Mon, May 15, 2017 at 11:46:37 +0200, Eric Noulard wrote:
> No answer whatsoever on this?

I don't think it is supported right now.

> I'd like to be able assign some custom targets to a ninja job pool.
> If I were to implement the feature would it be acceptable upstream ?

I think it'd be fine.

--Ben
-- 

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

[Ben Boeckel]

On Wed, May 10, 2017 at 17:56:07 +0300, Egor Pugin wrote:
> 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?

What is the use case? CMake does not ship an SDK to link against, so
presumably this is something going into CMake itself?

--Ben
-- 

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] Trouble with FindPNG module

[Ben Boeckel]

On Mon, Apr 24, 2017 at 19:58:52 +0100, Roger Leigh wrote:
> While you can install as many of the runtime packages as you like, the 
> headers go into /usr/include and so they conflict with each other, 
> limiting you to a single development package at one time (checked the 
> behaviour to verify this, and installing one triggers removal of any 
> existing variant).  Not itself a multiarch limitation--many packages now 
> use /usr/include/ for this reason--but certainly a limitation in 
> the packaging of the current libpng, which for some reason hasn't yet 
> started using arch-specific headers.

Hmm, odd. Coming from RPM, it copes with multiple -devel packages all
writing directly to `/usr/include` as long as the headers themselves are
the same on all architectures (and, IIRC, binaries are decided based on the
"preferred" architecture of the host in case of conflicts). Oddities in
packaging formats I suppose :) .

--Ben
-- 

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] Trouble with FindPNG module

[Ben Boeckel]

On Mon, Apr 24, 2017 at 19:17:39 +0100, Roger Leigh wrote:
> Sounds like that's exactly the problem.  You can only have one libpng 
> *development* package installed at once.  You probably want the regular 
> "libpng-dev" package installed if you want to build against the standard 
> libpng.

Ah, this is before the multiarch split from Debian came into Ubuntu? I'm
so used to Red Hat's lib64 split (multilib) (which, admittedly, has its
drawbacks in light of multiarch).

--Ben
-- 

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] Trouble with FindPNG module

[Ben Boeckel]

On Mon, Apr 24, 2017 at 12:20:27 -0500, Robert Dailey wrote:
> -- The C compiler identification is GNU 4.9.4
> -- The CXX compiler identification is GNU 4.9.4
> -- Check for working C compiler: /usr/bin/gcc-4.9
> -- Check for working C compiler: /usr/bin/gcc-4.9 -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/g++-4.9
> -- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done

Does the information in the CMakeFiles/$cmake_version directory contain
anything indicating that it's detecting the compiler as 64-bit?

> I'm not sure how to use strace. I tried following instructions I found
> on the [CMake Performance Tips][1] page, but this isn't working. My
> generate command has a lot of options, so I use a helper shell script
> to generate. strace seems to not work well when using a shell script.
> Trace also doesn't show much useful. Could you give exact command line
> I can run to get the info you need?

Sorry, it's such a common tool I use, I forget others are new to it :) .
Here's how I'd use it to debug this:

strace -s 1 -e file -o cmake.strace.log $cmake_command

If your cmake command is a script that later launches CMake, you can
give strace `-f` to have it also trace any child processes made by the
command. In the resulting log file, you'll see syscalls CMake is making.
searching for the png header/library searching area shouldn't be too
hard. Is it looking in anything resembling the right paths?

--Ben
-- 

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] Trouble with FindPNG module

[Ben Boeckel]

On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey  
> wrote:
> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
> >
> > find_package(PNG REQUIRED)
> >
> > Which gives me the output in CMake:
> >
> > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
> >
> > The CMakeCache.txt file has these variables set:
> >
> > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
> > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
> > PNG_PNG_INCLUDE_DIR:PATH=/usr/include
> >
> > So it found the headers, but not the libs. Why did it not find the
> > libs? Note that my version of Ubuntu is 64-bit, and I've installed the
> > 32-bit libs like so:
> >
> > $ sudo apt-get install libpng12-dev:i386

What compiler are you using (what does CMake say it is?)? Does an
`strace` of CMake configuring the project show anything interesting?
`cmake --trace-expand`?

--Ben
-- 

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 unified headers in Android NDK

[Ben Boeckel]

On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
> Google is supporting unified headers for sysroot as of NDK r14:
> 
> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
> 
> Is there a plan to add support for this natively into CMake?

There is a merge request that is in-progress, but was closed due to
inactivity (lack of time on Florent's side it seems). I'd recommend
coordinating with Florent to resurrect the MR.

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

--Ben
-- 

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] Feature suggestion: auto-create missing files

[Ben Boeckel]

On Tue, Apr 11, 2017 at 21:28:40 +0200, Alexander Neundorf wrote:
> personally I'm not convinced.
> Technically it would violate the "the source dir is read-only" rule.
> A typo would generate files. With multiple build dirs the behaviour will be 
> slightly different in the two dirs.
> ...not very strong arguments, but OTOH touching the file manually is also not 
> too complicated.

On case-insensitive file systems, there's also the "what if it exists,
but not with matching case?" problem. What was intended. Sure, CMake
will currently just leave it alone, but does the file exist? Is the file
on disk a typo? I don't think CMake can make that decision.

--Ben
-- 

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] Feature suggestion: auto-create missing files

[Ben Boeckel]

On Tue, Apr 11, 2017 at 11:52:52 -0400, Brad King wrote:
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.

This is already an issue here:

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

I have a branch which needs lots of work to be rebased properly; I can
dig it up if anyone is interested in taking it over before I get to it.

--Ben
-- 

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

[Ben Boeckel]

On Mon, Feb 13, 2017 at 20:18:02 -0700, Justin Berger wrote:
> I agree on the maximizing code reuse, but that doesn't require them to use
> the same operational mode -- the two modes do fundamentally different
> things; even while sharing most internal components. Is the idea that you
> could only start a debug session if you have cmake-server running, and then
> you instruct it to configure?

What about debugging CMake `-P` scripts? Or does server-mode not work in
script mode?

--Ben
-- 

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] Eclipse CDT Managed build

[Ben Boeckel]

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

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

--Ben
-- 

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] Eclipse CDT Managed build

[Ben Boeckel]

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

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

--Ben
-- 

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] Eclipse CDT Managed build

[Ben Boeckel]

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

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

--Ben
-- 

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] Eclipse CDT Managed build

[Ben Boeckel]

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

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

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

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

--Ben
-- 

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] CMAKE_DL_LIBS: fix typo

[Ben Boeckel]

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

Thanks, I've pushed up an MR here:

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

--Ben
-- 

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] Requesting Advice: Installing object files

[Ben Boeckel]

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

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

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

--Ben
-- 

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] Requesting Advice: Installing object files

[Ben Boeckel]

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

This issue might be the best way to go:

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

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

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

--Ben
-- 

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] COMPILE_FEATURES, Mac and non-Apple clang versions

[Ben Boeckel]

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

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

--Ben
-- 

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] import another compiler to cmake

[Ben Boeckel]

On Wed, Dec 21, 2016 at 13:00:29 +0100, Payam Samimi wrote:
> I'm working for a big company in Germany as software developer. They
> develope their code and test modules in c++ and using CMake. Additionally
> they use their own compiler which is company specific and they would like
> import or connect their own compiler to CMake, that Cmake can use it. So,
> this is my task, and I would like to ask you whether you have any
> suggestion that could help me.

Adding a compiler to CMake is possible, but in order to ensure that it
continues to work, a nightly dashboard would be helpful to catch any
problems changes introduce for the compiler. Instructions for setting up
a dashboard are here:

https://cmake.org/Wiki/CMake/Git/Dashboard

To actually add support, it would need to be added to the detection
logic under the `Modules/Compiler` directory and to the
`Modules/CMakeCompilerIdDetection.cmake` module. Docs would also be
necessary.

There also may be more, but that is a minimum. Brad knows much more, but
is currently on vacation until the second week in January.

Thanks,

--Ben
-- 

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] not able to push topic to stage

[Ben Boeckel]

On Tue, Dec 20, 2016 at 17:50:02 +0100, Domen Vrankar wrote:
> Has anything changed regarding how topics should be pushed to stage and
> then to next for testing?
> 
> When following what's written here: https://cmake.org/Wiki/CMake/Git/Develop
> I get a git hook error:
> 
> remote:
> --
> remote: denying cpack-deb-version-override-fix (64e9c38d) which contains
> deny/topics/next (66805932)
> remote:

Your branch contains `next` in it. This is not allowed since your branch
would then bring in all of the history `next` has into `master`.

Are you trying to update your topic on `next`? Or base your branch on
top of something on on `next`?

--Ben
-- 

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] Add native options to the clean step of 'cmake --build .. --clean-first'

[Ben Boeckel]

On Fri, Dec 16, 2016 at 09:46:22 +0100, Yves Frederix wrote:
> Although I am not fully convinced that the above might actually happen
> in 'normal' practice, I do agree that it is a risk that should not be
> introduced simply to get less verbose output for the clean step (my
> use case). Pulling the PR ;) Thanks for your insights!

If that is what you want, a `clean-quiet` target might be more useful
which then uses generator-specific flags. This could even be a separate
`--quiet` flag for `cmake --build` which would then apply to both the
build and clean step.

--Ben
-- 

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 vs libtool versioning of shared libraries

[Ben Boeckel]

On Thu, Dec 15, 2016 at 14:08:35 -0500, Brad King wrote:
> On 12/15/2016 01:57 PM, Kim Walisch wrote:
> > Lets suppose I do not want to stick to my previous libtool versioning
> > but instead version my library according to cmake best practices. How
> > should I set VERSION and SOVERSION given my API version is 3.5 and my
> > old ABI version 4:7:0. By browsing a few CMakeLists.txt on GitHub of
> > other projects it seems to me that most of these projects set VERSION
> > to the project/API version (e.g. 3.5) and the SOVERSION to the
> > project/API major version (e.g 3).
> 
> The VERSION is only for human reference and so can be the project
> version or anything else.  The SOVERSION is what provides the
> API version level.  A binary linked to your library will at runtime
> look for "libfoo.so.$soversion", and any file the dynamic loader
> can find with that name is considered acceptable.  Therefore the
> SOVERSION should be used for API versioning.  If you remove an
> API then the soversion should be changed.
> 
> The project version and API version don't have to be related,
> but it is a common convention depending on API stability.

Note that this is actually ABI compatibility, not API (i.e.,
source-level) compatibility.

Adding virtual methods, reordering struct members, changing struct
sizes, etc. all require a SOVERSION bump upon release, but are not
necessarily API breaks. KDE has a list of things which change the ABI
for C++ here:

https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

It does not look to have been updated for C++11, so things which affect
`auto` deduction may also cause ABI incompatibilities.

--Ben
-- 

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] Add native options to the clean step of 'cmake --build .. --clean-first'

[Ben Boeckel]

On Wed, Dec 14, 2016 at 21:26:13 +0100, Yves Frederix wrote:
> In PR https://gitlab.kitware.com/cmake/cmake/merge_requests/329 I am
> suggesting to not only pass the additional/native build options to the
> actual build step, but also to the 'clean' step in case of a call like
> `cmake --build ... --clean-first`. The change is simple enough, but
> there is the risk that a 'make clean' does not accept the additional
> build options that for a normal build are ok, which could cause a
> build to fail. Hence, I would like to check with the devs on this list
> to judge the actual risk of this PR.
> 
> Brad suggested to check the git logs to see if I could find something
> there. I tracked things down to d35651fb in which the additional build
> options were added.to the Build() function. It seems that already from
> the beginning, the additional options were only passed to the build
> step itself and not to the clean step. Whether there was a reason for
> this is unclear from the logs.
> 
> My question now is whether somebody remembers if there indeed was a
> particular reason to leave out the additional options from the 'make
> clean' call? And if not, could you come up with a real example in
> which case the proposed change would cause a build failure? I have
> tried, but wasn't able to come up with anything, although I must admit
> that my view is limited as I do not have much experience with non-VS
> generators.

Flags for other generators can cause the `clean` to not actually happen.
For example, with make `cmake --build ... --clean-first -- -i` can cause
the clean to silently fail and then it isn't really a clean build. Or
the `-t` flag which skips running commands and instead just touches
output files. `-n` just prints what would be done. Or a target is passed
and so you effectively have `make clean -j10 mytarget; make -j10
mytarget` which could be interesting with the `mytarget` subgraph making
files while `clean` is going around deleting them again.

IMO, these flags being passed to `--clean-first`'s subtask can
completely invalidate what is being asked for and it makes sense that
`--clean-first` is really just a plain clean.

--Ben
-- 

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] Specifying sources without file extensions

[Ben Boeckel]

On Thu, Dec 08, 2016 at 08:01:03 -0500, Brad King wrote:
> On 12/08/2016 01:41 AM, Craig Scott wrote:
> > file names without extensions is a feature which is simply missing
> > documentation or is it an undocumented feature that projects are not
> > supposed to use? Since there are error messages like the above, it
> > would seem that the latter would be a harder position to justify.
> 
> It is an ancient legacy behavior from CMake's earliest days when it
> was only used for C++ projects with lists of "classes" where each
> was expected to have a source and header file.  The behavior should
> be removed with a new policy, but no one has actually done that yet.

See https://gitlab.kitware.com/cmake/cmake/issues/15208 for the actual
issue for adding the policy.

--Ben
-- 

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 workflow with gitlab

[Ben Boeckel]

On Mon, Oct 31, 2016 at 19:26:19 +0100, Gregor Jasny via cmake-developers wrote:
> I wonder what's the recommended workflow for CMake developers with
> commit access to stage? I'd like to use feature branches in gitlab but
> wonder how those are best merged into 'next'?
> 
> Could you please advise or point me to some documentation?

The stage is still separate, so pushing to Gitlab is best for review and
discussion. In the coming weeks, there will be a tool to manage the
stage from within Gitlab (obsoleting the old stage).

--Ben
-- 

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] Java_INCLUDE_DIRS not populated by FindJava.cmake

[Ben Boeckel]

On Mon, Oct 17, 2016 at 15:32:06 +1100, Craig Scott wrote:
> In case anyone is wondering, the use case for me is when implementing a
> SWIG custom command to generate java wrappers, the jni.h header needs to be
> found by the generated sources.

There's FindJNI for that.

--Ben
-- 

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

[Ben Boeckel]

On Tue, Aug 23, 2016 at 08:00:09 +0200, Rolf Eike Beer wrote:
> Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott:
> > So how would you want the feature to work? I'd suggest an initial set of
> > requirements something like the following:
> > 
> >- Need to support the ability to define multiple setup and/or tear down
> >tasks.
> >- It should be possible to specify dependencies between setup tasks and
> >between tear down tasks.
> >- Individual tests need to be able to indicate which setup and/or tear
> >down tasks they require, similar to the way DEPENDS is used to specify
> >dependencies between test cases.
> >- When using ctest --rerun-failed, ctest should automatically invoke any
> >setup or tear down tasks required by the test cases that will be re-run.
> >- Setup or tear down tasks which reference executable targets should
> >substitute the actual built executable just like how add_custom_command()
> > does.
> 
> -need a way to mark if 2 tests with the same setup/teardown can share those 
> or 
> if they need to run for every of them

Proposal:

add_test(NAME setup-foo ...)
set_tests_properties(setup-foo PROPERTIES
  SETUP_GROUP foo
  SETUP_STEP SETUP_PER_TEST) # Also SETUP_ONCE.
add_test(NAME use-foo ...)
set_tests_properties(use-foo PROPERTIES
  SETUP_GROUP foo) # implicit depends on all SETUP_GROUP foo / SETUP_STEP 
SETUP_* tests.
add_test(NAME use-foo2 ...)
set_tests_properties(use-foo2 PROPERTIES
  SETUP_GROUP foo)
add_test(NAME teardown-foo2 ...)
set_tests_properties(teardown-foo2 PROPERTIES
  SETUP_GROUP foo
  SETUP_STEP TEARDOWN) # implicit depends on all non-TEARDOWN steps

Multiple setup/teardown steps could be done with DEPENDS between them.

> -the default for each test is "no s/t", which means it can't be run with any 
> of the above in parallel (especially for compatibillity)[1]
> -need a way to tell if a test doesn't care about those

Making RESOURCE_LOCK a rwlock rather than a mutex might make sense here.
SETUP_STEP bits have a RESOURCE_LOCK_WRITE group_${group}, otherwise it
is RESOURCE_LOCK_READ group_${group}.

> 1) think of a database connector test: the test that will check what happens 
> if no DB is present will fail if the setup step "start DB" was run, but not 
> the teardown

RESOURCE_LOCK on that group_${group} can fix that I think.

> > Some open questions:


I agree with what Eike said.

--Ben
-- 

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] Use full path for all source files in ninja build.

[Ben Boeckel]

On Sun, Aug 07, 2016 at 04:54:52 +0200, Florent Castelli wrote:
> I'd say that you shouldn't do this unless you have tested it extensively 
> with very long command lines, making sure that there is a response file 
> fallback if it grows too much.
> There are issues in CMake already on Windows with long command lines and 
> having even longer ones is not going to help.

Agreed. RC files compilation already has issues in some projects without
absolute paths as is.

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

--Ben
-- 

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] Use full path for all source files in ninja build.

[Ben Boeckel]

On Wed, Aug 03, 2016 at 11:11:45 -0700, Chaoren Lin wrote:
> Also, in the case of vim, the makeprg is user-supplied, so vim has no idea
> that it contains a path.

What about instead of "cd path && ninja", using "ninja -C path"?

--Ben
-- 

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] Use full path for all source files in ninja build.

[Ben Boeckel]

On Tue, Aug 02, 2016 at 11:11:44 -0700, Chaoren Lin via cmake-developers wrote:
> Similarly, the :make command in vim will have no knowledge of build.gradle,
> and only tries to parse the build errors directly.

FWIW, I haven't encountered any problems with Vim's :make with CMake's
generated Ninja files in out-of-source builds for in-source or generated
files (I almost never do in-source builds).

--Ben
-- 

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] Strange behaviour with check_library_exists on Windows

[Ben Boeckel]

On Thu, Jul 28, 2016 at 13:33:35 +0300, Sergei Nikulov wrote:
> -- Looking for CertFreeCertificateContext in crypt32;
> -- Looking for CertFreeCertificateContext in crypt32; - found
> crypt32 found

These are tested using try_compile. Is there anything interesting under
CMakeFiles/CMakeTmp/* when you configure with --debug-trycompile? It
should contain the example files used and output from the compiler.

Thanks,

--Ben
-- 

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] Autogen subdirectories patches

[Ben Boeckel]

On Tue, Jul 26, 2016 at 23:38:34 +0200, Sebastian Holtermann wrote:
> Doing so I found that Base64 allows '+' and '/' as characters which is 
> bad for directory names obviously.
> For now these characters get replaced with 'A' and 'B'.

'_' and '@' would be better replacements (with comments why they are
used) since 'A' and 'B' are already characters in Base64.

> +// unexpected hexchar

This raise an internal error, not just be a comment.

> +  }
> +}
> +hashBytes[ii] = hbyte[0] | (hbyte[1] << 4);
> +  }
> +}
> +// Convert hash bytes to Base64 text string
> +{
> +  std::vector base64Bytes(hashBytes.size() * 2, 0);
> +  cmsysBase64_Encode([0], hashBytes.size(), [0], 
> 0);
> +  checksumBase64 = reinterpret_cast([0]);
> +  // Base64 allows '+' and '/' characters. Replace these.

This comment should indicate it is because the string is used as part of
a path and that these characters tend to cause problems in paths.

--Ben
-- 

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] Autogen subdirectories patches

[Ben Boeckel]

On Tue, Jul 26, 2016 at 17:31:00 +0200, Sebastian Holtermann wrote:
> I have prepared an other approach which uses checksum suffixes
> instead of nested directory generation.
> This was tested on my Debian/amd64/Makefile setup.

Interesting; I like it. Might be worthwhile to reuse it for the .o files
in the future as well (since these can conflict, but are much less
likely to do so).

> Please review.

Could you run clang-format over the code? There are a number of style
issues that it will fix (IIRC, it needs at least Clang 3.8; I'm unsure
what version of the clang that comes with Xcode is sufficient).

> +rccOutputPath += cmQtAutoGeneratorUtil::BuildFileBase( qrcSourceName,
> +  makefile->GetCurrentSourceDirectory(),
> +  makefile->GetCurrentBinaryDirectory(),
> +  makefile->GetHomeDirectory(),
> +  makefile->GetHomeOutputDirectory() );

Is there a reason we can't pass just the `makefile` down and have it
query all the parameters rather than having 5 arguments?

> +  struct TPair {
> +const std::string * dir;
> +const char * seed;
> +  };
> +  TPair pDirs[4] = {
> +{ , "CurrentSource" },
> +{ , "CurrentBinary" },
> +{ , "ProjectSource" },
> +{ , "ProjectBinary" }
> +  };
> +  TPair * itc = [0];
> +  TPair * ite = [0] + ( sizeof ( pDirs ) / sizeof ( TPair ) );

It might be better to just use a NULL sentinel at the end of the array.
If not, the extra spaces here should go away.

> +  // Calculate the file ( seed + relative path + name ) checksum
> +  std::string checksumBase64;
> +  {
> +::std::vectorhashBytes;

CMake just uses std::, not ::std::.

> +{
> +  // Acquire hex value hash string
> +  std::string hexHash = cmCryptoHash::New("SHA256")->HashString(
> +(sourceRelSeed+sourceRelPath+sourceFileName).c_str());
> +  // Convert hex value string to bytes
> +  hashBytes.resize ( hexHash.size()/2 );
> +  for ( unsigned int ii=0; ii != hashBytes.size(); ++ii ) {
> +unsigned char byte ( 0 );
> +for ( unsigned int jj=0; jj != 2; ++jj ) {
> +  unsigned char cval ( 0 );
> +  switch ( hexHash[ii*2+jj] ) {
> +  case '0': cval=0; break; case '1': cval=1; break;
> +  case '2': cval=2; break; case '3': cval=3; break;
> +  case '4': cval=4; break; case '5': cval=5; break;
> +  case '6': cval=6; break; case '7': cval=7; break;
> +  case '8': cval=8; break; case '9': cval=9; break;
> +  case 'a': cval=10; break; case 'b': cval=11; break;
> +  case 'c': cval=12; break; case 'd': cval=13; break;
> +  case 'e': cval=14; break; case 'f': cval=15; break;
> +  default: break;

I feel like this is better as:

int nibble = hexHash[ii * 2 + jj];
if ('0' <= nibble && nibble <= '9') {
cval = nibble - '0';
} else if ('a' <= nibble && nibble <= 'f') {
cval = nibble - 'a' + 10;
} else {
// internal error about an unexpected hexchar
}

Alternatively, cmUuid::IntFromHexDigit() (and possibly other methods)
could be refactored to allow this to share an implementation.

--Ben
-- 

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] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Ben Boeckel]

On Fri, Jul 15, 2016 at 10:52:23 -0400, Brad King wrote:
> On 07/15/2016 10:45 AM, Eon Jeong wrote:
> > I considered that way, but doing this can't figure "VERBOSE" used
> > without  from never used. same empty string value.
> 
> You could hack it with something like
> 
>   if("${ARGN}" MATCHES ";VERBOSE;")
> 
> if the value comes back empty.

Avoiding regexes here would be better:

list(FIND ARGN "VERBOSE" has_verbose)

--Ben
-- 

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] Don't enclose CMake version to generated files

[Ben Boeckel]

On Mon, Jul 11, 2016 at 17:16:22 +0200, Christoph Grüninger wrote:
> this comes from the open build system, which is the system used by
> openSuse to generate the packages. If the CMake version is updated,
> which happens quite often, the generated files are altered and the
> packages are rebuild, repackaged and republished.
> Without the version number in the generated files, it wouldn't
> happen.

Why do the generated makefiles and ninja files cause this problem? Are
they packaged too? I grant that the export header one makes sense, but
the others not as much (and certainly not the Qt IFW file since I would
be surprised to see a Linux distro using it).

In any case, such information would be nice to have in the commit
message.

Thanks,

--Ben
-- 

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] Don't enclose CMake version to generated files

[Ben Boeckel]

On Sun, Jul 10, 2016 at 15:35:24 +0200, Christoph Grüninger wrote:
> I just updated openSuse's CMake package. We have a patch, that removes
> the CMake version from generated files. This is aiming to reduce the
> re-publishing of generated files. Please find the current patch attached.
> What do you think, can we get this somehow upstreamed? Or are you
> opposed to the general idea and keep the CMake version in the files?

Thanks!

> Enclosing the cmake version will cause a republish of generated files

What do you mean by "republish"? Do you mean "cause a rebuild"? The
files generated by CMake should, generally, not be put into source
control. If you mean "rebuild", only the header generation code needs to
really not put the version into the file. The version in generated
build.ninja, Makefiles, and CPack-related files shouldn't be a problem.

--Ben
-- 

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] One more pattern for extracting file name from URL

[Ben Boeckel]

On Tue, Jul 05, 2016 at 13:46:06 -0400, Brad King wrote:
> On 07/05/2016 01:31 PM, Ben Boeckel wrote:
> > Here's another idea: add an `OUTPUT_FILE ` keyword argument to
> > `file(DOWNLOAD)` to get the actual filename after content disposition
> > resolution (probably similar for 30x rewrites). This would also be
> > useful for things other than ExternalProject.
> 
> This may be a reasonable idea for the future but we are getting
> way off from the original patch here.

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

--Ben
-- 

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] One more pattern for extracting file name from URL

[Ben Boeckel]

On Tue, Jul 05, 2016 at 21:01:36 +0300, Ruslan Baratov wrote:
> Well it's never too late to learn something new. Also `tar` is not 
> widely used on Windows so to write nice code you should convert it to 
> `cmake -E tar`. That the whole point of `cmake -E` feature.
> I don't see the problem here, it was used internally, unpack archive for 
> you and you can do what you want with **unpacked** sources. Anyway you 
> can always force the name with |DOWNLOAD_NAME.|

I'm more considering the case of using the files as they exist on the
disk for other purposes, not necessarily through code (which probably
should be using `cmake -E tar`). For example, I will do:

  - tar xf $tarball.tar.gz
  - cp -a $tarball $tarball.to-patch
  - $edit .to-patch
  - diff -U5 -r $tarball $tarball.to-patch

to create patches for ExternalProject tarballs we use.

--Ben
-- 

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] One more pattern for extracting file name from URL

[Ben Boeckel]

On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote:
> Archive can be unpacked by "cmake -E tar xf" which detect type 
> automatically as far as I understand. At least this one used internally 
> by ExternalProject (see the testing I've made before).

CMake is not my go-to tool for extracting files though (and similarly
for others I imagine), so running `tar xf archive.tar` and getting an
error because it is actually a .tar.gz (or even a .zip) file is not
nice.

> So even if it seems that archive name is `|archive.tar.gz` it should be 
> downloaded to 
> `||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So 
> I think it's easily can be file with another extension.|

Here's another idea: add an `OUTPUT_FILE ` keyword argument to
`file(DOWNLOAD)` to get the actual filename after content disposition
resolution (probably similar for 30x rewrites). This would also be
useful for things other than ExternalProject.

--Ben
-- 

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] One more pattern for extracting file name from URL

[Ben Boeckel]

On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote:
> By default not, goes to -prefix/src/archive.tar .

Right, but if a download directory is set, this won't work. Can the
project name at least be added to the name?

Though I'm partial to keeping the extension still; if I need to add a
patch to a project, it'd be nice if the extension weren't a lie when I
go to extract the tarball.

--Ben
-- 

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] One more pattern for extracting file name from URL

[Ben Boeckel]

On Tue, Jul 05, 2016 at 16:26:54 +0300, Ruslan Baratov via cmake-developers 
wrote:
> +  # Do not put warning message here. If everything works OK it will
> +  # only distract. If unpack will fail the standard name can be 
> found in logs.
> +  # (see _ep_write_extractfile_script function)
> +  set(fname "archive.tar")

Is this going to cause multiple tarball downloads to overwrite each
other in the download cache directory?

--Ben
-- 

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] One more pattern for extracting file name from URL

[Ben Boeckel]

On Fri, Jul 01, 2016 at 18:48:41 +0300, Ruslan Baratov wrote:
> On 01-Jul-16 16:04, Ben Boeckel wrote:
> > On Fri, Jul 01, 2016 at 08:58:16 -0400, Brad King wrote:
> >> Also, the `([^/]*)\\?.*` part of the regex should be more
> >> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
> > This should also probably skip '#' characters for URLs with anchors.
> >
> > --Ben
> 'fragement' goes after 'query' so as far as I understand it's not necessary.
> https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax

Right, but if there isn't a query part:

foo.tar.gz#some_anchor

--Ben
-- 

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

[Ben Boeckel]

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.

--Ben
-- 

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] adding FindJsonCpp

[Ben Boeckel]

On Wed, Jun 29, 2016 at 17:36:45 +0200, Farbos a wrote:
> I have a concern with generating package configs:
> 
> 1 It seems to contain absolute path, so not really portable with git.

The actual config files are generated at build time, not committed to
the source control (template files with @variable@ spots to insert
values are committed).

> 2 It does not respect the naming of imported targets with `::`. As you
> can see here: 
> https://cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module
> The fact that it produces an appropriate diagnostic messages if that
> target does not exist is really helpful.

Not sure exactly what you mean when the config file approach "does not
respect" imported target names, but the file that CMake generates is not
the direct config file, but is usually included (I have CMake generate
${pkg}-targets.cmake). Checking for targets in the top-level script is
certainly possible.

--Ben
-- 

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] [iOS] What is the correct way to add resources to an XCode project

[Ben Boeckel]

On Wed, Jun 29, 2016 at 16:48:10 +0200, Roman Wüger wrote:
> I know because I wrote this ticket.

Ah. I didn't check the Mantis side.

> I thought this was "closed/want fixed" because of the implementation
> for RESOURCE a few days ago.

Hmm. I don't see that. Do you have a link?

--Ben
-- 

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] Script to update liblzma from upstream.

[Ben Boeckel]

On Wed, Jun 29, 2016 at 09:06:25 -0400, Brad King wrote:
> If there is a developer mailing list I typically use that.
> Otherwise I use kwrobot.

Ah, makes sense.

--Ben
-- 

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] Script to update liblzma from upstream.

[Ben Boeckel]

On Tue, Jun 28, 2016 at 23:24:22 +0200, Daniel Pfeifer wrote:
> 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.

Thanks! Looks like Brad hadn't imported the docs for it. Here's VTK's
copy:

https://gitlab.kitware.com/vtk/vtk/blob/master/ThirdParty/UPDATING.md

> +readonly ownership="liblzma upstream "

This should probably use kwro...@kitware.com as the email. The oddball I
see in the repo now is libarchive. Brad, why is that not kwrobot?

> +readonly paths="
> +  src/common/sysdefs.h
> +  src/common/tuklib_integer.h
> +  src/liblzma

I'd recommend adding a trailing slash to this to indicate that it is a
directory (at least this is the style I'd have used for VTK imports had
I needed to import any directories in those I ported to use this setup).

--Ben
-- 

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] [iOS] What is the correct way to add resources to an XCode project

[Ben Boeckel]

On Tue, Jun 28, 2016 at 23:01:56 +0200, Roman Wüger wrote:
> The target property RESOURCE does only allow files but no directories.

There's an open issue for this:

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

--Ben
-- 

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] adding FindJsonCpp

[Ben Boeckel]

On Wed, Jun 29, 2016 at 11:02:30 +0200, Farbos a wrote:
> I would like to add a find module: FindJsonCpp.cmake that I attached.
> the library github: https://github.com/open-source-parsers/jsoncpp.
> 
> This library allows JSON manipulation. It's used by more than one
> person and I think it could useful to add a find module for this
> library.

The library builds using CMake and rather than using more code to find
itself, it should instead create a package configuration file which
contains the exact information CMake needs to use its install tree. See
the docs:


https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages

Please consider contributing such support to the upstream project.

Thanks,

--Ben
-- 

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

[Ben Boeckel]

On Tue, Jun 14, 2016 at 02:00:14 +0200, Tobias Hunger wrote:
> Implementing new Protocol Versions:
> ==



> Deprecating old Protocol Versions:
> 



One idea that came up on a previous project was the following:

namespace protocol {
namespace aspect1 {
namespace v1 {
}

namespace v2 {
}
}

namespace aspect2 {
namespace v1 {
}
}

namespace v1 {
namespace aspect1 = aspect1::v1;
namespace aspect2 = aspect1::v1;

Version version(1, 0);
bool deprecated = true;
}

namespace v2 {
namespace aspect1 = aspect1::v2;
namespace aspect2 = aspect1::v1;

Version version(2, 0);
bool deprecated = false;
}

namespace latest = v2;
}

Then the code can use `protocol::v1::aspect1::` for explicit v1
communication and `protocol::latest::` in any normal code. It does
require C++11 though. There's probably some template metaprogramming
magic that could be done to instantiate communication ends for each
protocol namespace once communication is done.

I have no idea how maintainable in the long-term this is though.

--Ben
-- 

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

[Ben Boeckel]

On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote:
> On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> >   * Figure out whether a PDB file is actually going to be build. Currently
> > the PDB file is added to the list of artifacts whenever there is a .lib
> > file, which is probably wrong. Brad: Do you have an idea how to
> > get this information?
> 
> I'm not sure we have that information.  IIRC CMake only adds settings to the
> generated build system to tell the tools where to put the .pdb and what to
> call it if it happens to be created.  We don't have install rules for them
> so there has never been a need to know whether they will actually be created.
> Perhaps our format for the list of artifacts needs a way to indicate whether
> an artifact is optionally present.

Well, there is this issue:

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

which requests that they always be generated :) .

> >   2.8 buildsystem (return cmake files)
> >   
> >   * Return a list of cmake files (CMakeLists.txt, etc.) in different 
> > categories
> > (in source directory/in build directory/in the system).
> > 
> >   * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure
> > that name is much better than what is currently used.
> 
> "cmake_rerun_depends" describes the current use case for these.  I don't think
> the name "buildsystem" is clear though.  Other ideas:
> 
> * cmake_files
> * cmake_inputs
> * input_files

Also possible: regen_trigger_files

--Ben
-- 

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

[Ben Boeckel]

On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote:
> On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> >   * Some names could be improved. Suggestions welcome.
> 
> We'll cover these in more detail during review.  The most important name is
> the name of the feature, and IMO "daemon" is not an accurate description of
> it (it is never re-parented to 'init' and has a lifetime tied to the client).
> I think "server" would be better but am open to other suggestions.  Even if
> it later really becomes a daemon the name "server" will still be appropriate.
> 
> As you said before there has been a lot of PR with the name "daemon", but I
> don't think it is too late to change it.  Those interested in the features
> will see the new name when it appears in release notes and should easily be
> able to recognize it.

cmake-oracle sounds reasonable for what it's doing to me.

--Ben
-- 

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] Using a custom DSL compiler in CMake

[Ben Boeckel]

On Tue, Jun 21, 2016 at 16:05:47 -0400, Brad King wrote:
> On 06/21/2016 02:18 PM, Chris Bieneman wrote:
> > Our DSL compiler can generate .d files, but hooking that up to
> > CMake is a harder problem.
> 
> With some work it may be possible to teach our Ninja generator how
> to consume .d files in custom commands.  Perhaps such support could
> even be extended to the Makefile generators instead of using our
> approximate scanning implementation.

Here's the relevant issue for Ninja:

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

--Ben
-- 

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] speed up package with mingw on Windows host

[Ben Boeckel]

On Mon, Jun 20, 2016 at 23:05:11 +0200, laurent wrote:
> I mean dependencies will be marked as *analysed* at global scope.
> 
> Is cpack able to pack 2 binaries at the same time ?

Concurrently, no. In a single invokation, yes (though it is still just
one package).

> Maybe i could suffix GET_PREREQUISITES_ANALYZED with something unique
> to the current main target (get_prerequisites has an argument called
> exepath )
> 
> Do you have some advices ?

Multiple executables might go into the same package and amortizing
looking at common libraries that way would be useful. I think a new
keyword to get_prerequisites along the lines of "PACKAGE_GROUP" or
something would be useful for those that need such things (with it
defaulting to "default" or something).

--Ben
-- 

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] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Ben Boeckel]

On Fri, Jun 17, 2016 at 15:40:45 +0200, Nils Gladitz wrote:
> I have not been involved in that development.
>  From what I can tell this is Eike's work.

Ack, sorry. Should have double checked.

--Ben
-- 

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] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Ben Boeckel]

Hi,

Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
for that. However, it is hidden behind the check that pkg_check_modules
uses to see if it already ran:

if (NOT DEFINED __pkg_config_checked_${_prefix} OR
__pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR
NOT ${_prefix}_FOUND)

which means that on the second configure, the target is not created
causing build faiures. Could you please look at reordering the logic so
that the imported target is always created (if requested)? Thanks.

Brad, this is in the rc releases; what should be done? Block the
release, undocument the feature, or wait for a patch?

--Ben
-- 

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] Possibly an obscure bug

[Ben Boeckel]

On Wed, Jun 15, 2016 at 21:34:27 +0300, Binkie Pinkie wrote:
> build$ make
> Scanning dependencies of target list
> make[2]: Circular blink/CMakeFiles/list.dir/main.cpp.o <- blink/list
> dependency dropped.
> [ 50%] Building CXX object blink/CMakeFiles/list.dir/main.cpp.o
> In file included from /media/data/docs/dev/Blink/blink/main.cpp:2:0:
> /media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ‘\177’ in 
> program
>  ELF  > � @ @   �   @ 8   @@
>  ^

Looks like the built binary gets found by the compiler and it tries to
#include it. Try setting:

set(EXECUTABLE_OUTPUT_PATH "${CMAKE_BINARY_DIR}/bin")

to put the executable outside of the -I paths.

--Ben
-- 

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

[Ben Boeckel]

On Mon, Jun 13, 2016 at 16:14:51 +0200, Daniel Pfeifer wrote:
> On Mon, Jun 13, 2016 at 2:09 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> > 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.

And I'm saying that looking to port to GetSafeDefinition() will
highlight those that *can't* be converted easily which will get you use
cases for the current split.

> > 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`?

There isn't, hence the difference in behavior between NULL and empty.

--Ben
-- 

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

[Ben Boeckel]

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? Usually NULL means "unset". See properties,
variable values, etc. As an output, any place which doesn't care should
already be using GetSafeDefinition().

As a concrete example, `set(CACHE)` cares about NULL versus *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());
}

--Ben
-- 

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

[Ben Boeckel]

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.

> `const char*` can distinguish
> invalid from empty. Do we actually need this distinction?

It's used all over the place.

--Ben
-- 

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: LLVM community CMake documentation

[Ben Boeckel]

On Thu, Apr 28, 2016 at 14:16:40 -0700, Chris Bieneman wrote:
> The only comment I think I didn’t directly update the document for was
> Dan’s comment about GLOBAL properties. I kinda have mixed feelings
> about GLOBAL properties. I know why we use them, but I’m not sure I
> want to encourage people to use them. I think some of the places we
> use them is just wrong.

Curious, but why? What alternative do you use? Using INTERNAL cache
variables tends to have weird effects since they then persist between
runs and if the variables aren't cleared at the start of configure
diligently, you get old values left laying around (and has caused bugs
in projects). Plus, updating them is easier since you don't have to keep
doing `set(var full_val CACHE INTERNAL "")` and you have nice things
like `set_property(GLOBAL APPEND)`.

--Ben
-- 

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] cmLocalGenerator::GetTargetFlags

[Ben Boeckel]

On Wed, Jun 08, 2016 at 10:12:13 -0400, Brad King wrote:
> Side note: This is another thing that should be cleaned up in the Ninja
> generator.  It should hold target-wide flags in the per-target rules.ninja
> entries instead of duplicating them for every object file in build.ninja.
> That would make the build.ninja files smaller.

Don't we already do this with target-specific build rules in
rules.ninja?

--Ben
-- 

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] Suggest if function has lte gte operators

[Ben Boeckel]

On Fri, Apr 08, 2016 at 14:24:08 +, Harry Mallon wrote:
> CMake's "if" functionality is missing greater than or equal to and
> less than or equal to. This change could be tweaked and added to
> provide this functionality to avoid things like "if(VERSION_STRING
> VERSION_GREATER "4.8.0" OR VERSION_STRING VERSION_EQUAL "4.8.0")".

This can also be done as:

if (NOT VERSION_STRING VERSION_LESS "4.8.0")

I'm ambivalent on the idea of new operators. Documentation for this
pattern would likely help.

--Ben
-- 

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] ninja/make compilation response file

[Ben Boeckel]

On Mon, Apr 04, 2016 at 15:59:30 +, Dmitry Ivanov wrote:
> We have a strange situation where we do have too many include paths,
> which makes command line for obj compilation too long on windows (more
> 32kb).
> I've tried using set(CMAKE_NINJA_FORCE_RESPONSE_FILE 1), but
> apparently after checking cmake upstream I've realized that it's only
> implemented for linking, and not compilation.

Hmm. I know that RC compilation doesn't support response files (though
the rc compiler does on Windows). Haven't had a problem with source
compilation though (and I've had to deal with *long* paths before).

> What we should do (other than fixing "the problem" with too many
> paths) ? Would be nice to have this feature working for makefiles and
> ninja.

Teaching the Ninja generator about response files for object file
compilation would be the way to go (and support for RC as well would
be good since the logic is likely the same).

> PS. Can we do something about bloated cmake ninja generator ? in our
> case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though
> ninja is still faster than make even in this case.

There was work to reduce the size of the generated build.ninja file.
More work could be done, but the projects I was looking at would only
get marginal improvements from other techniques (though other projects
with different flag quantities might show other things to improve). What
version of CMake are you using?

--Ben
-- 

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] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64

[Ben Boeckel]

On Mon, Apr 04, 2016 at 09:07:09 +, melven.roehrig-zoell...@dlr.de wrote:
> After thinking about my patch I worried it could break other compilers.
> So, here is a more defensive version that shouldn't interfere with anything 
> else.
> 
> Explanation:
> CMAKE_Fortran_COMPILER_ID was correctly set to "GNU";
> If CMAKE_Fortran_PLATFORM_IS is missing, run gfortran with a C file
> -> fallback to C which has appropriate preprocessor definitions to recognize 
> MINGW.

+exec_program(${CMAKE_Fortran_COMPILER}
+  ARGS ${CMAKE_Fortran_COMPILER_ID_FLAGS_LIST} -E
+"\"${CMAKE_ROOT}/Modules/CMakeTestGNU.c\""
+  OUTPUT_VARIABLE CMAKE_COMPILER_OUTPUT RETURN_VALUE
+CMAKE_COMPILER_RETURN)

Please use `execute_process` instead.

+if(NOT CMAKE_COMPILER_RETURN)
+  if(NOT CMAKE_Fortran_PLATFORM_ID)

Is this not always true inside this block?

+if("${CMAKE_COMPILER_OUTPUT}" MATCHES "THIS_IS_MINGW")

Use:

if (CMAKE_COMPILER_OUTPUT MATCHES "THIS_IS_MINGW")

+  set(CMAKE_Fortran_PLATFORM_ID "MinGW")
+endif()
+if("${CMAKE_COMPILER_OUTPUT}" MATCHES "THIS_IS_CYGWIN")

elseif? Similar transformation as above.

+  set(CMAKE_Fortran_PLATFORM_ID "Cygwin")
+endif()
+  endif()
+endif()

--Ben
-- 

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 v2] ExternalProject: Allow TLS_VERIFY for git clones

[Ben Boeckel]

On Fri, Apr 01, 2016 at 15:39:26 +0100, Samir Benmendil wrote:
> Use the git config `http.sslVerify=false` to disable strict ssl for git
> commands.
> ---
> Changes in v2:
> - git_options is now a list

Thanks.

I've pushed this into next for testing.

--Ben
-- 

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