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] Putting the git commit hash in a cmake variable

[Ben Boeckel]

Sorry if this shows up oddly on the list; I was forwarded the original
in order to reply. As such, please keep me in Cc.

> I'd like to set a CMake variable to the current git commit short hash.
> This variable will be used as part of the version string for my
> project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
> by using execute_process and setting the resulting output to a
> variable.
> 
> ```cmake
> execute_process(
> COMMAND
> git rev-parse --short HEAD
> RESULT_VARIABLE
> SHORT_HASH_RESULT
> OUTPUT_VARIABLE
> SHORT_HASH)
> ```
> 
> My issue is that cmake will only run execute_process once, during the
> configure step. I need cmake to run this execute_process on every
> build and, if the output has changed, reconfigure to make sure
> SHORT_HASH is up to date.
> 
> I came up with one solution to this issue: During the configure step,
> I can write the current short hash to a file named short_hash.txt. On
> every build, I'll re-compute the short hash and verify that the
> computed short hash is the same as what is in short_hash.txt. If its
> not, I'll write the new short hash to short_hash.txt. I then make
> short_hash.txt an input to configure_file. This will cause cmake to
> validate SHORT_HASH is properly set, and re-configure if its not.

I solved this a few years ago :) . Here are all the relevant files:

https://github.com/Kitware/sprokit/blob/master/src/sprokit/version.h.in
https://github.com/Kitware/sprokit/blob/master/src/sprokit/.gitattributes
https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt

https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake

Basically the solution follows:

  - If we're in an archive (.gitattributes' export-subst), use the
information from it. Detect this in CMake by checking if Git
replaced substitutions for us:

if ("$Format:$" STREQUAL "")

If we are, just use that information (gathered using other
`$Format:$` expansions).
  - If not, we set up some code to run at build time to extract the
information.
  - The variables (or code) from above is injected via
`sprokit_configure_file_always` which basically is just a
`configure_file` done at build time. The list of variables to export
to the script are listed as arguments. The `_always` bit just adds
an extra output file named `${output}.noexist` which causes tools to
always run the associated custom command (which is then attached to
a custom target via its output file).

The file is only updated if the contents change (via `configure_file`),
so rebuilding should be minimal.

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

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] [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

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] [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

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] CMake 3.9 change to dependencies of object compilation

[Ben Boeckel]

On Fri, Aug 04, 2017 at 17:35:53 +, Puetz Kevin A wrote:
> Thanks for the reply, questions/clarifications below.
> > requests that that be fixed as well (though that is backwards compatible
> > since the solution will likely involve ).
> 
> Sentence cut off? I assume you meant "will likely involve a new keyword"?

Yep, sorry.

> > > 2. MSVC's #import construct which needs the indirect dependencies
> > > (dependencies of the #import-ed dependency) be registered, which is
> > > handled as part of the target using add_custom_command(TARGET foo
> > > POST_BUILD COMMAND ...)
> > 
> > So there's an issue here that there's a dependency between your build rules
> > which CMake doesn't know about (though I don't know #import well
> > enough, the docs don't state where the information *goes*).
> 
> #import will load a COM typelib during preprocessing, possibly
> following registry keys to locate other typelibs which the specified
> one refers to. It will have the byproduct of creating .tlh/.tli files
> next to the other compiler outputs (e.g. .o file) Arguably the
> .tlh/.tli files should be listed in OBJECT_OUTPUTS, but I can't
> because I don't know their location; CMake doesn't have a
> variable/property/generator expression that reveals where it's going
> to place the object files (i.e. /Fo$out), so I don't know where they
> will end up. Luckily the .tlh/.tli files aren't important to list for
> dependency resolution anyway, because the #import also automatically
> #includes the just-generated headers, (though this is not mentioned in
> /showIncludes). So CMake is at least *consistently* unaware of these
> files, and they get regenerated any time they would have been read so
> it doesn't really need to know.

OK, a genex for where object outputs may be useful anyways. I think
there's something along those lines with Cuda's PTX file generation?

> The important missing dependency is the one between
> creating/regstering the typelib (we'll call this target COMServer) and
> the #import that will read it in a source file in another target
> (we'll call it COMClient).  I have a call add_custom_command(TARGET
> COMServer POST_BUILD COMMAND regsvr32 $),
> which will create the registry keys under HKEY_CLASSES_ROOT. This
> needs to happen before the source file in COMClient can preprocess the
> #import successfully. Prior to CMake 3.9, I could inform CMake of this
> by just using add_dependencies(COMClient COMServer) to tell CMake that
> it couldn't build (any of) Client until Server had been built (and
> thus its POST_BUILD had also run to register it). But in 3.9,
> add_dependencies has changed in meaning; although the documentation
> still says "to ensure that they build before  does", in
> practice this now only means "to ensure that they build before
>  *links*"; these edges do not apply to object compilation or
> add_custom_command rules.
> 
> add_custom_command is no problem; it already had a DEPENDS argument
> that allows target-level dependencies, and arguably such dependencies
> needed to be stated there anyway since an add_custom_command output
> can get reused by multiple targets in the same subdir. But object
> compilation is a problem because there's nowhere to add them
> per-source, and add_dependencies doesn't work anymore to add them
> per-target.

It sounds like the logic may need fixing then. Do you have an example
case where add_dependencies doesn't work anymore in Ninja?

> > When adding
> > this custom command, you may use the `BYPRODUCTS` argument
> > (introduced in 3.2.0) to let CMake know what's going on here. It only 
> > affects
> > Ninja, but the other generators do target-level dependencies anyways. That
> > output can then be depended on via `OBJECT_DEPENDS` and the
> > dependency should link up properly.
> 
> There is not an explicit file output, though I could do the usual
> workaround of a stamp/witness file listed in BYPRODUCTS to the
> add_custom_command(TARGET ... POST_BUILD ...). But I don't think that
> will work with most generators, since CMake doesn't generally allow
> file-level depends to set the order in which targets are built. I
> suppose it might work out in practice for ninja since that writes a
> monolithic set of rules, but conditional code where I have to peek at
> CMAKE_GENERATOR and use BYPRODUCTS/OBJECT_DEPENDS for ninja and
> add_dependencies for other generators seems like the sort of thing
> this list would tell me not to do :-)

Well, other generators are generally target-ordered anyways. Ninja is
the oddball here (which is why it's the only one to get the feature). I
don't know the effect it'd have in other generators, but I feel like I'd
be surprised if it *broke* them since excess dependencies (usually) only
result in either slower builds or circular dependency loops and Ninja
complains loudly about the latter. And since BYPRODUCTS only affects
Ninja, if BYPRODUCTS is used, other generators shouldn't care anyways.

> And even for ninja I think I'd have to 

Re: [CMake] CMake 3.9 change to dependencies of object compilation

[Ben Boeckel]

> . The Ninja generator has loosened the dependencies of object
> compilation. Object compilation now depends only on custom targets and
> custom commands associated with libraries on which the object's target
> depends and no longer depends on the libraries themselves. Source
> files in dependent targets may now compile without waiting for their
> targets' dependencies to link.

Correct.

> We have a few cases where the object compilation really does depend on
> the TARGET_FILE itself, e.g.
> 1. An RC compiler embedding the resulting file of a custom target (I
> think this one may still work, since custom targets appear to have
> been exempted from the change)

Correct, though this issue:

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

requests that that be fixed as well (though that is backwards
compatible since the solution will likely involve ).

> 2. MSVC's #import construct which needs the indirect dependencies
> (dependencies of the #import-ed dependency) be registered, which is
> handled as part of the target using add_custom_command(TARGET foo
> POST_BUILD COMMAND ...)

So there's an issue here that there's a dependency between your build
rules which CMake doesn't know about (though I don't know #import well
enough, the docs don't state where the information *goes*). When adding
this custom command, you may use the `BYPRODUCTS` argument (introduced
in 3.2.0) to let CMake know what's going on here. It only affects Ninja,
but the other generators do target-level dependencies anyways. That
output can then be depended on via `OBJECT_DEPENDS` and the dependency
should link up properly.

If it instead gets registered somewhere in the aether (as far as CMake
is concerned), adding support for generator expressions to
`OBJECT_DEPENDS` so that `$` may be used there would be
the next solution.

Making `POST_BUILD` write out a stamp file would also work and then
using `OBJECT_DEPENDS` on that would also work.

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

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] [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

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] [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

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] [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

Re: [CMake] [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

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

[Cmake-commits] CMake branch, next, updated. v3.7.2-2290-gca3a4fe

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  ca3a4fee2db8946a5ba46498959027a5cdf84b9a (commit)
   via  893423e9c9f4563dcd33e6472c8be85ec1aca88c (commit)
   via  7b4514fb33cf256ef165b2b28ba4affd1930a957 (commit)
   via  8ea12a8b80c4c3153cc602f1d0735b3db8581ae8 (commit)
   via  ae629a0dc9fa775230f4ce0157f13fde99381c9c (commit)
  from  69cd1ce190268342cc570569afbba1fc6038822e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca3a4fee2db8946a5ba46498959027a5cdf84b9a
commit ca3a4fee2db8946a5ba46498959027a5cdf84b9a
Merge: 69cd1ce 893423e
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Mon Jan 23 08:49:32 2017 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Jan 23 08:49:32 2017 -0500

Merge topic 'dl-libs-typo' into next

893423e9 CMAKE_DL_LIBS: fix typo
7b4514fb CMake Nightly Date Stamp
8ea12a8b CMake Nightly Date Stamp
ae629a0d CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=893423e9c9f4563dcd33e6472c8be85ec1aca88c
commit 893423e9c9f4563dcd33e6472c8be85ec1aca88c
Author: Thiago Perrotta <tperro...@tgr.net.br>
AuthorDate: Fri Jan 20 23:35:27 2017 -0200
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Mon Jan 23 08:48:36 2017 -0500

CMAKE_DL_LIBS: fix typo

diff --git a/Help/variable/CMAKE_DL_LIBS.rst b/Help/variable/CMAKE_DL_LIBS.rst
index 1fe7641..50d313d 100644
--- a/Help/variable/CMAKE_DL_LIBS.rst
+++ b/Help/variable/CMAKE_DL_LIBS.rst
@@ -1,7 +1,7 @@
 CMAKE_DL_LIBS
 -
 
-Name of library containing ``dlopen`` and ``dlcose``.
+Name of library containing ``dlopen`` and ``dlclose``.
 
 The name of the library that has ``dlopen`` and ``dlclose`` in it, usually
 ``-ldl`` on most UNIX machines.

---

Summary of changes:
 Help/variable/CMAKE_DL_LIBS.rst |2 +-
 Source/CMakeVersion.cmake   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, next, updated. v3.7.2-2230-gcba760d

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  cba760da8de27c311918f2d33ff7f27193f6e6af (commit)
   via  8c1cfb945a4fe63caa4f5d9fc33fbe2c3731a3ca (commit)
   via  fe8e00f6b91d7e8614af5a5ffb2ab68775b06e1c (commit)
  from  f38f5c7b2003bd0865d395e07f015d5d8c1580a7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cba760da8de27c311918f2d33ff7f27193f6e6af
commit cba760da8de27c311918f2d33ff7f27193f6e6af
Merge: f38f5c7 8c1cfb9
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Wed Jan 18 12:30:50 2017 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Jan 18 12:30:50 2017 -0500

Merge topic 'add-dl-to-lua-static-linking' into next

8c1cfb94 Add dl library to Lua static library linking
fe8e00f6 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c1cfb945a4fe63caa4f5d9fc33fbe2c3731a3ca
commit 8c1cfb945a4fe63caa4f5d9fc33fbe2c3731a3ca
Author: Michael Krasnyk <michael.kras...@gmail.com>
AuthorDate: Wed Jan 18 15:22:20 2017 +0100
Commit: Michael Krasnyk <michael.kras...@gmail.com>
CommitDate: Wed Jan 18 18:01:50 2017 +0100

Add dl library to Lua static library linking

diff --git a/Modules/FindLua.cmake b/Modules/FindLua.cmake
index 5be0428..c777970 100644
--- a/Modules/FindLua.cmake
+++ b/Modules/FindLua.cmake
@@ -172,6 +172,13 @@ if (LUA_LIBRARY)
 if (UNIX AND NOT APPLE AND NOT BEOS)
 find_library(LUA_MATH_LIBRARY m)
 set(LUA_LIBRARIES "${LUA_LIBRARY};${LUA_MATH_LIBRARY}")
+
+# include dl library for statically-linked Lua library
+get_filename_component(LUA_LIB_EXT ${LUA_LIBRARY} EXT)
+if(LUA_LIB_EXT STREQUAL CMAKE_STATIC_LIBRARY_SUFFIX)
+  list(APPEND LUA_LIBRARIES ${CMAKE_DL_LIBS})
+endif()
+
 # For Windows and Mac, don't need to explicitly include the math library
 else ()
 set(LUA_LIBRARIES "${LUA_LIBRARY}")

---

Summary of changes:
 Modules/FindLua.cmake |7 +++
 Source/CMakeVersion.cmake |2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.2-2227-gf38f5c7

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  f38f5c7b2003bd0865d395e07f015d5d8c1580a7 (commit)
   via  7f0a21a51eb483c523a2c8880ce4e0466251ec74 (commit)
  from  9d16616b45a62a9b398cff89d9801a7e9af264b0 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f38f5c7b2003bd0865d395e07f015d5d8c1580a7
commit f38f5c7b2003bd0865d395e07f015d5d8c1580a7
Merge: 9d16616 7f0a21a
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Wed Jan 18 12:29:52 2017 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Jan 18 12:29:52 2017 -0500

Merge topic 'case-insensitive-bindir-detection' into next

7f0a21a5 cmSystemTools: use the actual case for root detection


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f0a21a51eb483c523a2c8880ce4e0466251ec74
commit 7f0a21a51eb483c523a2c8880ce4e0466251ec74
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Wed Jan 18 10:06:23 2017 -0500
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Wed Jan 18 10:08:40 2017 -0500

cmSystemTools: use the actual case for root detection

On Windows, calling a binary installed with the default `bin` binary
directory will fail to be detected when called as `BIN\cmake.exe` due to
the string compare. Get the actual case of the path before checking that
the path ends with `CMAKE_BIN_DIR`.

Fixes #16574.

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 3d8fdf5..e693beb 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -1979,7 +1979,8 @@ void cmSystemTools::FindCMakeResources(const char* argv0)
   // Install tree has
   // - "/cmake"
   // - ""
-  if (cmHasSuffix(exe_dir, CMAKE_BIN_DIR)) {
+  const std::string actual_case = cmSystemTools::GetActualCaseForPath(exe_dir);
+  if (cmHasSuffix(actual_case, CMAKE_BIN_DIR)) {
 std::string const prefix =
   exe_dir.substr(0, exe_dir.size() - strlen(CMAKE_BIN_DIR));
 cmSystemToolsCMakeRoot = prefix + CMAKE_DATA_DIR;

---

Summary of changes:
 Source/cmSystemTools.cxx |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, next, updated. v3.7.1-1877-gd0868c9

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  d0868c9866d1bec94285c51bf2c6258e1c835223 (commit)
   via  78c5db6a0ad90eec54958e06e7b9dcac9b6cc8ab (commit)
  from  040e28be7c196697a103e19725d1c9ef392d2471 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0868c9866d1bec94285c51bf2c6258e1c835223
commit d0868c9866d1bec94285c51bf2c6258e1c835223
Merge: 040e28b 78c5db6
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Wed Jan 4 08:05:59 2017 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Jan 4 08:05:59 2017 -0500

Merge topic 'codeblocks-nmake-makefiles-jom' into next

78c5db6a Allow CodeBlocks for NMake Makefiles JOM


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78c5db6a0ad90eec54958e06e7b9dcac9b6cc8ab
commit 78c5db6a0ad90eec54958e06e7b9dcac9b6cc8ab
Author: Konstantin Podsvirov <konstan...@podsvirov.pro>
AuthorDate: Fri Dec 23 12:50:40 2016 +0300
Commit: Konstantin Podsvirov <konstan...@podsvirov.pro>
CommitDate: Fri Dec 23 12:50:40 2016 +0300

Allow CodeBlocks for NMake Makefiles JOM

diff --git a/Help/generator/CodeBlocks.rst b/Help/generator/CodeBlocks.rst
index 01798c7..d03cb0c 100644
--- a/Help/generator/CodeBlocks.rst
+++ b/Help/generator/CodeBlocks.rst
@@ -18,6 +18,9 @@ This "extra" generator may be specified as:
 ``CodeBlocks - NMake Makefiles``
  Generate with :generator:`NMake Makefiles`.
 
+``CodeBlocks - NMake Makefiles JOM``
+ Generate with :generator:`NMake Makefiles JOM`.
+
 ``CodeBlocks - Ninja``
  Generate with :generator:`Ninja`.
 
diff --git a/Help/release/3.7.rst b/Help/release/3.7.rst
index 4c51af4..e42ce48 100644
--- a/Help/release/3.7.rst
+++ b/Help/release/3.7.rst
@@ -46,6 +46,9 @@ Generators
   :variable:`CMAKE_CODELITE_USE_TARGETS` option
   to change project creation from projects to targets.
 
+* The :generator:`CodeBlocks` now can generate with
+  :generator:`NMake Makefiles JOM`.
+
 Commands
 
 
diff --git a/Source/cmExtraCodeBlocksGenerator.cxx 
b/Source/cmExtraCodeBlocksGenerator.cxx
index 18c732d..bc81a6a 100644
--- a/Source/cmExtraCodeBlocksGenerator.cxx
+++ b/Source/cmExtraCodeBlocksGenerator.cxx
@@ -49,6 +49,7 @@ cmExtraCodeBlocksGenerator::GetFactory()
 #if defined(_WIN32)
 factory.AddSupportedGlobalGenerator("MinGW Makefiles");
 factory.AddSupportedGlobalGenerator("NMake Makefiles");
+factory.AddSupportedGlobalGenerator("NMake Makefiles JOM");
 // disable until somebody actually tests it:
 // this->AddSupportedGlobalGenerator("MSYS Makefiles");
 #endif
@@ -743,7 +744,7 @@ std::string cmExtraCodeBlocksGenerator::BuildMakeCommand(
   }
 
   std::string generator = this->GlobalGenerator->GetName();
-  if (generator == "NMake Makefiles") {
+  if (generator == "NMake Makefiles" || generator == "NMake Makefiles JOM") {
 // For Windows ConvertToOutputPath already adds quotes when required.
 // These need to be escaped, see
 // https://gitlab.kitware.com/cmake/cmake/issues/13952

---

Summary of changes:
 Help/generator/CodeBlocks.rst |3 +++
 Help/release/3.7.rst  |3 +++
 Source/cmExtraCodeBlocksGenerator.cxx |3 ++-
 3 files changed, 8 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, next, updated. v3.6.2-1993-gd3a223e

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  d3a223e4918e3c7eeba9ec2511309399f987cf7a (commit)
   via  7845d2aaf7e4f2080892107a4d2e73d6a966ba6f (commit)
   via  6a9ed3d4aeee576dd87af77fe51a781c5fe64b79 (commit)
  from  b129f20547e849650e9aee1b3b2b0a6835c748e2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3a223e4918e3c7eeba9ec2511309399f987cf7a
commit d3a223e4918e3c7eeba9ec2511309399f987cf7a
Merge: b129f20 7845d2a
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Tue Sep 13 15:09:05 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Sep 13 15:09:05 2016 -0400

Merge topic 'detect-relink-incompat' into next

7845d2aa ninja: error out on relink requirements
6a9ed3d4 cmGeneratorTarget: factor out a space


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7845d2aaf7e4f2080892107a4d2e73d6a966ba6f
commit 7845d2aaf7e4f2080892107a4d2e73d6a966ba6f
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Tue Sep 13 11:23:19 2016 -0400
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Tue Sep 13 13:53:26 2016 -0400

ninja: error out on relink requirements

Ninja does not support PRE_INSTALL_SCRIPT properties and does not
perform the relink required by installation without help from some other
mechanism, so error out if it would be required.

See #16304.

diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index 4f8c036..32dd150 100644
--- a/Source/cmGeneratorTarget.cxx
+++ b/Source/cmGeneratorTarget.cxx
@@ -1162,7 +1162,23 @@ bool cmGeneratorTarget::NeedRelinkBeforeInstall(
   // If either a build or install tree rpath is set then the rpath
   // will likely change between the build tree and install tree and
   // this target must be relinked.
-  return this->HaveBuildTreeRPATH(config) || this->HaveInstallTreeRPATH();
+  bool have_rpath =
+this->HaveBuildTreeRPATH(config) || this->HaveInstallTreeRPATH();
+  bool is_ninja =
+this->LocalGenerator->GetGlobalGenerator()->GetName() == "Ninja";
+
+  if (have_rpath && is_ninja) {
+std::ostringstream w;
+w << "Ninja does not support relinking before installation "
+ "on non-ELF platforms. This has been detected as a \""
+  << this->Makefile->GetDefinition("CMAKE_EXECUTABLE_FORMAT")
+  << "\" platform.";
+
+cmake* cm = this->LocalGenerator->GetCMakeInstance();
+cm->IssueMessage(cmake::FATAL_ERROR, w.str(), this->GetBacktrace());
+  }
+
+  return have_rpath;
 }
 
 bool cmGeneratorTarget::IsChrpathUsed(const std::string& config) const

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a9ed3d4aeee576dd87af77fe51a781c5fe64b79
commit 6a9ed3d4aeee576dd87af77fe51a781c5fe64b79
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Tue Sep 13 11:22:42 2016 -0400
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Tue Sep 13 11:22:42 2016 -0400

cmGeneratorTarget: factor out a space

diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index 7dd8e7f..4f8c036 100644
--- a/Source/cmGeneratorTarget.cxx
+++ b/Source/cmGeneratorTarget.cxx
@@ -1280,11 +1280,11 @@ bool cmGeneratorTarget::HasMacOSXRpathInstallNameDir(
 
   if (!this->Makefile->IsSet("CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG")) {
 std::ostringstream w;
-w << "Attempting to use";
+w << "Attempting to use ";
 if (macosx_rpath) {
-  w << " MACOSX_RPATH";
+  w << "MACOSX_RPATH";
 } else {
-  w << " @rpath";
+  w << "@rpath";
 }
 w << " without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being set.";
 w << "  This could be because you are using a Mac OS X version";

---

Summary of changes:
 Source/cmGeneratorTarget.cxx |   24 
 1 file changed, 20 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1255-g7d693f7

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  7d693f72615cdef461fc3f22b5aefc7c5d6a93f1 (commit)
   via  2bdba83e4bbd5435ee6faf5a2eedec4f0d0dfb0a (commit)
  from  a63f6c7ac7e406abe9c12a524bf3f11b1666f74f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d693f72615cdef461fc3f22b5aefc7c5d6a93f1
commit 7d693f72615cdef461fc3f22b5aefc7c5d6a93f1
Merge: a63f6c7 2bdba83
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Mon Aug 15 09:34:48 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Aug 15 09:34:48 2016 -0400

Merge topic 'issue-tracker-urls' into next

2bdba83e issues: update references to the CMake issue tracker


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bdba83e4bbd5435ee6faf5a2eedec4f0d0dfb0a
commit 2bdba83e4bbd5435ee6faf5a2eedec4f0d0dfb0a
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Fri Aug 12 15:06:35 2016 -0400
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Mon Aug 15 09:34:06 2016 -0400

issues: update references to the CMake issue tracker

References to specific comments are left as-is since comments were not
migrated.

diff --git a/Modules/CMakeDetermineCCompiler.cmake 
b/Modules/CMakeDetermineCCompiler.cmake
index 73d9fb3..c566f39 100644
--- a/Modules/CMakeDetermineCCompiler.cmake
+++ b/Modules/CMakeDetermineCCompiler.cmake
@@ -105,7 +105,7 @@ if(NOT CMAKE_C_COMPILER_ID_RUN)
 CMAKE_C_COMPILER_ID_PLATFORM_CONTENT)
 
   # The IAR compiler produces weird output.
-  # See https://cmake.org/Bug/view.php?id=10176#c19598
+  # See https://gitlab.kitware.com/cmake/cmake/issues/10176#note_153591
   list(APPEND CMAKE_C_COMPILER_ID_VENDORS IAR)
   set(CMAKE_C_COMPILER_ID_VENDOR_FLAGS_IAR )
   set(CMAKE_C_COMPILER_ID_VENDOR_REGEX_IAR "IAR .+ Compiler")
diff --git a/Modules/CMakeDetermineCXXCompiler.cmake 
b/Modules/CMakeDetermineCXXCompiler.cmake
index 063b68e..fb4155b 100644
--- a/Modules/CMakeDetermineCXXCompiler.cmake
+++ b/Modules/CMakeDetermineCXXCompiler.cmake
@@ -97,7 +97,7 @@ if(NOT CMAKE_CXX_COMPILER_ID_RUN)
 CMAKE_CXX_COMPILER_ID_PLATFORM_CONTENT)
 
   # The IAR compiler produces weird output.
-  # See https://cmake.org/Bug/view.php?id=10176#c19598
+  # See https://gitlab.kitware.com/cmake/cmake/issues/10176#note_153591
   list(APPEND CMAKE_CXX_COMPILER_ID_VENDORS IAR)
   set(CMAKE_CXX_COMPILER_ID_VENDOR_FLAGS_IAR )
   set(CMAKE_CXX_COMPILER_ID_VENDOR_REGEX_IAR "IAR .+ Compiler")
diff --git a/Modules/CMakeFindEclipseCDT4.cmake 
b/Modules/CMakeFindEclipseCDT4.cmake
index 5bf738a..e158a73 100644
--- a/Modules/CMakeFindEclipseCDT4.cmake
+++ b/Modules/CMakeFindEclipseCDT4.cmake
@@ -35,7 +35,7 @@ function(_FIND_ECLIPSE_VERSION)
 
   if(NOT DEFINED CMAKE_ECLIPSE_VERSION)
 if(CMAKE_ECLIPSE_EXECUTABLE)
-  # use REALPATH to resolve symlinks 
(http://public.kitware.com/Bug/view.php?id=13036)
+  # use REALPATH to resolve symlinks 
(https://gitlab.kitware.com/cmake/cmake/issues/13036)
   get_filename_component(_REALPATH_CMAKE_ECLIPSE_EXECUTABLE 
"${CMAKE_ECLIPSE_EXECUTABLE}" REALPATH)
   get_filename_component(_ECLIPSE_DIR 
"${_REALPATH_CMAKE_ECLIPSE_EXECUTABLE}" PATH)
   file(GLOB _ECLIPSE_FEATURE_DIR 
"${_ECLIPSE_DIR}/features/org.eclipse.platform*")
diff --git a/Modules/Compiler/IAR.cmake b/Modules/Compiler/IAR.cmake
index 8c6c3f6..8c45276 100644
--- a/Modules/Compiler/IAR.cmake
+++ b/Modules/Compiler/IAR.cmake
@@ -1,6 +1,6 @@
 # This file is processed when the IAR compiler is used for a C or C++ file
 # Documentation can be downloaded here: 
http://www.iar.com/website1/1.0.1.0/675/1/
-# The initial feature request is here: https://cmake.org/Bug/view.php?id=10176
+# The initial feature request is here: 
https://gitlab.kitware.com/cmake/cmake/issues/10176
 # It also contains additional links and information.
 
 if(_IAR_CMAKE_LOADED)
@@ -39,7 +39,8 @@ endif()
 
 if(NOT IAR_TARGET_ARCHITECTURE)
   message(FATAL_ERROR "The IAR compiler for this architecture is not yet 
supported "
-  " by CMake. Please go to https://cmake.org/Bug and enter a feature 
request there.")
+  "by CMake. Please go to 
https://gitlab.kitware.com/cmake/cmake/issues "
+  "and enter a feature request there.")
 endif()
 
 set(CMAKE_LINKER "${CMAKE_IAR_LINKER}" CACHE FILEPATH "The IAR linker" FORCE)
diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index fc01976..e27eb72 100644
--- a/Modules/E

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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1063-g55c3ee1

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  55c3ee103dcac6bc4659993deee069b53bcc008b (commit)
   via  088f14eb725650158d256c28e86e44da3989ad9c (commit)
   via  27a3ca15e5e92abbdf9228a5ac83c190a5caf0a8 (commit)
   via  cc223e1eed69775a323a59628ad93fc79390c2f2 (commit)
  from  57addbd3e72f7f16595ba2245a12da9eeac12535 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=55c3ee103dcac6bc4659993deee069b53bcc008b
commit 55c3ee103dcac6bc4659993deee069b53bcc008b
Merge: 57addbd 088f14e
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Tue Aug 2 15:13:46 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Aug 2 15:13:46 2016 -0400

Merge topic 'intel-gnu11-support' into next

088f14eb Intel-C: standard flags are also supported in 12.0
27a3ca15 Intel-C: support gnu89 and gnu99 extension flags
cc223e1e Intel-C: declare support for gnu11


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=088f14eb725650158d256c28e86e44da3989ad9c
commit 088f14eb725650158d256c28e86e44da3989ad9c
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Tue Aug 2 13:10:56 2016 -0400
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Tue Aug 2 13:10:56 2016 -0400

Intel-C: standard flags are also supported in 12.0

diff --git a/Modules/Compiler/Intel-C.cmake b/Modules/Compiler/Intel-C.cmake
index 0efcbc2..edca154 100644
--- a/Modules/Compiler/Intel-C.cmake
+++ b/Modules/Compiler/Intel-C.cmake
@@ -19,7 +19,7 @@ if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 15.0.0)
   set(CMAKE_C11_EXTENSION_COMPILE_OPTION "${_std}=gnu11")
 endif()
 
-if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 12.1)
+if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 12.0)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "${_std}=c89")
   set(CMAKE_C90_EXTENSION_COMPILE_OPTION "${_std}=gnu89")
   set(CMAKE_C99_STANDARD_COMPILE_OPTION "${_std}=c99")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27a3ca15e5e92abbdf9228a5ac83c190a5caf0a8
commit 27a3ca15e5e92abbdf9228a5ac83c190a5caf0a8
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Tue Aug 2 13:10:30 2016 -0400
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Tue Aug 2 13:10:41 2016 -0400

Intel-C: support gnu89 and gnu99 extension flags

diff --git a/Modules/Compiler/Intel-C.cmake b/Modules/Compiler/Intel-C.cmake
index b2ff50d..0efcbc2 100644
--- a/Modules/Compiler/Intel-C.cmake
+++ b/Modules/Compiler/Intel-C.cmake
@@ -21,9 +21,9 @@ endif()
 
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 12.1)
   set(CMAKE_C90_STANDARD_COMPILE_OPTION "${_std}=c89")
-  set(CMAKE_C90_EXTENSION_COMPILE_OPTION "${_std}=c89")
+  set(CMAKE_C90_EXTENSION_COMPILE_OPTION "${_std}=gnu89")
   set(CMAKE_C99_STANDARD_COMPILE_OPTION "${_std}=c99")
-  set(CMAKE_C99_EXTENSION_COMPILE_OPTION "${_std}=c99")
+  set(CMAKE_C99_EXTENSION_COMPILE_OPTION "${_std}=gnu99")
 endif()
 
 if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 12.1)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc223e1eed69775a323a59628ad93fc79390c2f2
commit cc223e1eed69775a323a59628ad93fc79390c2f2
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Tue Aug 2 11:31:50 2016 -0400
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Tue Aug 2 11:42:45 2016 -0400

Intel-C: declare support for gnu11

Without extensions, functions like `strdup` are not available since they
are actually controlled by feature flags such as _SVID_SOURCE and
_BSD_SOURCE. When using `-std=c11` on Intel, none of these flags are
set, so the functions are not declared properly leading to compile
errors.

Reported-by: Adam J. Stewart <ajstewart...@gmail.com>
Closes: #16226

diff --git a/Modules/Compiler/Intel-C.cmake b/Modules/Compiler/Intel-C.cmake
index eb9602a..b2ff50d 100644
--- a/Modules/Compiler/Intel-C.cmake
+++ b/Modules/Compiler/Intel-C.cmake
@@ -16,7 +16,7 @@ endif()
 
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 15.0.0)
   set(CMAKE_C11_STANDARD_COMPILE_OPTION "${_std}=c11")
-  set(CMAKE_C11_EXTENSION_COMPILE_OPTION "${_std}=c11")
+  set(CMAKE_C11_EXTENSION_COMPILE_OPTION "${_std}=gnu11")
 endif()
 
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 12.1)

---

Summary of changes:
 Modules/Compiler/Intel-C.cmake |8 
 1 file changed, 4 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-819-g33aaf51

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  33aaf5180f12918392bd158c1c7278f4c83bc922 (commit)
   via  0b7c209610d1d24db3e8569b4fe8df98d138d6bb (commit)
  from  7650a137f25afc846e64a3ce9fd3da04a401a9ec (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=33aaf5180f12918392bd158c1c7278f4c83bc922
commit 33aaf5180f12918392bd158c1c7278f4c83bc922
Merge: 7650a13 0b7c209
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Wed Jul 13 09:49:15 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Jul 13 09:49:15 2016 -0400

Merge topic 'geh-visibility-flag' into next

0b7c2096 GenerateExportHeader: always fill in _EXPORT macros


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b7c209610d1d24db3e8569b4fe8df98d138d6bb
commit 0b7c209610d1d24db3e8569b4fe8df98d138d6bb
Author: Ben Boeckel <ben.boec...@kitware.com>
AuthorDate: Mon Jul 11 14:52:05 2016 -0400
Commit: Ben Boeckel <ben.boec...@kitware.com>
CommitDate: Mon Jul 11 15:19:14 2016 -0400

GenerateExportHeader: always fill in _EXPORT macros

The `_EXPORT` and `_NO_EXPORT` macros should always be made properly
because the `_VISIBILITY_PRESET` properties are controlled
independently of this module.

One case where this breaks compatibility is where a project was setting
`USE_COMPILER_HIDDEN_VISIBILITY=OFF` and then marking a symbol used
outside of the library with `_NO_EXPORT` which is a contridiction.

diff --git a/Modules/GenerateExportHeader.cmake 
b/Modules/GenerateExportHeader.cmake
index 6389d30..1f67724 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -223,9 +223,6 @@ macro(_test_compiler_hidden_visibility)
 check_cxx_compiler_flag(-fvisibility=hidden COMPILER_HAS_HIDDEN_VISIBILITY)
 check_cxx_compiler_flag(-fvisibility-inlines-hidden
   COMPILER_HAS_HIDDEN_INLINE_VISIBILITY)
-option(USE_COMPILER_HIDDEN_VISIBILITY
-  "Use HIDDEN visibility support if available." ON)
-mark_as_advanced(USE_COMPILER_HIDDEN_VISIBILITY)
   endif()
 endmacro()
 
@@ -275,7 +272,7 @@ macro(_DO_SET_MACRO_VALUES TARGET_LIBRARY)
 if(WIN32 OR CYGWIN)
   set(DEFINE_EXPORT "__declspec(dllexport)")
   set(DEFINE_IMPORT "__declspec(dllimport)")
-elseif(COMPILER_HAS_HIDDEN_VISIBILITY AND USE_COMPILER_HIDDEN_VISIBILITY)
+elseif(COMPILER_HAS_HIDDEN_VISIBILITY)
   set(DEFINE_EXPORT "__attribute__((visibility(\"default\")))")
   set(DEFINE_IMPORT "__attribute__((visibility(\"default\")))")
   set(DEFINE_NO_EXPORT "__attribute__((visibility(\"hidden\")))")
@@ -388,6 +385,9 @@ function(add_compiler_export_flags)
   _test_compiler_hidden_visibility()
   _test_compiler_has_deprecated()
 
+  option(USE_COMPILER_HIDDEN_VISIBILITY
+"Use HIDDEN visibility support if available." ON)
+  mark_as_advanced(USE_COMPILER_HIDDEN_VISIBILITY)
   if(NOT (USE_COMPILER_HIDDEN_VISIBILITY AND COMPILER_HAS_HIDDEN_VISIBILITY))
 # Just return if there are no flags to add.
 return()
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt 
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index 8b94ca7..875b0cf 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -124,10 +124,8 @@ if (WIN32 OR CYGWIN)
   else()
 set(_platform WinEmpty)
   endif()
-elseif(COMPILER_HAS_HIDDEN_VISIBILITY AND USE_COMPILER_HIDDEN_VISIBILITY)
+elseif(COMPILER_HAS_HIDDEN_VISIBILITY)
   set(_platform UNIX)
-elseif(COMPILER_HAS_DEPRECATED)
-  set(_platform UNIX_DeprecatedOnly)
 else()
   set(_platform Empty)
 endif()
diff --git 
a/Tests/Module/GenerateExportHeader/reference/UNIX_DeprecatedOnly/libshared_export.h
 
b/Tests/Module/GenerateExportHeader/reference/UNIX_DeprecatedOnly/libshared_export.h
deleted file mode 100644
index 808ff01..000
--- 
a/Tests/Module/GenerateExportHeader/reference/UNIX_DeprecatedOnly/libshared_export.h
+++ /dev/null
@@ -1,42 +0,0 @@
-
-#ifndef LIBSHARED_EXPORT_H
-#define LIBSHARED_EXPORT_H
-
-#ifdef LIBSHARED_STATIC_DEFINE
-#  define LIBSHARED_EXPORT
-#  define LIBSHARED_NO_EXPORT
-#else
-#  ifndef LIBSHARED_EXPORT
-#ifdef libshared_EXPORTS
-/* We are building this library */
-#  define LIBSHARED_EXPORT
-#else
-/* We are using this library */
-#  define LIBSHARED_EXPORT
-#endif
-#  endif
-
-#  ifndef LIBSHARED_NO_EXPORT
-#define LIBSHARED_NO_EXPORT

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] Ninja + parallel linking

[Ben Boeckel]

On Fri, Jul 08, 2016 at 11:40:38 -0400, Brad King wrote:
> This happens because CMake generates order-only dependencies on the
> compilation rules of each exe/lib's objects to make sure the do not
> compile until linking of dependencies is done.  This makes the build
> semantics match that of other generators where each logical target is
> treated as its own isolated build that is evaluated only when its
> logical target dependencies have been finished.
> 
> This is unfortunately necessary to get correct builds for CMake projects
> in general because we support cases where add_custom_command is used
> in library "foo" to generate a header file that is included during
> compilation in library "bar" that links to "foo", but we have no good
> way to express this dependency besides the ordering dependency of bar
> on foo.
> 
> It is likely possible to detect causes automatically when this is
> not necessary, such as when the transitive closure of a target's
> dependencies contains no custom commands.  A dedicated effort will be
> needed to investigate this further and implement such optimizations
> on the build graph generation.

There's an issue for this already:

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

I've brainstormed how to detect when the dependencies can be dropped
(it's on some paper around here somewhere...), but haven't implemented
it yet.

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

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] [cmake-developers] [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

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