Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

On 24/08/18 02:32, David Blaikie wrote:
On Tue, Jul 24, 2018 at 3:20 PM Stephen Kelly <mailto:steve...@gmail.com>> wrote:


David Blaikie wrote:

> (just CC'ing you Richard in case you want to read my
ramblings/spot any
> inaccuracies, etc)
>
> Excuse the delay - coming back to this a bit now. Though the varying
> opinions on what modules will take to integrate with build
system still
> weighs on me a bit

Can you explain what you mean by 'weighs on you'? Does that mean
you see it
as tricky now?


Yes, to some extent. If the build system is going to require the 
compiler-callsback-to-buildsystem that it sounds like (from 
discussions with Richard & Nathan, etc) is reasonable - yeah, I'd say 
that's a bigger change to the way C++ is compiled than I was 
expecting/thinking of going into this.


Yes.


I've kind of been assuming that people generally think it is not
tricky, and
I'm just wrong in thinking it is and I'll eventually see how it is
all
manageable.


I think it's manageable - the thing that weighs on me, I suppose, is 
whether or not the community at large will "buy" it, as such.


Yes, that has been my point since I first started talking about modules. 
I don't think modules will gain a critical mass of adoption as currently 
designed (and as currently designed to work with buildsystems).


And part of that is on the work we're doing to figure out the 
integration with build systems, etc, so that there's at least the 
first few pieces of support that might help gain user adoption to 
justify/encourage/provide work on further support, etc...


Yes, reading the document Nathan sent us on June 12th this year, it 
seems that CMake would have to implement a server mode so that the 
compiler will invoke it with RPC. That server will also need to consume 
some data generated by CMake during buildsystem generation (eg user 
specified flags) and put that together with information sent by the 
compiler (eg ) in order to formulate a response. It's complex. Maybe 
CMake and other buildsystem generators can do it, but there are many 
bespoke systems out there which would have to have some way to justify 
the cost of developing such a thing.



> The build.sh script shows the commands required to build it
(though I
> haven't checked the exact fmodule-file dependencies to check
that they're
> all necessary, etc) - and with current Clang top-of-tree it does
build and
> run the example dinnerparty program.

Ok. I tried with my several-weeks-old checkout and it failed on
the first
command with -modules-ts in it (for AbstractFruit.cppm - the
simplest one).

I'll update my build and try again, but that will take some time.


Huh - I mean it's certainly a moving target - I had to file/workaround 
a few bugs to get it working as much as it is, so not /too/ 
surprising. Did you get it working in the end? If not, could you 
specify the exact revision your compiler's at and show the complete 
output?


Yes, I got it working. See

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



> But I'm not sure how best to determine the order in which to
build files within a library - that's where the sort of -MM-esque
stuff, etc, would be
> necessary.

Would it? I thought the -MM stuff would mostly be necessary for
determining
when to rebuild? Don't we need to determine the build order before
the first
build of anything? The -MM stuff doesn't help that.


-MM produces output separate from the compilation (so far as I can 
tell - clang++ -MM x.cpp doesn't produce anything other than the 
makefile fragment on stdout) & finds all the headers, etc. So that's 
basically the same as what we'd need here


Are you sure? I thought compiling with -MM gives us information that we 
need before we compile the first time. Sorry if that was not clear from 
what I wrote above. I see a chicken-egg problem. However, I assume I'm 
just misunderstanding you (you said that -MM would be used to determine 
build order for the initial build) so let's just drop this.


Looking at your example - if you have a library for all the fruits and 
libabstractfruit, libfruitsalad, libnotfruitsalad, and libbowls - then 
you'd have one module interface for each of those (AbstractFruit.cppm, 
FruitSalad.cppm, NotFruitSalad.cppm, Bowls.cppm) that would be 
imported (so replace "import Apple", "import Grape" with "import 
FruitSalad", etc... ) & the implementations could be in multiple files 
if desired (Apple.cpp, Grape.cpp, etc).


Could you show me what that would look like for the repo? I am 
interested to know if this approach means concatenating the content of 
multiple files (eg Grape.h and Apple.h) and porting that result to a 
module. My instinct says that won't gain adoption.



>&g

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

Stephen Kelly wrote:
>> The build.sh script shows the commands required to build it (though I
>> haven't checked the exact fmodule-file dependencies to check that they're
>> all necessary, etc) - and with current Clang top-of-tree it does build
>> and run the example dinnerparty program.
> 
> Ok. I tried with my several-weeks-old checkout and it failed on the first
> command with -modules-ts in it (for AbstractFruit.cppm - the simplest
> one).
> 
> I'll update my build and try again, but that will take some time.

I have locally tried your modifications. Aside from the content of my 
previous email, I updated my clone (force push) to clean up the commits, and 
to modify your build.sh script to maintain the different libraries in the 
repo.

 https://github.com/steveire/ModulesExperiments/commits/master

I am still interested in what the C++ code (and build.sh) look like in the 
case of one-module-per-library. 

It is obvious from looking at build.sh as it is that the buildsystem needs 
to be changed when adding a new import to a c++ file, as I have described. 
see the commit adding Grape separately and the changes required to the 
buildsystem which were not required in the non-modules world:

 https://github.com/steveire/ModulesExperiments/commit/428bea53fc6

I will see if I can get a recent GCC build for comparison and to determine 
whether the callback-to-the-buildsystem used in GCC makes a difference in 
that respect.

I'm still interested in a response to my previous email in that respect.

Thanks,

Stephen.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

David Blaikie wrote:

> (just CC'ing you Richard in case you want to read my ramblings/spot any
> inaccuracies, etc)
> 
> Excuse the delay - coming back to this a bit now. Though the varying
> opinions on what modules will take to integrate with build system still
> weighs on me a bit

Can you explain what you mean by 'weighs on you'? Does that mean you see it 
as tricky now? 

I've kind of been assuming that people generally think it is not tricky, and 
I'm just wrong in thinking it is and I'll eventually see how it is all 
manageable.

> - but I'm trying to find small ways/concrete steps to
> make some progress on this rather than being lost in choice/opinion
> paralysis.

Cool.

> To that end, Stephen, I've made a fork of your example repository & a very
> simple/direct change to use C++ modules as currently implemented in Clang.

Interesting, thanks for doing that! Here's the link for anyone else 
interested:

 https://github.com/dwblaikie/ModulesExperiments

> The build.sh script shows the commands required to build it (though I
> haven't checked the exact fmodule-file dependencies to check that they're
> all necessary, etc) - and with current Clang top-of-tree it does build and
> run the example dinnerparty program.

Ok. I tried with my several-weeks-old checkout and it failed on the first 
command with -modules-ts in it (for AbstractFruit.cppm - the simplest one).

I'll update my build and try again, but that will take some time.

> If you happen to try experimenting with any ways the commands in the
> build.sh file could be run from CMake it a sensible way - even if you
> hypothesize what -MM support (or other compiler hooks like the dependency
> server I alluded to above, etc) for modules might look like to do so, I'd
> love to chat about it/throw ideas around/try mocking up/prototyping the
> sort of compiler support (I don't think there's -MM support yet, but I
> could see about adding it, for example) that seems like it might be most
> useful.

Yes, that would be useful I think.

> One thing I'm vaguely concerned about is actually the dependency of
> building modules within a single library (as in this project/example - at
> least the way I've built it for now - I didn't try building it as separate
> .so/.a files). At least across-library we can work at the library
> granularity and provide on the command line (or via a file as GCC does)
> the module files for all the modules from dependent libraries. But I'm not
> sure how best to determine the order in which to build files within a
> library

Exactly, that's one of the reasons my repo has libraries of multiple files 
with dependencies between them, but building everything into one executable 
also exposes that issue.

I guess it would work in a similar way to determining the order to link 
libraries though, so probably not a major problem.

> - that's where the sort of -MM-esque stuff, etc, would be
> necessary.

Would it? I thought the -MM stuff would mostly be necessary for determining 
when to rebuild? Don't we need to determine the build order before the first 
build of anything? The -MM stuff doesn't help that.

>> It seems quite common to have one PCH file per shared library (that's
>> what Qt does for example). What makes you so sure that won't be the case
>> with modules?
>>
> 
> Can't say I've worked with code using existing PCH - if that seems common
> enough, it might be a good analogy/guidance people might follow with C++
> modules.

Perhaps. I wonder how the C++ code/build.sh code would change in that 
scenario? If there were only four modules - one for each of the libraries 
(as delimited in the CMakeLists). Would the C++ code change then too 
(something about building partial modules from each of the multiple cppm 
files?), or how would the build.sh code change?

>> Ok. That's not much better though. It still means editing/generating the
>> buildsystem each time you add an import.
> 
> 
> Isn't that true today with headers, though? 

No. Imagine you implemented FruitBowl.cpp in revision 1 such that it did not 
#include Grape.h and it did not add the Grape to the bowl.

Then you edit FruitBowl.cpp to #include Grape.h and add the Grape to the 
bowl. Because Grape.h and Apple.h are in the same directory (which you 
already have a -Ipath/to/headers for in your buildsystem), in this (today) 
scenario, you don't have to edit the buildsystem.

In your port, you would have to add an import of Grape (fine, equivalent), 
add the Grape to the bowl (the same as today), but additionally, you have to 

 * add -fmodule-file=Grape.pcm to the compile line or run your buildsystem 
generator such as CMake to cause that compile line to be generated with the 
argument added.
 * Generate Grape.pcm (because the library has 1000 fruit classes in it and 
your buildsystem is smart enough to 

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

David Blaikie wrote:

>> Nope, scratch that ^ I had thought that was the case, but talking more
>> with Richard Smith it seems there's an expectation that modules will be
>> somewhere between header and library granularity (obviously some small
>> libraries today have one or only a few headers, some (like Qt) have many
>> - maybe those on the Qt end might have slightly fewer modules than the
>> have headers - but still several modules to one library most likely, by
>> the sounds of it)
>>
>>
>> Why? Richard maybe you can answer that? These are the kinds of things I
>> was trying to get answers to in the previous post to iso sg2 in the
>> google group. I didn't get an answer as definitive as this, so maybe you
>> can share the reason behind such a definitive answer?
>>
> 
> It's more that the functionality will allow this & just judging by how
> people do things today (existing header granularity partly motivated by
> the cost of headers that doesn't apply to modules), how they're likely to
> do things in the future (I personally would guess people will probably try
> to just port their headers to modules - and a few places where there are
> circular dependencies in headers or the like they might glob them up into
> one module).


It seems quite common to have one PCH file per shared library (that's what 
Qt does for example). What makes you so sure that won't be the case with 
modules?

I'd say that what people will do will be determined by whatever their tools 
optimize for. If it is necessary to list all used modules on the compile 
line, people would choose fewer modules. If 'import QtCore' is fast and 
allows the use of QString and QVariant etc and there is no downside, then 
that will be the granularity offered by Qt (instead of 'QtCore.QString'). 
That is also comparable to '#include ' which is possible today.

>> I just looked through the commits from Boris, and it seems he made some
>> changes relating to -fmodule-file=. That still presupposes that all
>> (transitively) used module files are specified on the command line.
>>
> 
> Actually I believe the need is only the immediate dependencies - at least
> with Clang's implementation.

Ok. That's not much better though. It still means editing/generating the 
buildsystem each time you add an import. I don't think a model with that 
requirement will gain adoption.

>> I was talking about the -fprebuilt-module-path option added by Manman Ren
>> in https://reviews.llvm.org/D23125 because that actually relieves the
>> user/buildsystem of maintaining a list of all used modules (I hope).
>>
> 
> *nod* & as you say, GCC has something similar. Though the build system
> probably wants to know about the used modules to do dependency analysis &
> rebuilding correctly. 

Yes, presumably that will work with -MM.

> Yeah, thanks for the link - useful to read.

There seems to be a slew of activity around modules at the moment. You can 
read some other reactions here which might have input for your paper:

https://www.reddit.com/r/cpp/comments/8jb0nt/what_modules_can_actually_provide_and_what_not/

https://www.reddit.com/r/cpp/comments/8j1edf/really_think_that_the_macro_story_in_modules_is/

I look forward to reading your paper anyway.

>> I think clang outputs the definitions in a separate object file, but GCC
>> currently doesn't. Perhaps that's a difference that cmake has to account
>> for or pass on to the user.
>>
> 
> Clang outputs frontend-usable (not object code, but serialized AST usable
> for compiling other source code) descriptions of the entire module
> (whatever it contains - declarations, definitions, etc) to the .pcm file.
> It can then, in a separate step, build an object file from the pcm. I
> think GCC produces both of these artifacts in one go - but not in the same
> file.

Ok, I must have misremembered something.


>> Sure. I didn't notice anything from reading, but I also didn't try it
>> out. You might need to provide a repo with the module.modulemap/c++ files
>> etc that are part of your experiment. Or better, provide something based
>> on modules-ts that I can try out.
>>
> 
> *nod* I'll see if I can get enough of modules-ts type things working to
> provide some examples, but there's some more variance/uncertainty there in
> the compiler support, etc.

Something working only with clang for example would be a good start.

>> I'm guessing that's enough for you to implement what you want as an
>> experiment?
>>
> 
> OK, so in that case it requires source changes to cmake? *nod* sounds
> plausible - I appreciate the pointers. I take it that implies there's not
> a way I could hook into those file kinds and filters without changing
> cmake

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

Brad King wrote:

> On 05/07/2018 12:01 PM, Stephen Kelly wrote:
>> Hopefully Brad or someone else can provide other input from research
>> already done.
> 
> I'm not particularly familiar with what compiler writers or the modules
> standard specification expects build systems to do w.r.t modules.
> However, IIUC at least at one time the expectation was that the module
> files would not be installed like headers and are used only within a
> local build tree.  Are modules even supposed to be first-class entities
> in the build system specification that users write?

The answer is probably both 'hopefully not' and 'sometimes'.

> In the Fortran world users just list all the sources and build systems are
> expected to figure it out.  CMake has very good support for Fortran
> modules. Our Ninja generator has rules to preprocess the translation units
> first, then parse the preprocessed output to extract module definitions
> and usages, then inject the added dependencies into the build graph, and
> then begin compilation of sources ordered by those dependencies (this
> requires a custom fork of Ninja pending upstream acceptance).
> 
> Is that what is expected from C++ buildsystems for modules too?


Hopefully. However, in some cases, the step of 'extracting module 
definitions and usages' might be very hard to do. This document is quite 
concise about that:

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1052r0.html

So, the answer for cmake might be that CMake can learn to extract that 
stuff, but ignore certain cases like imports within ifdefs. Maybe CMake 
could then also provide API for users to specify the usages/dependencies 
explicitly in those cases. I don't know how convenient that would be (or 
could be made through design).

Thanks,

Stephen.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

dules - given a
> set of C++ definitions, it's not 100% constrained how those
> definitions are exposed as modules - the developer has some freedom
> over how the declarations of those entities are grouped into modules.

Yes, exactly. This repo is small, but has a few libraries, so if we
start with one approach we should be easily able to also try a different
approach and examine what the difference is and what it means.

>  
>
> After that, is there one importable module per class or one per
> shared library (which I think would make more sense for Qt)?
>
>
> Apparently (this was a surprise to me - since I'd been thinking about
> this based on the Clang header modules (backwards compatibility stuff,
> not the standardized/new language feature modules)) the thinking is
> probably somewhere between one-per-class and one-per-shared-library.
> But for me, in terms of how a build file would interact with this,
> more than one-per-shared-library is probably the critical tipping point.

Yes. I think you're talking about the one-module-file-per-library and
*not*-one-module-file-per-library distinction I mentioned above.

> If it was just one per shared library, then I'd feel like the
> dependency/flag management would be relatively simple. You have to add
> a flag to the linker commandline to link in a library, so you have to
> add a flag to the compile step to reference a module, great. But, no,
> bit more complicated than that given the finer granularity that's
> expected here.

"finer granularity that's *allowed* here" really. If there is a simple
thing for the user to do (ie one-module-file-per-library), then cmake
can make that simple to achieve (because the dependencies between
modules are the same as dependencies between targets, which the user
already specifies with target_link_libraries).

If the user wants to do the more complicated thing
(*not*-one-module-file-per-library), then cmake can provide APIs for the
user to do that (perhaps by requiring the user to explicitly specify the
dependencies between modules).

My point is that cmake can design optimize for the easy way and I think
users will choose the easy way most of the time.
 
>
> The git repo is an attempt to make the discussion concrete because
> it would show how multiple classes and multiple libraries with
> dependencies could interact in a modules world. I'm interested in
> what it would look like ported to modules-ts, because as far as I
> know, clang-modules and module maps would not need porting of the
> cpp files at all.
>
>
> Right, clang header-modules is a backwards compatibility feature. It
> does require a constrained subset of C++ to be used to be effective
> (ie: basically your headers need to be what we think of as
> ideal/canonical headers - reincludable, independent, complete, etc).
> So if you've got good/isolated headers, you can port them to Clang's
> header modules by adding the module maps & potentially not doing
> anything else - though, if you rely on not changing your build system,
> then that presents some problems if you want to scale (more cores) or
> distribute your build. Because the build system doesn't know about
> these  dependencies - so if you have, say, two .cc files that both
> include foo.h then bar.h - well, the build system runs two compiles,
> both compiles try to implicitly build the foo.h module - one blocks
> waiting for the other to complete, then they continue and block again
> waiting for bar.h module to be built. If the build system knew about
> these dependencies (what Google uses - what we call "explicit
> (header)modules") then it could build the foo.h module and the bar.h
> module in parallel, then build the two .cc files in parallel.

I think that the 'build a module' step should be a precondition to the
compile step. I think the compiler should issue an error if it
encounters an import for a module it doesn't find a file for. No one
expects a linker to compile foo.cpp into foo.o and link it just because
it encounters a fooFunc without a definition which was declared in foo.h.

That would reduce the magic and expect something like

 add_cxx_module(somename somefile.h otherfiles.h)

to specify a module file and its constituent partitions, which I think
is fine.

>> Basically: What do folks think about supporting these sort of
>> features in CMake C++ Builds? Any pointers on how I might best
>> implement this with or without changes to CMake?
>
> I think some design is needed up front. I expect CMake would want
> to have a first-class (on equal footing with include directories
> or compile definitions and with particular handling) concept for
> modules, extending the install(TARGET) command to install module
> binary files etc.
>
>
> Module binary files wouldn't be installed in the sense of being part
> of the shipped package of a library - because module binary files are
> compiler/flag/etc specific.

Ok.

Thanks,

Stephen.

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[cmake-developers] Embracing Modern CMake Video and Slides

[Stephen Kelly]

Hi,

I know I'm not active here at the moment, but I thought this post might be 
interesting for some here:

 https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Question about ALIAS targets

[Stephen Kelly]

David Cole via cmake-developers wrote:

> Is there a good reason why this error must be an error?
> 
> CMake Error at CMakeLists.txt:23 (add_library):
>   add_library cannot create ALIAS target "MyProj::gtest" because
>   target "OtherProj::googletest" is IMPORTED.
> 
> The line of code is:
> 
> add_library(MyProj::gtest ALIAS OtherProj::googletest)
> 
> Why is there any restriction on ALIAS targets about what sorts of
> targets they may be aliases of?

They were introduced here:

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=370bf554151a1

Aside from the information there, other commits may have extended or tweaked 
the features/restrictions.


> After my find_package(OtherProj) call, which is a super build which
> defines lots of imported targets, I want the target to be named gtest
> to match its library name, but OtherProj has named it googletest.

Why isn't there a standard name? Should upstream provide the imported 
target? Has any effort been made to make upstream provide it? Is the name 
from OtherProj namespaced? Why do you need it to have a particular name? Why 
does OtherProj expose it? Should it expose that target for you to use (it 
seems an internal thing to me)?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Florent Castelli wrote:

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

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

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

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

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

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

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

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] deprecate check_function_exists?

[Stephen Sorley]

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

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

-Stephen Sorley

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

> On 01/11/2017 03:59 PM, Stephen Sorley wrote:
> > So, could check_function_exists() be explicitly deprecated in the
> > documentation in favor of check_symbol_exists()?
>
> Yes.  Please submit a MR with proposed documentation updates.
>
> There may still be use cases for the test that `check_function_exists`
> performs, so I don't want to add an actual deprecation warning to it.
> A documentation update will be fine though.
>
> Thanks,
> -Brad
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] deprecate check_function_exists?

[Stephen Sorley]

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

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

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

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

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


Thanks!

Stephen Sorley
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Stephen Kelly]

Craig Scott wrote:

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

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

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

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

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

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

 cmake_policy(VERSION 3.2)
 project(foo)

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

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

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

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

Others include 

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

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

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

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

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Stephen Kelly]

René J.V. Bertin wrote:

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

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

Thanks,

Steve.
 

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Stephen Kelly]

René J.V. Bertin wrote:

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

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

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

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

 add_executable(etc)



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

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] cm(Generator)Target::IsFrameworkOnApple

[Stephen Kelly]

Gregor Jasny via cmake-developers wrote:

> Hello,
> 
> it looks like that during Generator Target refactoring the
> cm(Generator)Target::IsFrameworkOnApple and similar got duplicated. Is
> there a reason for this or could the GeneratorTarget simply query the
> Target?

Hi Gregor,

The intention of my refactoring effort was to make generate-time classes 
like cmGeneratorTarget not depend on configure-time classes like cmTarget 
and cmMakefile at all. The cmMakefile class at least is tightly integrated 
to the current cmake language. I've made some effort to remove some of the 
other non-language related responsibilities it has, but there is more to do. 
I've also put work into to making cmGeneratorTarget not depend on cmTarget, 
but there is more to do there too.

Isolating the different classes would be a step along the way to introducing 
a new cmake language. It would also make better cross-compiling features 
possible such as multi-configuration builds (host+target etc).

> Do you have by any chance some high level design documentation about the
> most important involves classes like the various generators, target,
> makefile, etc? I sometimes wonder where to place a new function and
> would like to get some more background.

I think such a thing would be out of date quite quickly, but the best 
guideline I can give is to try to separate the code which is dependent on 
cmMakefile+cmTarget from the code dependent on generators+cmGeneratorTarget.

Do you have a more-specific query?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 property to get all linked libraries including transitive ones

[Stephen Kelly]

Brad King wrote:

> On 11/04/2016 09:52 AM, maikel van den Hurk wrote:
>> What about doing what was targeted with this bug:
>> https://cmake.org/Bug/view.php?id=12435?
> 
> That issue is now tracked here:
> 
>  https://gitlab.kitware.com/cmake/cmake/issues/12435
> 
> I've just added some notes to the discussion.
> 
> Steve, do you recall why $
> is not transitive as genexes for other usage requirements are?

I believe it's because of a chicken-egg concern - the link libraries are the 
basis for transitivity for other properties. I remember discussing that in 
the mailing list back in the design phase.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

[Stephen Kelly]

Brad King wrote:

 out of place in cmLocalGenerator. If it were returned from
 cli.GetItems,
>>>
>>> Yes, it could be moved.
>> 
>> Ok. I might look into that.
> 
> It looks like OutputLinkLibraries currently puts the flag in the
> linkLibs (which goes to the  placeholder) but it
> would more sensibly be located in the linkFlags (which goes to
> the  placeholder).  If we do clean this up it should
> be moved to .  Therefore it should not go in GetItems,
> but instead in a separate helper that all generators can share.

Do you know what CMAKE_EXE_EXPORTS_${lang}_FLAG is? It is added to the 
linkFlags already for executables with exports.

For Linux, it contains 

 "-Wl,--export-dynamic"

CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS contains

 "-rdynamic"

for Linux-GNU.

According to 

 https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

rdynamic means:

 "Pass the flag -export-dynamic to the ELF linker, on targets that support 
it."

Is CMP0065 adding redundant flags?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

[Stephen Kelly]

Brad King wrote:

> The variable name refers to flags needed when linking an executable *to*
> shared libraries.  It is a terrible name that has been around since the
> earliest days.  One could rename the variable in our own platform files
> but would have to also honor the old name just in case.

That wouldn't be a rename. The infinite compatibility promises of CMake 
concern me. 

A policy could be added but those are also defined to never expire, so while 
they help users migrate, they don't help clean up code.

End result: do nothing.

>> Also, shouldn't that code be part of cmComputeLinkInformation? It seems
>> out of place in cmLocalGenerator. If it were returned from cli.GetItems,
>> then cmLocalVisualStudio7GeneratorInternals::OutputLibraries and
>> cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it,
>> which as far as I can tell they currently do not. Should/do those
>> generators support ENABLE_EXPORTS?
> 
> Yes, it could be moved.  It hasn't really mattered because the variable
> is not populated on the platforms supported by those other generators.

Ok. I might look into that.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

[Stephen Kelly]

Hi,

I have encountered the implementation of CMP0065. As far as I can see, this 
is the only use of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS, and it is not 
used for shared libraries, but for executables.

Finding uses of variables like that is hard because they could be composed 
like

 "CMAKE_"
 + targetType 
 + "_LINK_"
 + lang
 + "_FLAGS";

which is hard to find with grep.

Am I missing something or is that also used for shared libraries? Or should 
the variable be renamed? Or should CMP0065 be using some other appropriate 
variable?

Also, shouldn't that code be part of cmComputeLinkInformation? It seems out 
of place in cmLocalGenerator. If it were returned from cli.GetItems, then 
cmLocalVisualStudio7GeneratorInternals::OutputLibraries and 
cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it, 
which as far as I can tell they currently do not. Should/do those generators 
support ENABLE_EXPORTS?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Generator options per-directory v. global

[Stephen Kelly]

Brad King wrote:

> On 10/05/2016 06:38 PM, Stephen Kelly wrote:
>> The suggestion to use the first cmMakefile for these kinds of definitions
>> is a good one
>> 
>> 1) It can be documented that the variable can only be set in the top
>> level 2) It is what people already do probably
>> 3) It is more convenient than the API for setting cache or global
>> properties
> 
> That makes sense, but the codelite feature is just following a
> long-standing convention used for many settings.  If you want to
> make a sweeping effort to formalize this kind of scoping then that
> is fine with me.  Mostly I think it will be documenting that the
> value of the variable at the end of the top-level CMakeLists.txt
> file is the one that is used.  In some cases that may involve
> fixing generators to actually use that one.

Ok. I started by adjusting the new CodeLite feature. I based it on an early 
commit so that it can be merged to the release branch. The sweep belongs in 
master for the following release I think.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Generator options per-directory v. global

[Stephen Kelly]

Craig Scott wrote:

> I'm coming in half way to this discussion, so apologies if my comments
> interspersed below are not so well related to the core topic of
> discussion.

Hi Craig,

Thanks for your input.

> Consider the following example which perhaps better shows that this
> problem may not be as uncommon as first thought:
> 
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption")
> add_library(foo ...)
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse")
> 
> I think most developers probably expect foo to not have the -somethingElse
> option when it is compiled, but I believe it would have it. 

The difference occurs depending on when the value is read. See my 
CMAKE_CXX_STANDARD example below.

> If I understand things correctly, directory *properties* don't typically
> have this unexpected behaviour as their value at the time of defining the
> targets is used, not at the end of that directory's processing. 

It all depends on when the value is read. Something that is read at 
configure-time appears to have immediate effect, regardless of whether it is 
a 'directory property' or a set() 'definition'. 

When something that is read at generate-time (such as CMAKE_CXX_FLAGS) it 
takes on the value at the end of the directory.

You might be referring to things like this, which are still 'definitions' 
not 'directory properties':

 set(CMAKE_CXX_STANDARD 11)

 # Reads CMAKE_CXX_STANDARD 'now' at configure time
 add_executable(foo ...)

 set(CMAKE_CXX_STANDARD 14)

 # Reads CMAKE_CXX_STANDARD 'now' again!
 add_executable(bar ...)


The important distinction is where in the CMake C++ code the 
cmMakefile::GetDefinition call occurs - generate-time code or configure-time 
code.

This is a sideline just for your information. What this thread is really 
about is whether things should be read 'only once' or 'once per directory', 
and whether the CMake C++ code chooses one or the other deliberately or 
accidentally, and what impact that has on maintainability and refactoring.

> this behaviour of using the
> variable's value at the end of the directory processing is likely a
> surprise to many and probably already causes some head-scratching until
> devs figure it out. Is the problem being discussed here relating to
> CMAKE_CODELITE_USE_TARGETS
> much different?

It seems like a related example to me. The CMAKE_CODELITE_USE_TARGETS 
feature is trying to be related to a project() command, but it is read at 
the end of the directory. Usually, I would think that is not a problem the 
way most people write project() commands and set these kinds of settings.

However, in the general sense of how 'global' settings should work, I think 
things could be better.

>> Those are not problems users or contributors adding features encounter,
>> so that might affect a perception of 'big'ness. These problems only
>> bubble up during refactoring or under longer-term maintenance when the
>> true semantics of the code become known.
>>
> 
> Perhaps a bit more common than that, as the above example suggests.

Yes, those kinds of examples are the things that I would expect to arise 
during maintenance, perhaps several releases after a feature hits master.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [ANNOUNCE] CMake 3.7.0-rc1 now ready for testing!

[Stephen Kelly]

Robert Maynard wrote:

> * The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS"
> option to change project creation from projects to targets.


Something that I have often noticed (and which causes problems) in my 
refactoring is that per-directory variable definitions are used when they 
are not appropriate or intended. 

This causes problems because now the code has to read the value for each 
directory and can't assume that the value is always the same as the value 
from the top-level CMakeLists file. It adds complexity to the code which 
could otherwise be removed.

In some cases (language-specific definitions) the definition may not be 
defined in the top level due to an enable_language() in a subdirectory. As 
far as I know, in other sibling directories the language can still be used, 
so the variable definitions are telling an inconsistent story in that case. 
Perhaps enable_language should only be allowed in the top-level.

This CodeLite variable looks like an example of this misuse of variable 
definitions too. It is read via cmMakefile::IsOn. That means that different 
directories can set it to different values, which is probably not the 
intention of the author of the feature, and it means that that (probably 
broken) behavior needs to be preserved.

Does CMake need a 'better answer' to the question of 'how to add features 
like this to CMake'? 

Is the answer 'Use global properties or a cache variable instead'?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 version to build CMake

[Stephen Kelly]

Brad King wrote:

> On 09/07/2016 06:44 PM, Stephen Kelly wrote:
>> ALIAS targets were introduced in CMake 2.8.12 (released August 2013).
>> 
>> What do you think of updating the requirement to that or higher?
> 
> Fine with me.  It really only matters on platforms where one cannot use
> the bootstrap script.  Let's go to 3.0 so we have the option to use the
> bracket argument syntax.

Are there dashboard machines which need to be updated first?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMake version to build CMake

[Stephen Kelly]

Hi,

Currently CMake requires a minimum of CMake 2.8.4 to build.

I was reviewing the cmake-server work from Tobias starting with the libuv 
integration, and I think CMake might benefit from using ALIAS targets in its 
own build. ALIAS targets were introduced in CMake 2.8.12 (released August 
2013).

What do you think of updating the requirement to that or higher?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Stephen Kelly]

Daniel Pfeifer wrote:

> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly
> <steve...@gmail.com> wrote:
>> 3) Compute cmGeneratorTarget state non-lazily in its constructor.
>> * Historically target state for generators was computed lazily because it
>>   might need to be cleared and re-computed.  That is no-longer true.
> 
> SourceFilesMap is cleared in a call to AddSource. It is then
> recomputed the next time GetSourceFiles is called.

Hmm, maybe there is a way to reduce the amount of times it is cleared, once 
the computation sequence is better defined by being extracted to 
cmComputeTarget. cmGeneratorTarget::AddSource is currently called from 
several generate-time locations, some of which could become compute-time 
locations. The uses in 

* cmQtAutoGeneratorInitializer::InitializeAutogenSources 
* cmGlobalVisualStudio8Generator::AddCheckTarget
* cmLocalVisualStudio7Generator::CreateVCProjBuildRule
* cmGlobalXCodeGenerator

seem that way to me, because the file names don't depend on anything from 
the cmGeneratorTarget which is only known at build time. Unless I'm missing 
something, they could be added to the list of files for the cmComputeTarget  
at compute time before the SourceFilesMap is populated at generate time.

The tricky case is when AddSource is called with something computed from the 
result of cmGeneratorTarget::GetSources. The only case of that seems to be 
SetupSourceFiles in cmQtAutoGeneratorInitializer. That calls AddSource in a 
loop. If cmComputeTarget gains an AddSource and doesn't have a 
SourceFilesMap, then that would be the only use of 
cmGeneratorTarget::AddSource. That could then be replaced with a new 
AddSources or AddSourcesForRCC, or something better might be possible.

This is just a brain-dump which I haven't investigated. You might find some 
facts which make the source addition refactoring to compute time to be 
impossible.

Then maybe the entries of the ComputedTargets map might not have to be 
recomputed lazily.

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

Cool, thanks for working on this!

I am a bit confused by the first commit in the branch. It removes some c++ 
template code while adding cmComputeTarget. I think that's because you make 
the working class inherit from cmComputeTarget, and you do that just to re-
use the data members, and then later in the branch, to re-use the 
cmComputeTarget itself.

Is it possible to split what is happening in that commit? Is it possible to 
remove the template code first without introducing cmComputeTarget? Even if 
doing so would mean introducing a struct with the same data members early in 
the branch and perhaps removing that struct later, I think it might make the 
commit more clear. Currently I don't understand it.

I also generally recommend to put the most obvious/cleanup commits at the 
start of the branch (or even in a separate minor-cleanups branch). The 
'don't clear container in destructor' commit and the 'use erase-unique 
instead of reinitialization' commit and the 'factor out common part of 
AddSources commands' all seem to fit that description. I was able to rebase 
them at least, but I didn't try building the result. 

Getting those kinds of commits out of the way first makes the rest of the 
branch smaller and focused on extending the code in only one specific way.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] FindCUDA bug fixes

[Sorley, Stephen L.]

I've attached two patches that fix bugs in the 
CUDA_COMPILE{,_PTX,_FATBIN,_CUBIN} macros from FindCUDA.cmake.


First bug (fixed by patch #1)

Commit 7ded655 added generator expressions in CUDA_WRAP_SRCS to scrape include 
directories and compile definitions off of the target.  This works great when 
the target name passed to CUDA_WRAP_SRCS is an actual target (like in 
cuda_add_library and cuda_add_executable).  However, the CUDA_COMPILE* macros 
also use CUDA_WRAP_SRCS, and they pass in a hardcoded name that doesn't 
represent a real target.  This breaks the generator expressions, causing CMake 
to abort during generation.

I fixed this by teaching CUDA_WRAP_SRCS to check for "PHONY" in its argument 
list.  When CUDA_WRAP_SRCS sees "PHONY", it queries the appropriate directory 
properties (INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS) instead of using the 
generator expressions.  I then modified cuda_compile_base (which is used 
internally by all the CUDA_COMPILE* macros) to pass PHONY to CUDA_WRAP_SRCS.


Second bug (fixed by patch #2)

In a couple spots, CUDA_WRAP_SRCS assumes that the passed-in target name is 
unique - for example, the name of the directory containing the intermediate 
output is built from the target name.  However, the CUDA_COMPILE* macros always 
pass the same hardcoded target name.  So, if you call the same macro twice in a 
directory, some of the generated files from the second call will silently 
overwrite those from the first call.

I fixed this by adding a counter (_cuda_internal_phony_counter) as a directory 
property.  The counter gets incremented every time cuda_compile_base is called, 
and the value of the counter is appended to the hardcoded target name that gets 
passed to CUDA_WRAP_SRCS.  This ensures that each call to the macro has its own 
unique target name.


Thanks!
Stephen Sorley


0001-FindCUDA-Fix-for-broken-cuda_compile-commands.patch
Description: 0001-FindCUDA-Fix-for-broken-cuda_compile-commands.patch


0002-FindCUDA-Allow-cuda_compile-macros-to-be-called-more.patch
Description: 0002-FindCUDA-Allow-cuda_compile-macros-to-be-called-more.patch
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Bugfix: Default behavior of CUDA_USE_STATIC_CUDA_RUNTIME

[Sorley, Stephen L.]

The previous fix uncovered another bug from commit 7229ae7.  That commit 
dropped librt from the link line when using static linking with CUDA 7.0 or 
newer on Linux.  However, librt is still required on the link line in newer 
CUDA versions, I get linker errors without it.

I've attached a second patch to fix this extra bug.

Thanks!
Stephen Sorley

From: Sorley, Stephen L.
Sent: Thursday, August 11, 2016 3:37 PM
To: cmake-developers@cmake.org
Subject: Bugfix: Default behavior of CUDA_USE_STATIC_CUDA_RUNTIME

Recent changes to FindCUDA.cmake (commit 7229ae7) broke the documented behavior 
of the CUDA_USE_STATIC_CUDA_RUNTIME option.  Per the documentation, this option 
should be enabled by default if libcudart_static is present in the selected 
version of CUDA, and silently disabled if it's not.  After commit 7229ae7, the 
option is disabled by default instead.

I've attached a small patch (based on master) that fixes the problem.

Thanks!
Stephen Sorley


0001-Fix-for-missing-librt-on-Linux-when-using-static-cud.patch
Description: 0001-Fix-for-missing-librt-on-Linux-when-using-static-cud.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Bugfix: Default behavior of CUDA_USE_STATIC_CUDA_RUNTIME

[Sorley, Stephen L.]

Recent changes to FindCUDA.cmake (commit 7229ae7) broke the documented behavior 
of the CUDA_USE_STATIC_CUDA_RUNTIME option.  Per the documentation, this option 
should be enabled by default if libcudart_static is present in the selected 
version of CUDA, and silently disabled if it's not.  After commit 7229ae7, the 
option is disabled by default instead.

I've attached a small patch (based on master) that fixes the problem.

Thanks!
Stephen Sorley


0001-Restore-default-behavior-of-CUDA_USE_STATIC_CUDA_RUN.patch
Description: 0001-Restore-default-behavior-of-CUDA_USE_STATIC_CUDA_RUN.patch
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 -E capabilities [attempt 2]

[Stephen Kelly]

Tobias Hunger wrote:

> Hi Stephen,
> 
> thanks for taking the time to do such a thorough review!

Actually my review wasn't thorough at all. I didn't try to review it 
further. 

The NewFactory methods in your patch don't return a new'd object, but 
instead return static locals. The regular generators NewFactory methods 
don't work that way, so you're introducing a pattern which is different to 
what already exists and the commit message doesn't say why. Maybe there's a 
reason, but I don't know what it is. In the future, no one else will know 
either.

There are lots of things in there for which your intent is unclear. That's 
why splitting and writing descriptive commit messages is valuable. You might 
find 

 https://vimeo.com/172882423

to be a good introduction to this.

I have more to ask about your first commit (and why the second commit is 
split out). I stopped my review at recommending it be split to see what it 
is hiding. 

> Added const to some of them:-) Hope I caught all.

cmake::ReportCapabilities() should be const, right?

>> * and a whitespace change that should be squashed into the commit that
>> introduces it
> 
> I used Utilities/Scripts/clang-format.bash to do the formatting, so
> that should not be an issue. I just reran that on all commits. Maybe I
> forgot it in a commit or something before.

Maybe. Running the script on all commits would be the fix anyway.

>> * The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the
>> capabilities handling:
>>
>> #if defined(CMAKE_BUILD_WITH_CMAKE)
>> else if (args[1] == "capabilities") {
>>   cmake cm;
>>   std::cout << cm.ReportCapabilities();
>>   return 0;
>> }
>> #endif
> 
> Why?

Because it's a bit odd to return 0 if capabilities can't be reported. I 
missed that the contents of that method don't compile in bootstrap mode 
though without the define.

>> As it is, it is doing many different things, none of which are mentioned
>> in the commit message, and some of which it probably shouldn't be doing.
>>
>> For example renaming GetExtraGeneratorName to
>> GetExternalMakefileProjectGeneratorName is probably not needed. If you
>> really want to do it, then it should be in its own commit with its own
>> commit message which justifies the change. As it is, it adds noise to the
>> big commit and makes it harder to review. Minimal is always better with
>> commits which do refactoring like that.
> 
> I undid that change. That is one of the things that I originally
> removed and then realized last minute that it is needed somehow. So I
> added it, not realizing that I had removed similar functionality
> earlier.

This doesn't happen if you split commits. Splitting makes these things 
visible to you and you can decide whether they were intentional or not at 
that point.

>> A general good rule of thumb (which helps reviews, and makes things
>> bisectable in the future) is to do one thing per commit.
> 
> I agree that this is the ideal we all should all strive for, but you
> are not going to get that from me anytime soon. 

Calling it an 'ideal' isn't really the right mindset. It's easy, and it's 
generally done by all other cmake contributors.

> At least not in the cmake codebase.

I don't know what this part means. It seems somehow disdainful, but I might 
be missing something. Something to talk about in person perhaps.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 -E capabilities [attempt 2]

[Stephen Kelly]

Tobias Hunger wrote:

> Did anyone find some time for a review yet?

Hi Tobias,

I had a look through this this evening. Thanks for working on this. The 
commit adding the functionality at the end looks much better after the extra 
generator refactoring. 

Here are some review notes:

* That commit has a cmDefinitions include though that should be removed.
* There are also some methods that should be const
* and a whitespace change that should be squashed into the commit that 
introduces it
* The pretty-print flag should be removed. Aside from being a boolean trap, 
it creates a interface segregation principle violation. See eg  

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23f87e81

for more.  If you want to pretty print things on the command line I suggest 

 cmake -E capabilities | jq

which will give you colorized output, or 

 cmake -E capabilities | python -mjson.tool

for something that you already have installed. See 

 http://stackoverflow.com/questions/352098/how-can-i-pretty-print-json

for more.

* The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the 
capabilities handling:

#if defined(CMAKE_BUILD_WITH_CMAKE)
else if (args[1] == "capabilities") {
  cmake cm;
  std::cout << cm.ReportCapabilities();
  return 0;
}
#endif

That define should not be used in ReportCapabilities.

* Splitting the 'CMake: Refactor ExtraGenerator registration' commit into 
multiple commits would make it more reviewable, and more bisectable in the 
future.

As it is, it is doing many different things, none of which are mentioned in 
the commit message, and some of which it probably shouldn't be doing. 

For example renaming GetExtraGeneratorName to 
GetExternalMakefileProjectGeneratorName is probably not needed. If you 
really want to do it, then it should be in its own commit with its own 
commit message which justifies the change. As it is, it adds noise to the 
big commit and makes it harder to review. Minimal is always better with 
commits which do refactoring like that.

A general good rule of thumb (which helps reviews, and makes things 
bisectable in the future) is to do one thing per commit.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Stephen Kelly]

Sebastian Holtermann wrote:

>> 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.
> 
> I have changed that to use a NULL sentinel.
> std::array would be the best solution IMO but it is not allowed, is it?

You could use cmArrayBegin and cmArrayEnd without the sentinal. They are 
designed for this kind of thing.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Spurious warning with FindCUDA.cmake on Windows

[Sorley, Stephen L.]

Found a minor problem with FindCUDA.cmake on the master branch.  When using 
FindCUDA.cmake on Windows with CUDA SDK version 6.5 or older, CMake prints the 
following warning:

CMake Warning at cmake/FindCUDA.cmake:826 (message):
  Expecting to find librt for libcudart_static, but didn't find it.
Call Stack (most recent call first):
 cmake/build_setup.cmake:693 (find_package)
  CMakeLists.txt:42 (include)

This warning is incorrect, since librt is only present on Linux.  I've attached 
a patch (based on master) that fixes the problem.

Thanks!
Stephen S.


0001-Fix-for-spurious-CMake-warning-message-on-Windows.patch
Description: 0001-Fix-for-spurious-CMake-warning-message-on-Windows.patch
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 -E capabilities

[Stephen Kelly]

Tobias Hunger wrote:

> On So, 2016-07-03 at 12:33 +0200, Stephen Kelly wrote:
>> Tobias Hunger wrote:
>> 
>> > Either we should have multiConfig return a list of configuration names
>> > that will be generated or I do not see any need to have the information
>> > in the first place.
>> 
>> I think when using qmake with QtCreator, the user can choose the
>> configuration at build time by selecting it from the left-side menu.
> 
> I do not understand what you are getting at.
> 
> That widget already works for cmake projects in Qt Creator: It switches
> between different build directories with different configurations.

Ok. I'm not sure that worked when I tried it years ago :).

>> Such a feature would also work with cmake projects if the user chooses to
>> use the XCode generator on mac or VS generator on Windows (or if someday
>> we have a multi-config Ninja generator or so).
> 
> How is a multi-config ninja generator better than just having to build
> directories next to each other, each with one configuration? You might
> save a bit of disk space (probably not a lot). Will you save a significant
> amount of processing time?
> 
> The one benefit I can think of is switching between configurations will
> probably be a lot faster. But that is nothing that is done so often that
> it warrants optimizing for IMHO.

What I have in mind is not optimization. As you say, if this is not needed 
at this point for IDE integration, then we can drop the idea.

> Either the clients do not care or they need to know which configurations
> those are going to be.

This can be retrieved by reading the STRINGS property of the 
CMAKE_BUILD_TYPE cache variable.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 -E capabilities

[Stephen Kelly]

Tobias Hunger wrote:

> Hello CMake Developers!
> 
> As laid out in the last mail thread about daemon-mode in CMake (for your
> reference:
> http://public.kitware.com/pipermail/cmake-developers/2016-June/028777
> .html ), Stephen and me agreed that we needed a way for IDEs to figure out
> which generators are available to cmake and more static information built
> into CMake.

Here's a gmane link to the thread for reference:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16782

> There is actually a bug report about the need for this feature here:
> https://gitlab.kitware.com/cmake/cmake/issues/15462
> 
> This is my attempt to solve the issue:
> https://github.com/hunger/CMake/commits/cmake-capabilities

Thanks for working on this.

> The output looks like this:
>> cmake -E capabilities --pretty-print
> {
> "generators" : [
> {
> "extraGenerators" : [],

Interesting. I didn't realize the "Watcom WMake" generator does not work 
with 'extra' generators.

> "KDevelop3",

 This generator should probably be removed/hidden by now. It has 
confused users of more-recent KDevelop versions.

> What do you think? What else should we report here?

It looks like a good start. The intention of the output is to satisfy needs 
that consumers like you have, and I guess it does have what you need.

> Compared to the bug report mentioned above the fields "multiconfig" and
> "recursive" are missing. I could not figure out how to get that
> information:-/

When I made the example in the issue tracker, 'recursive' meant 'you can cd 
to a directory and run the CMAKE_MAKE_PROGRAM there'. At the time, it was 
possible to do that when using the Makefiles generator, but not the Ninja 
generator. 

I think that capability has since been added for the Ninja generator, but I 
don't know if it is possible with the Xcode and VS generators.

Would that be a useful thing to expose here in your view?

> I would also welcome some code review on the patch. 

1) For consistency you should change 

 GetRegisteredGenerators

to 

 this->GetRegisteredGenerators

whether that is a preferred style is orthogonal to the fact that it's 
consistently used in cmake code.

2) CMake has to build with toolchains which do not provide 
std::unordered_map. See uses of CMake_HAVE_CXX_UNORDERED_MAP for existing 
code which uses either std::unordered_map or std::unordered_map. (Yes there 
is room for improvement there, but such improvement is orthogonal to your 
branch).

3) Similarly, CMake has to build with compilers which do not support 
cxx_range_for or cxx_auto_type. For the cmServer implementation that may or 
may not be the case, but within the cmake class, that's the way it is.

4) It seems that the 

 this->Generators

member of the cmake class has the names of all generators (without 'extra' 
generators). It seems unfortunate to not use that container and instead 
parse the names out of the names from the GetRegisteredGenerators call by 
splitting on the ' - '. It leads to hard coded magic expressions like 
'separator + 3', so it should be avoided if possible.

Is there another way of determining the extra generators supported by a 
given generator and avoiding parsing a string which we just generated? Can 

  const std::vector& supportedGlobalGenerators =
extraGenerator->GetSupportedGlobalGenerators();

be used somehow? Can you first loop over this->Generators to get the 
'normal' generators, then loop over the extra generators, call that method 
to match things up and output the result?

Or would it make sense to refactor the container members in the cmake class 
themselves to make this information more easily available for this use-case?

5) You use the term 'appendix' for the version, but 'suffix' is the more-
commonly used name for that concept.



Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 -E capabilities

[Stephen Kelly]

Tobias Hunger wrote:

> Either we should have multiConfig return a list of configuration names
> that will be generated or I do not see any need to have the information in
> the first place.

I think when using qmake with QtCreator, the user can choose the 
configuration at build time by selecting it from the left-side menu.

Such a feature would also work with cmake projects if the user chooses to 
use the XCode generator on mac or VS generator on Windows (or if someday we 
have a multi-config Ninja generator or so).

However, I don't think that is an immediate goal, and that information can 
be added later easily if a client does need it.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 -E capabilities

[Stephen Kelly]

Brad King wrote:

> On 07/01/2016 05:11 AM, Tobias Hunger wrote:
>>> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
>> I do not see why this information is need to set up a cmake project. I
>> need two directories and a generator. Do I need to know what the
>> generator produces at that point?
> 
> If we don't foresee a use case for it we don't need to add it now.  The
> example given in the issue was just a quick demo IIUC and not intended to
> be authoritative result of deep design thought.

I can confirm this.

>> If "-A" is the way to go, then I would like to try my hand at adding
>> a method to retrieve all valid platforms for a generator. CMake has
>> a lot of code to find those names (or hardcodes known names), so why
>> not pass it on to the user?
> 
> If it is reasonably straightforward to do then go for it.  That would
> be nice to offer.

Does Visual Studio have a drop-down menu or similar for this? If yes, then 
such a list would be good to have I think.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Tobias Hunger wrote:

> Hello CMake Developers,
> 
> Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch
> we both have been working on. It was a very productive meeting: We managed
> to resolve almost all the differences of opinion we had.

Thanks Tobias for the summary and everyone else for the discussion.

Here are a few additional notes that I took when meeting Tobias last week. 
These notes don't change anything in the discussion, but expands on a few 
things to put some meat on the bones and lists some discarded design 
options.

cmMessenger
---

> * Having cmMessanger would be nice and will make things easier.

In particular - a cmMessenger class can have some virtual methods 
implemented to print to the console as cmake::IssueMessage currently does. 

It would be inherited by a cmServerMessenger which would override the 
virtual methods to send them over the server IPC protocol instead of 
printing them on stdout. This has the advantage of not losing semantic 
information - a backtrace becomes a JSON array, meaning clients don't have 
to try to parse the backtrace out of the stdout message as they currently 
do. That becomes possible with just a IssueMessage virtual. See 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607

Additionally, the cmMessenger can have additional high-level virtual 
methods, such as for find_package results making it easier for user tools 
and IDEs to get a list of packages searched for and make it possible to give 
users use-case specific ways of specifying where packages are.

Similarly it can have a virtual method for try_compile results (somehow - 
this might require extending the message type for scripting API) which also 
give user tools more opportunities to present the user with semantic 
information and not discard the intent of the person writing the 
buildsystem.

Another place where a virtual method on cmMessenger would make sense is for 
policy warnings, giving user tools a chance to present them to the user 
without trying to parse them from stdout.

There may be other messages which have semantics whose meaning we currently 
discard by printing to stdout.

All of this is currently blocked by a clean-up in the parser needing further 
review and perhaps further implementation work:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=16663


Name


Last year before publication I was calling this feature a 'metadata server' 
(class called cmMetadataServer etc). I probably made a mistake renaming it 
to a daemon. Now, 'metadata server' might be better and more specific than 
'server' alone.

Change Notification
---

I wrote previously that I think change notification is an essential feature 
of the first version of the protocol - otherwise the output is no better 
than a static generated file. 

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16648

Tobias was concerned that implementing filesystem watching for all necessary 
platforms is an unreasonable burden and he would prefer something like 
QFileSystemWatcher.

libuv has a portable abstraction for filesystem change notification similar 
in a way to QFileSystemWatcher. I implemented a basic use of the libuv API 
fs notification API last year.

Action item for me is to dig out that work or do it again. Then the metadata 
server can emit a message on the protocol when the source directory content 
changes.

Feature Flags
-

> 1.2 Protocol versions
> 
> * We need the daemon-mode to support different protocol versions.
> 
> * We want to have the option to mark protocol versions as experimental.

As far as I know, Chrome has a development model whereby unfinished features 
are checked into master immediately and developed there, instead of being 
developed in a branch. The new/experimental features are disabled by default 
with 'feature flags' so that people/CI can enable and test features which 
are candidates to be enabled by default to everyone.

We discussed whether this would make sense for the server instead of 
'experimental' protocol versions. We decided that such feature flags would 
make sense if there would be many experimental features in flight from 
multiple contributors over multiple cmake releases. We don't expect this to 
be the case, so we consider feature flags to be over-engineered for the 
server for now.

InReplyTo
-

> * Currently a reply (and error and all other messages in response to a
> request) contain a "inReplyTo" with the type string from the request
> triggering the reply.
> 
> Stephen thinks that is not necessary and argues anything that is not
> strictly necessary should not be in the first version of the protocol.

Tobias told me that the only reason for this is to make it easier for people 
developing the actual protocol to paste blocks of text which contain 

Re: [cmake-developers] CMake 32 and 64 bit packages on Windows

[Stephen Kelly]

Brad King wrote:

> I logged out and logged back in and
> then everything gets the proper PATH.
> 
> Then I un-installed again and had to logout/login again to get the
> PATH updated for programs launched through shortcuts.

Hmm, I didn't do any logging out or in. Maybe that was the cause.

Thanks,

Steve.



-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] How to set startup project in Visual Studio

[Stephen Kelly]

J Decker wrote:

> The setting is in a different file that's .vcproj.user (or .user.vcproj)

And there is not one of these for each project() command?

It seems to me that this should either be a GLOBAL property, or the 
documentation which directory to set the DIRECTORY property on. I have no 
idea what the answer is.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 32 and 64 bit packages on Windows

[Stephen Kelly]

Brad King wrote:

> MSI
> takes care of reversing effects of the removed installation, so that
> may have removed it from your PATH.

Hmm, the steps I took were:

* Uninstall my pre-existing CMake 3.1 installation
* Install the CMake 3.5 32 bit package
** At this point everything worked on the command line. Maybe MSI added the 
correct directory to the PATH.
* Install the CMake 3.6 RC 64 bit package
** This may have caused MSI to remove the CMake 3.5 installation and to 
reverse the PATH manipulation for CMake 3.5.
** The install location for CMake 3.6 RC 64 bit was not added to my PATH?
* Install the CMake 3.6 RC 32 bit package
** This added the correct directory to my PATH, so I could use it in the 
command line environment.

Even if I look at it this way, there still seems to be a bug somewhere.

If no one can reproduce this, then I may have somehow made a mistake in the 
installation.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] How to set startup project in Visual Studio

[Stephen Kelly]

Hi, 

the outcome of 

 https://cmake.org/Bug/view.php?id=15578

seems to be 

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78ec0461 

a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project in 
Visual Studio. I tried it in the 3.6 RC and it works fine if I set the 
property in the top-level directory, so thanks for that.

However, the documentation does not say which directory to set it in, or why 
it is a DIRECTORY property. 

Why is this not a GLOBAL property?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMake 32 and 64 bit packages on Windows

[Stephen Kelly]

Hi,

I tried the CMake 3.6 RC on Windows yesterday. I initially downloaded the 64 
bit version, and the installer uninstalled my CMake 3.5 (32 bit).

Then, in my 'Visual Studio 14 2015 64 bit command prompt', the cmake 
executable was no longer found. I think the difference is that the 64 bit 
cmake is installed to 'Program Files (x64)', whereas the 32 bit version is 
installed to 'Program Files'. I installed the 3.6 RC 32 bit and that worked 
fine with my command prompt.

It is possible that I somehow made a mistake or messed up my visual studio 
command prompt environment (I don't recall doing that), but it didn't seem 
to be looking in the 64 bit location for cmake. It might be something for 
someone more familiar with Windows to look into.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode: Project structure

[Stephen Kelly]

Tobias Hunger wrote:
>> * Designing a protocol like this is hard (and not fast)
> 
> We have been discussing this for about two years now.

That's a misleading thing to say.

Time since an effort or discussion started has never been a guideline for 
when something is ready for CMake master.

> I see no problem there: You can always cut out old protocols if their
> implementation hurts too much. That sucks for users that need the old
> version, but it can be cleanly detected.

I think you underestimate the cost of supporting old versions and the 
benefit of exploring the design space to get it as right as possible the 
first time (exploring the design space isn't the same as giving IDE 
developers votes).

I suggest switching gears and designing the initial protocol handshake and 
version negotiation, and come back to this buildsystem description part of 
the protocol later.

Designing the how versioning the protocol works can include design and 
discussion of end of support for particular protocol versions (how many 
years/releases it will be deprecated for before being removed etc). That is 
the first part that would get merged to master anyway.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

On 06/13/2016 04:22 PM, Brad King wrote:
> On 06/11/2016 08:14 AM, Stephen Kelly wrote:
>> Thanks for your thorough review! I think I've fixed the errors I
>> introduced while rebasing now.
>>
>> I'm not completely certain that the gymnastics I do with the
>> cmListFileBacktrace in the parser in the early commits in the branch are
>> correct or appropriate.
> The role of `.Pop()` on `lfbt = this->Backtrace.Pop()` is not clear.
> I was not able to produce a RunCMake.Syntax test failure by removing it.
>
> The clean-up-Parser topic currently strips the backtrace lines and some
> other context from some expected test output even though the lines still
> appear, such as in
>
>   Tests/RunCMake/Syntax/UnterminatedBracket0-stderr.txt
>
> and I think a few others.  Please restore the context lines where possible.
>
> Overall I like the cleanup though.

You're right, but I think digging into that again would take more time
than I want to put into it now. I really just wanted to not have to
rebase that branch again in the future :).

I've merged other clean ups and pushed the rest of the
extract-cmMessenger branch to my repo again.

Thanks,

Steve.

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

On 06/10/2016 10:07 PM, Daniel Pfeifer wrote:
> On Fri, Jun 10, 2016 at 8:17 PM, Stephen Kelly <steve...@gmail.com> wrote:
>> However, that's not a problem when messages are delivered through the
>> daemon, so I suggest that
>>
>>  https://github.com/steveire/cmake/tree/extract-cmMessenger
>>
>> and the daemon itself are good places to direct your attention to improve
>> this situation.
> I have reviewed the branch and wrote some inline comments on github.
> Overall, I confirm this is the right approach. So, "approval" from my side.

Thanks for your thorough review! I think I've fixed the errors I
introduced while rebasing now.

I'm not completely certain that the gymnastics I do with the
cmListFileBacktrace in the parser in the early commits in the branch are
correct or appropriate.

Thanks,

Steve.

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode: Project structure

[Stephen Kelly]

Tobias Hunger wrote:

> Hello everybody,
> 
> I made some progress with extracting project structure from cmake via the
> daemon-mode. I am rather happy with the information and would love to get
> some feedback from other interested parties.
> 
> Here is the format that is currently reported (with comments;-):
> 
> [== CMake MetaMagic ==[
> {
> # Reply header:
> "cookie":"",
> "type":"reply"
> "inReplyTo":"project",

Part of the design of the daemon is that messages that it sends can be 
'spontaneous' - it watches for filesystem changes and can tell clients to 
re-read the buildsystem information.

The inReplyTo does not fit that model. Additionally, it appears to be 
redundant if you have a 'cookie'?

> 
> # Data:
> "projects":

What you call 'projects' appear to be 'targets' in CMake vocabulary. Is that 
correct? Note that a project is something different in CMake vocabulary (see 
the project command). 

Note also that in CMake, targets (libraries, executables etc) have a project 
name.  Conceptualizing this as 'a project is a group of targets' doesn't 
work well because of how CMake deals with multiple project() commands and 
the VS and Xcode structures it generates. See 

 cmGlobalGenerator::FillProjectMap() 

and how the result of that method is used. It is important that the daemon 
does not create a new claim of truth in this regard - the structure from the 
daemon should be the same as the structure generated for those ide projects. 

You may need to understand that before you can create something final here.

Of course, my branch 

 https://github.com/steveire/CMake/commits/cmake-daemon-lite

is already 'correct' in this regard.

I think you need to understand my branch more. You're doing some different 
things, but you haven't compared and explained the differences I think. 
There should be comparison and convergence in the end.

> Is this the information you need for IDE integration?

You might be packing too much into one protocol verb. Try this on LLVM and 
VTK for example to see how much data it is. Perhaps then compare with the 
gradual approach in my branch.

In my branch I have 

* `buildsystem` - Get the targets (name, type, project) and backtraces
* `target_info` - Get buildsystem properties for a target
* `file_info` - Get buildsystem properties for a file in a target

Getting the backtraces (instead of the location) for targets is important - 
the location relevant to the user might be a macro invocation, not the 
inside of a macro. See:

 https://www.youtube.com/watch?v=BPgXuvPAl-8=870

In general I think you are missing a lot by not understanding my branch. My 
branch is created with the mindset of 'expose what is correct in CMake'. You 
are creating what you think QtCreator needs - that's good, but what is 
needed is convergence between the two. 

If you rebase your work on top of mine, then you can explain why you do 
that, and we can find out if you are exposing 'correct' information (I'm 
thinking again of the project stuff). For your convenience, I have pushed 
your work to my clone (after rebasing):

 https://github.com/steveire/CMake/commits/daemon-hunger

I suggest you continue your work from there. That way we can discuss your 
changes and converge on something correct.

Notice that some of your changes make some diffs needlessly big and 
therefore harder to understand. For example you rename member variables from 
mLoop to m_Loop, and you rename the cmMetadataServer class to cmServer. Both 
only make it harder to understand your patches. I recommend fixing up your 
patches to remove those differences. 

That way we can converge on the dual goals of exposing correct information, 
and exposing what QtCreator needs. 

You are currently diverging from my work without explaining the differences, 
leading to incorrectness in some cases, and you are missing out on the work 
that I have already done.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] cmCacheManager related changes

[Stephen Kelly]

Brad King wrote:

>  cmState: Expose list of properties of values in the cache
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63c0e92c

The way these classes are designed, cmState is intended to be the way to 
access state which generally does not change during a CMake configure run in 
a way which would be observable to and relevant to the daemon.

Things which do change in such a way should be accessed through 
cmState::Snapshot, or classes which depend on cmState::Snapshot such as 
cmState::Directory for directory properties, or some day cmState::Target for 
target properties. That way those properties can be versioned.

It is true that some existing things in cmState should not be there 
(commands, cache properties etc). You can consider whether now is the time 
to move the cache property access to cmState::Snapshot (even without 
versioning internally) instead of adding more methods related to cache 
properties to cmState directly.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Tobias Hunger wrote:
> Forcing messages into one consistent format will be a pain, agreed, but
> continuing to add messages in whatever form the developer likes at the
> time of writing the code is even worse. CMake has a lot of different error
> message styles!

This is something my branch addresses in part, which is why I drew attention 
to it in the context of the daemon.

> If you were to unify on e.g.
> 
> CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO):
> MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES
> 
> then you will probably hit existing code paths in IDEs.

I don't think that's possible for all messages (not all messages have file 
or line information).

However, that's not a problem when messages are delivered through the 
daemon, so I suggest that 

 https://github.com/steveire/cmake/tree/extract-cmMessenger

and the daemon itself are good places to direct your attention to improve 
this situation.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

On 06/09/2016 09:49 AM, Daniel Pfeifer wrote:
> On Thu, Jan 28, 2016 at 10:42 PM, Stephen Kelly <steve...@gmail.com> wrote:
>> Hi,
>>
>> I have pushed a extract-cmMessenger branch to my clone:
>>
>>  https://github.com/steveire/CMake/commits/extract-cmMessenger
> I have rebased it to master and cherry-picked some minor changes.
> Once those minor changes land in master, I will rebase again and then
> have a closer look at the individual commits.

Cool. I did some work rebasing it yesterday too. It changed a bit due to
the recent cmListFileBacktrace changes, and in the end the cmMessenger
class is much simpler.

>> * Make it possible to make add first-class handling of messages about
>> missing packages (for example) to cmake-gui by making methods on
>> cmMessenger virtual and subclassing
> That sounds useful. But long term, I would rather base ccmake and
> cmake-gui on top of the daemon.

Sounds interesting.

> What I would like to have, is separate subclasses for gcc-style and
> msvc-style messages. In gcc-style, messages look like this:
>
> :row:column: error: 
>
> In msvc-style, messages look like this:
>
> (row,column): error: 
>
> This would make it easier to jump to the location in IDEs (and
> powerful editors).

Hmm, some existing clients (KDevelop) parse messages in the form they
are already in. They would break if all message formats were changed
substantially. Having the above behavior be dependent on some command
line option or environment variable wouldn't be great either.

The impact of this would need to be assessed.

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

Great, thanks for that!

Steve.

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon-mode

[Stephen Kelly]

On 06/07/2016 11:42 AM, Daniel Pfeifer wrote:
> On Mon, Jun 6, 2016 at 7:24 PM, Brad King  wrote:
>> On 06/06/2016 11:39 AM, Tobias Hunger wrote:
>>
>>> A big chunk of Stephen's work has not even landed in my branch yet. Since 
>>> cmake
>>> reformated all the source in the meantime it is a bit tedious to apply 
>>> patches
>>> from his tree and I have simply not yet needed the changes as I did not 
>>> venture
>>> where he went yet.
>> See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
>> how to rebase across the style transition.  If you rebase the original
>> "cmake-daemon" branch on that then we can rewrite the style to make
>> cherry-picking later easier.
> When I rebased my own branches across the style transiton, I found the
> process quite straight forward.
> I can help with the style transition if someone rebases to 82df6deaaf.
>
> When I tried to rebase steve's work, it was not the style transition
> but changes like the following that I struggled with:
> https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355

I have rebased it and force pushed my github branch (there are a few
rebasing mistakes which I'll remove later).

We hit issues at work that different clang-format versions have
different behavior. There we have the luxury of providing particular
binaries that every developer uses to get identical results and no diff
confusion.

I don't know how to solve that in CMake though. It could become an issue
in the future when some contributors use clang-3.9 and others 3.8. Maybe
clang-format binaries should be in the repo.

Also, it seems that clang-format is not run by CI. The ProductBuild
stuff doesn't seem to be clang formatted.

Thanks,

Steve.

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Stephen Kelly]

On 06/06/2016 11:14 PM, Daniel Pfeifer wrote:
> Here is what I found.
>
> * SetLinkScriptShell is called from two places:
> cmMakefileExecutableTargetGenerator::WriteExecutableRule and
> cmMakefileLibraryTargetGenerator::WriteLibraryRules.
> * We can instantiate a cmOutputConverter in those places and then pass
> it along the call tree in all branches that contain calls to Convert.

I don't think that's the right approach. It just worsens spaghetti code
and an antipattern in CMake which is already too widespread.

Stepping back a bit to look at the more general problem in CMake:

It is fairly common in CMake code to have methods used throughout the
codebase which take parameters and then use the parameters in if()
conditions to change the behavior of the method in significant ways.

This is an anti-pattern and a code smell. It couples all code which
calls the method and makes it harder to refactor, as you now see with
Convert(). It violates:

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

I fixed some of the instances of it in my
15-years-worth-of-cmake-clean-up-in-9-months last year.

Unfortunately because it is so common in CMake, this pattern still grows
in the codebase. See eg cmake::GetSuppressDeprecatedWarnings and related
methods which take a cmMakefile which defaults to null. Those methods
exist since v3.5.0-rc1~165^2 (Explicitly enable deprecated warnings by
default., 2015-11-29).

Notice how there is only ONE caller where the cmMakefile is not-null!

So it makes sense to take the condition out of the inside of the method
and put it in the call site. It simplifies everything:

 
https://github.com/steveire/CMake/commit/86d13501f3253c5489b8f6abf21b6a983481a77c

I didn't manage to get enough interest in that commit or the rest of the
branch to get it merged:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607

but I would like your review of the branch if you have time.

Anyway, back to Convert()...

The reason I listed this refactoring of removal of cmOutputConverter as
a base of cmLocalGenerator in the OP of this thread is to create
separation of compute-time code from generate-time code. So let's keep
that in mind as a goal.

Generate time should be just for generating. If we have that strict
design, it benefits the daemon because that needs to configure and
compute, and it benefits a multi-toolchain feature architecture because
that needs to configure for multiple toolchains, compute across the
result and then generate once (I'm talking about an idea evolved from
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 in
case you never followed that).

Notice that Convert() is called at configure time, compute time and
generate time currently.

In the very end:

1) It should only be called at configure and compute time
2) CMake should create some state at compute time using APIs similar to
Convert()
3) Configure-time and compute-time Convert() behavior and APIs will not
necessarily be the same because the needs are different - you will see
that if you analyze the users of the Convert method and the OutputFormat
enum.

So, look into the Convert() methods. There are two overloads. Both do
some computation, then call ConvertToOutputFormat().

What does ConvertToOutputFormat() do? It does nothing at all if the
OutputFormat is UNCHANGED.

What is the default value of OutputFormat? It is UNCHANGED!

I guess you can see where this is going:

1) The parts of Convert() which come before the ConvertToOutputFormat()
calls should be extracted into two new overloads, maybe called
RawConvert(). The name is not great, but in the end the existing
Convert() methods can probably be deleted and the Raw* ones renamed.
2) Convert() should call RawConvert() and pass the result to
ConvertToOutputFormat().
3) Callers of Convert() should be ported to RawConvert(). A quick way to
do most of this is to find all callers of Convert() which pass only two
arguments and change those to RawConvert(). Note that there are other
callers which explicitly pass UNCHANGED!
4) Analyze remaining callers of Convert() and inspect the OutputFormat
they pass. For example see the output of 'git grep -w RESPONSE'. That
enum value can probably be removed and the EscapeForShell inlined into
the callers.
5) Do the same analysis for the other enum values. SHELL is used a lot.
In the end some new method might make sense for the SHELL case instead
of that enum.
6) Look at the result and see if there is an obvious way to go from
here, including for the LinkScriptShell case. The case where that
condition is used might be the last remaining case when the above is
done, and a different design can be considered.
7) The OutputFormat enum and the LinkScriptShell can probably be removed
in the end, with their callers ported to more-purposeful methods.

The whole point of this is to reach the essence of what all this
Convert() stuff in CMake is really about. It's currently very confused
and fixing that 

Re: [cmake-developers] Developer tasks - Refactoring

[Stephen Kelly]

On 05/19/2016 11:27 PM, Daniel Pfeifer wrote:
> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly <steve...@gmail.com> wrote:
>> 1) Make cmLocalGenerator not inherit cmOutputConverter
>> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>>
>>https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298
>>
>>   for a similar sed command to achieve this.
>>
>> * Remove inheritance. Implement Convert() methods in cmLocalGenerator for
>>   source compatibility which instantiate and use a cmOutputConverter as in
>>
>>https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad
> That may change behavior because the LinkScriptShell member may have
> the wrong value.
> I am currently digging deeper.

Yes, that looks like it requires deeper digging.

In commit v3.3.0-rc1~29^2~1 (cmState: Host some state from the
cmGlobalGenerator., 2015-05-24) I moved other things which are used by
Convert() APIs to cmState, but the LinkScriptShell didn't seem to belong
there.

I was hoping the callers which need LinkScriptShell would manage that
state themselves somehow, but it would take some deep digging and
probably refactoring of the makefile generator to do that.

Did your digging turn anything up?

Thanks,

Steve.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Stephen Kelly]

On 05/20/2016 12:06 AM, Daniel Pfeifer wrote:
> On Thu, May 19, 2016 at 11:18 PM Daniel Pfeifer
> <dan...@pfeifer-mail.de <mailto:dan...@pfeifer-mail.de>> wrote:
>
> On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly <steve...@gmail.com
> <mailto:steve...@gmail.com>> wrote:
>
> 1) Make cmLocalGenerator not inherit cmOutputConverter
> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>
>
> Please see attached patch.
>
>
> Revised patch attached. Please ignore the previous one.
> This one also fully qualifies the enums that were used unqualified.

Thanks for working on this! Looks good to me too.

Steve.

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

On 03/25/2016 09:25 AM, Tobias Hunger wrote:
> I am personally rather unsure about how to proceed. I can help make
> this branch production/merge ready, but I do not want to maintain it
> indefinitely after it is merged. It touches to many CMake internals
> for me to be comfortable hacking on that code. 

Yes, this lack of interest in general in maintaining it upstream is
currently a demotivator. I think we need a group of people interested in
doing that.

Brad/Ben, no response since I posted the blog or the code. Any word of
interest in any of it?

Thanks,

Steve.

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Listing all targets

[Stephen Kelly]

Clifford Yapp wrote:

> On Mon, Sep 14, 2015 at 1:47 PM, Stephen Kelly
> <steve...@gmail.com> wrote:
>> Making the target names available through properties via cmState is also
>> trivial after targets become first-class parts of cmState
>> (cmState::Target like cmState::Directory).
>>
>> That can happen sooner (it's on my plate), but required refactoring is
>> also on hold until after CMake 3.4.
> 
> 
> Does anyone recall where the "list all targets" feature ended up?  Is
> it still on hold?  (I apologize if I missed any subsequent discussion
> - just now getting back to this...)

It's not being worked on. I didn't get that far in my refactoring.

If you want to work on it, you can create the cmState::Target and store 
target names in cmState instead of cmTarget (making cmTarget take a 
cmState::Target in order to implement cmTarget::GetName() of course).

Then implementing a global property to get the list of target names is easy.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] CMakeFindDependencyMacro limitations

[Stephen Kelly]

Roger Leigh wrote:

> On 24/02/2016 22:49, Roger Leigh wrote:
>> I've attached a patch for a very simple modification to find_dependency.
>>   I'm not proposing that it be merged, it's just a suggestion for
>> further discussion.  I've tested it with my own packages with multiple
>> find_dependency(Boost COMPONENTS ...) calls.  Some rationale and
>> thoughts follow:
> 
> Did anyone have any time to take a look at this?  Are there any
> objections or further questions arising from the approach taken here?
> Could it be submitted for inclusion if not?

I still see the find_dependency limitation as a useful one, given how much 
confusion removing it would cause.

 find_package(foo)
 find_package(bar)

 if (Qt5_FOUND) # TRUE!
 endif()

6 months later...

 find_package(foo)
 find_package(bar)
 find_package(bing)

 if (Qt5_FOUND) # FALSE!
 endif()


My recommendation is: figure out the underlying truth about find_package 
COMPONENTS and multiple find_package calls. 

This isn't a matter of opinion - it is inherent to how find_package and the 
cmake cache, and cmake scoping work. 

As far as I know, no one has thought it through thoroughly.

You might find this interesting:

 http://public.kitware.com/Bug/view.php?id=15971

As I wrote there,

> Also, a user might expect
> multiple find_package in the same scope (as with transitive package
> dependencies) to be 'reliable'. As far as I know it is not.

It doesn't matter if things like that have been done for years if they have 
never been reliable and if there has never been a possible way to do it 
correctly. 

The statement is not at all about find_dependency, but is about whether it 
was ever possible (or is possible now) for someone to put correct lines into 
their Config.cmake package (or possibly into a Find module) which would make 
multiple find_package of the same package with different COMPONENTS 
reliable. 

My suspicion is it was never possible (independent of existence or not of 
any macro). That's what I'm suggesting you to investigate and discover. This 
is something to discover (based on inherent truths about the cmake cache, 
scoping, find_package features etc. I'm repeating myself), not something to 
'decide'.

You might find that COMPONENTS is incompatible/confusing/unreliable with 
other parts of CMake, or you might find that it actually makes sense. I'm 
just suggesting a full investigation completely independent of the 
find_dependency macro.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

Alexander Neundorf wrote:

> On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote:
>> Jean-Michaël Celerier wrote:
>> > There is also https://www.cevelop.com/ which is an Eclipse derivative,
>> > they may be interested ?
>> 
>> I went all hipster reach-out.io and tweeted at them. :)
> 
> looks like that's an FP7-project, so I wouldn't be too sure about its
> future once the project funding ends...

If anyone can get me a working java environment and a way to asynchronously 
write stdin/stdout on long-running processes, I can write a plugin for 
eclipse which would be independent of cevelop afaict.

Do you know enough java to help get started on that?

Thanks,

Steve


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

Jean-Michaël Celerier wrote:

> There is also https://www.cevelop.com/ which is an Eclipse derivative,
> they may be interested ?

I went all hipster reach-out.io and tweeted at them. :)

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

Alexander Neundorf wrote:

> On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote:
>> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
>> > Hi Dominik,
>> > 
>> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"
>> > <dhaum...@kde.org
>> > 
>> > <mailto:dhaum...@kde.org>>:
>> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
>> > 
>> > I'd be in, but I do not have the time to organize one. I could
>> > probably get a room in our office though (in Berlin).
>> 
>> I'd be up for a sprint in Berlin too, but given the muted response so
>> far here, it's not clear who would want to join and what we could
>> achieve.
> 
> just out of curiosity, did you get any feedback from anybody from
> Eclipse/CDT ?

Nope. No response from there at all despite reaching out to them.

> Or CodeBlocks maybe ?

I didn't reach out to them, so no.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake Daemon blog

[Stephen Kelly]

Taylor Braun-Jones wrote:

> On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly
> <steve...@gmail.com> wrote:
>> I've just pushed the daemon code here:
>>
>>  https://github.com/steveire/cmake/tree/cmake-daemon
>>
>> The Kate plugin should soon appear here I think:
>>
>>  https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git
> 
> Thanks for sharing, Stephen! Do you plan to also share the standalone
> Qt-based editor/client as well (cmake-browser)? That would be
> immediately useful to me and allow me to more easily test drive all
> this work that you've done.

I've deliberately not pushed that yet because it would put the wrong focus 
on the conversation:

* It doesn't need a test drive because I know it is limited by the daemon
* The focus needs to be on the implementation of the daemon first to make 
that work better. That can be done by anyone determined enough to paste some 
things into the stdin. 

For more see

 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15741

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

On 02/15/2016 07:24 PM, Tobias Hunger wrote:
>
> Hi Dominik,
>
> Am 15.02.2016 19:01 schrieb "Dominik Haumann"  >:
> > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
>
> I'd be in, but I do not have the time to organize one. I could
> probably get a room in our office though (in Berlin).
>

I'd be up for a sprint in Berlin too, but given the muted response so
far here, it's not clear who would want to join and what we could achieve.

Thanks,

Steve.

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] FindCUDA.cmake regression in 3.5.0-rc2

[Sorley, Stephen L.]

I tested your fix, it's working well for my project.  Thanks for the quick 
response!

-Stephen S.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, February 17, 2016 3:28 PM
To: Sorley, Stephen L.
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote:
> FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution 
> files for Visual Studio on Windows (VS 2013 update 4, to be specific).  
> The ninja generator on Windows is unaffected.

Thanks for trying the release candidate and tracking this down!

In the long run I agree that switching away from $(VCInstallDir) is best, but 
it is mentioned in several other places within the module and is documented as 
a valid user-provided value.  For now I'd like to fix the regression with 
minimal changes.

Please test this fix on top of 3.5.0-rc2:

 FindCUDA: Fix regression under Visual Studio generators
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda0

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

[Sorley, Stephen L.]

FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution files 
for Visual Studio on Windows (VS 2013 update 4, to be specific).  The ninja 
generator on Windows is unaffected.

When I attempt to build a cuda target, the compile step for each .cu file fails 
with the following message:

Building NVCC (Device) object 
utils/CMakeFiles/utils_cu.dir/Release/utils_cu_generated_cudaarray.cu.obj
3>  cudaarray.cu
3>
3>  '$' is not recognized as an internal or external command,
3>
3>  operable program or batch file.
3>
3>  CMake Error at utils_cu_generated_cudaarray.cu.obj.cmake:207 (message):
3>Error generating
3>
C:/Users/sorlesl1/Desktop/testproj/build/utils/CMakeFiles/utils_cu.dir//Release/utils_cu_generated_cudaarray.cu.obj

I've traced the problem to this 
commit<https://github.com/Kitware/CMake/commit/6ccc307053f03c4c48a2cb9d5795f91d341a5c39>,
 which added VERBATIM to the add_custom_command() call in CUDA_WRAP_SRCS.

Adding the VERBATIM flag changes how the escaped double-quotes in the 
ccbin_flags variable are interpreted:

Without verbatim, ${ccbin_flags} expands to the following in the generated VS 
project:
   -D "CCBIN:PATH=$(VCInstallDir)bin"

With verbatim, the double quotes are escaped in the generated project, causing 
the error:
   -D \"CCBIN:PATH=$(VCInstallDir)bin\"

If the escaped quotes are omitted entirely when ccbin_flags is set, the custom 
command still fails, this time due to VCInstallDir expanding at compile time to 
a path containing spaces.

According to bug 15001<https://cmake.org/Bug/view.php?id=15001>, there isn't 
any way in CMake to correctly quote Visual Studio placeholder variables that 
expand to values containing spaces - you'll always get either no quotes, or 
escaped quotes.  However, I was able to work around this problem by getting the 
compiler path directly from CMake instead of using the placeholder.  Please see 
the attached patch (it's based on master) - with this patch, compiling CUDA 
code with Visual Studio works again.

Thanks,
Stephen Sorley


0001-Fixed-Visual-Studio-CUDA-compile-failure.patch
Description: 0001-Fixed-Visual-Studio-CUDA-compile-failure.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake Daemon

[Stephen Kelly]

Tobias Hunger wrote:

> Hi Stephen,
> 
> stupid question: How do I run the server-mode autotests?
> 
> I just implemented a unified way to do progress reporting and want to
> make sure that did not break too much. Running
> Tests/Server/daemon-test.py manually works, but how do I run all those
> tests configured in the CMakeLists.txt? The builddirectory does not
> contain a Tests/Server directory to run make test in:-/

After building cmake, run 

 ctest -R Server 

in the build directory

Alternatively, cd to 

 Tests/Server 

in the source directory and 

 mkdir build
 cd build
 cmake ..

The tests are run at cmake time.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Developer tasks - Daemon mode

[Stephen Kelly]

The Daemon mode for CMake is online here:

 https://github.com/steveire/CMake/tree/cmake-daemon

The commit messages and some of the commits contain indications of things 
that need to be done before such a mode could be introduced into CMake, such 
as writing a new failsafe parser and implementing some of the features in 
the branch so that they work well in all cases.

I won't repeat those tasks in a list here, but they prevent the Daemon from 
becoming upstreamable.

There are other tasks which prevent the Daemon being upstreamable to cmake 
proper. These are not tasks for raw-beginners:

1) Using libuv filesystem notification to re-generate the cmState when 
  buildsystem files change (and notifying the client through the protocol
  about resulting changes in the generated buildsystem).  This is by far the 
  most essential.

2) Prune state which is created while operating. The parts of the protocol 
  which execute some cmake code (eg, debugging and code completion) create 
  cmState::Snapshots without cleaning them up afterward (or possibly using 
  an LRU cache if such a thing would make sense).


I can provide guidance to anyone wishing to complete them, or any of the 
tasks described in the cmake-daemon branch.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake Daemon

[Stephen Kelly]

Stephen Kelly wrote:

> Tamás Kenéz wrote:
> 
>> That's great and really does open a new world for IDEs!
> 
> Thanks! Let's see if the interest grows.
> 
> I've just pushed the daemon code here:
> 
>  https://github.com/steveire/cmake/tree/cmake-daemon

Tobias made a pull request there. Rather than review it there, I will review 
it here for visibility.

 https://github.com/steveire/CMake/pull/2

The branch is quite it hard to review, or even to see the particular 
changes, due to large commits and diff noise. If the Daemon reaches a level 
of completeness that it could be upstreamed (See 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740

) then these commits (including all of my commits on the branch) would have 
to be rewritten, split, made reviewable etc making heavy use of `rebase -i`. 

In a way, we don't have to do that now, but I'm also not very enthusiastic 
about making the `cmake-daemon` branch commits unreadable. I would add your 
commits to the branch if they we split and in the appropriate place (eg, 
with the cmServerProtocol0_1 change early in the cmake-daemon branch).

The changes in your branch are good and useful to more than just QtCreator.

Things that I like in your branch:

* Explicit cmServerRequest and cmServerResponse APIs, which enforce the type 
and cookie consistency. 
* Returning cmServerResponse objects from the cmServerProtocol instead of 
invoking the server from the cmServerProtocol. 
* A way to version the protocol in a future-proof way with C++ classes.
* Implementation of daemon and protocol error messaging infrastructure. 
(Reporting errors from cmake code requires other refactoring: 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636)

So I think that is progress!

Thanks,

Steve.



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake Daemon blog

[Stephen Kelly]

Stephen Kelly wrote:

> Hi,
> 
> I just made a blog and video about the advanced features and possibilities
> that a daemon mode for CMake can bring:
> 
>  https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/
> 


The lack of response on the list to any of this is quite disappointing.

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Developer tasks - Refactoring

[Stephen Kelly]

In order to make it possible to implement fully featured user tools like the 
cmake daemon

 https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/

... and to make it possible to use multiple toolchains at once

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272

... and turn CMake into a fully capable modern cross-compiling buildsystem

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10873

... the implementation of CMake needs to improve. At least if any of those 
advanced features are to be maintainable.

A large amount of the steps to get there involve refactoring the existing 
CMake code to be more flexible. I have been doing that since April last 
year, but I want to open up the task list to other collaborators and 
newcomers in particular.

Here are some entry-level refactoring tasks which have a useful impact on 
CMake, and which lead to more familiarity with the code for whoever does 
them. Feel free to ask for further guidance on any task.

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

   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298

  for a similar sed command to achieve this.

* Remove inheritance. Implement Convert() methods in cmLocalGenerator for 
  source compatibility which instantiate and use a cmOutputConverter as in

   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad

2) Reduce generate-time use of cmMakefile definitions
* The intention is to remove direct use of cmMakefile from generate-time 
  code.
* Use an IDE to find uses of cmGeneratorTarget::Makefile and 
  cmGeneratorTarget::Target
* Replace use of 'low-level' GetDefinition from cmMakefile with more 
  'high-level' methods on cmGeneratorTarget.  Eg

   this->Target->Target->GetMakefile()->GetDefinition("CMAKE_STRIP")

  in cmComputeLinkInformation could be replaced with a new

   std::string cmGeneratorTarget::GetCMakeStripTool() const;

  or similar.

3) Compute cmGeneratorTarget state non-lazily in its constructor.
* Historically target state for generators was computed lazily because it 
  might need to be cleared and re-computed.  That is no-longer true.
* For example, the LinkInformation is populated lazily in
  cmGeneratorTarget::GetLinkInformation.
* Instead the LinkInformation could be populated in the cmGeneratorTarget 
  constructor for all known configurations.  That is what generators will 
  request during generate-time anyway.
* Doing this will make it possible to split a cmComputedTarget out of 
  cmGeneratorTarget.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 3.5 generation time

[Stephen Kelly]

Bartosz Kosiorek wrote:

> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f

The relevant part of that patch (from the point of view of separating 
configure time code from generate time code) is the removal of the use of 
TotalTargets at generate time.

Mappings could be re-introduced in cmGlobalGenerator, maybe with names 
indicating that their purpose is faster searching, and separated between 
cmTargets and cmGeneratorTargets:

 TargetMap TargetSearchIndex;
 TargetMap ImportedTargetSearchIndex;
 GeneratorTargetMap GeneratorTargetSearchIndex;

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Michael Scott wrote:

>> Yes. Did you have a close look at the commits? I'm not really sure they
>> are correct, and I wonder if you have any thoughts on the first one which
>> discusses interface?
> I went back and had a closer look at the major changes. I think on the
> whole the cmMessenger class is good and a clear improvement over the
> previous organisation, however I imagine in its current form it would be
> perhaps a bit tricky extending it for other environments (e.g.
> displaying messages as GUI modal notifications), which I understood to
> be one of the overall aims of the branch (correct me if I've
> misunderstood of course though).

The aim of the branch is only to extract the class. That allows the further 
work on it.

When it is extracted, it can be refactored with a virtual interface as you 
describe, and as is described in the 'cmMessenger: Extract from cmake class' 
commit.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Namespaces

[Stephen Kelly]

Pau Garcia i Quiles wrote:

> But that does not work unless I juggle with add_library(... IMPORTED) or I
> use Hunter or alike.

I did something like that a few months ago:

 https://github.com/Ableton/aqt-cassowary/blob/master/src/CMakeLists.txt

However, that's not a pattern which scales I think. It requires the host to 
know too much about the hosted, and could stop working in the future (cmake 
should maybe emit an error if the LOCATION specified in an IMPORTED target 
does not exist).

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Michael Scott wrote:

>> * Make it possible to make add first-class handling of messages about
>> missing packages (for example) to cmake-gui by making methods on
>> cmMessenger virtual and subclassing
>
> This sounds like a good idea and makes a lot of sense.
> 
> While working on the message functionality previously it felt like it
> was tacked on as an afterthought, I think moving in this direction will
> help lead to message functionality that can be expanded and improved
> upon much more easily in the future.

Yes. Did you have a close look at the commits? I'm not really sure they are 
correct, and I wonder if you have any thoughts on the first one which 
discusses interface?

> This may be a stupid question, but I previously wondered why CMake
> doesn't use (or at least obviously use) a standard logging library,
> similar to log4j, for some of this stuff?

I don't know the answer to this.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Namespaces

[Stephen Kelly]

Pau Garcia i Quiles wrote:

> CMake should wrap every variable defined under the directory added with
> add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

So, CMake needs to first determine what variables are used in the QtZeroConf 
directory (presumably without executing the cmake code there) and then wrap 
the variables, then execute the cmake code? 

I must be missing something. I don't think that's possible.

> 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...)
> 
> and
> 
> server/CMakeLists.txt contains find_package(QtZeroConf)

I think you need:

 ExternalProject_Add(3rdparty/Whatever ...)
 ExternalProject_Add(3rdparty/QtZeroConf ...)
 ExternalProject_Add(server ...)

and pass appropriate args to the latter, including where to look for 
dependencies etc (and dependencies among the ExternalProjects).

You might not like this solution, but as far as I know it is the only 
correct solution built into CMake.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Namespaces

[Stephen Kelly]

Pau Garcia i Quiles wrote:

> On Thu, Jan 28, 2016 at 8:21 PM, Stephen Kelly
> <steve...@gmail.com> wrote:
> 
> 
> Pau Garcia i Quiles wrote:
>>
>> > CMake should wrap every variable defined under the directory added with
>> > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)
>>
>> So, CMake needs to first determine what variables are used in the
>> QtZeroConf
>> directory (presumably without executing the cmake code there) and then
>> wrap the variables, then execute the cmake code?
>>
> I must be missing something. I don't think that's possible.
>>
>>
> I think it's just a matter of adding an "internal note" saying "OK, I'm
> going to namespace variables from now on" in cmAddSubdirectoryCommand when
> add_subdirectory contains NAMESPACE, and then modifying the literal of the
> variable in cmSetCommand.cxx (first argument to AddDefinition here in line
> 165):
> 
> this->Makefile->AddDefinition(variable, value.c_str());
> 
> https://github.com/Kitware/CMake/blob/master/Source/cmSetCommand.cxx#L165

I'm happy to provide guidance if you start writing a patch and find that it 
is a realistic approach, but I still don't think this is possible.

What do you do when third party code contains

 set(SOMETHING foo bar)
 foreach(thing ${SOMETHING})
 ...
 endforeach()

?

Are you going to change every read of a variable to prefix it with a 
namespace?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Hi,

I have pushed a extract-cmMessenger branch to my clone:

 https://github.com/steveire/CMake/commits/extract-cmMessenger

The motivations are:

* Decrease responsibilities of the cmake class. CMake uses too few
classes for too many things
* Make it possible to make add first-class handling of messages about
missing packages (for example) to cmake-gui by making methods on
cmMessenger virtual and subclassing
* Make it possible to emit messages through the daemon (also by
subclassing) together with backtrace and message type, relieving clients
from having to parse the text.

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

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Namespaces

[Stephen Kelly]

Pau Garcia i Quiles wrote:

> add_subdirectory(pugixml/scripts)
> add_subdirectory(QtZeroConf)
> add_subdirectory(QtDropBox)
> add_subdirectory(websocketpp)
> 
> This is an easy way to work with third-party dependences.

Unfortunately this is 'easy, obvious and wrong'.

> My problem comes from the fact several of these third-party libraries use
> common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc).

And indeed this is why.

> Has some kind of namespacing been considered for add_subdirectory?
> 
> E. g.
> 
> add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

And what if someone builds your project with -DBUILD_SHARED=ON? Are you 
going to use 

 set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED})
 add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

for every variable you're wrapping? Or do you want cmake to do that for 
every variable in scope when the directory is added? How would cmake decide 
which variables to namespace?

You should use ExternalProject instead, or fork the buildsystem of those 
projects to integrate them into your project. Not that I recommend the 
latter for you though :). That's what cmake does when integrating 3rd party 
code.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Anyone going to FOSDEM?

[Stephen Kelly]

Benjamin Eikel wrote:

> Hi Gregor,
> 
> Am Mittwoch, 30. Dezember 2015, 14:33:08 schrieb Gregor Jasny via cmake-
> developers:
>> Hello,
>> 
>> I wonder if any of you CMake Developers go to FOSDEM [1] this year?
> 
> I am not a CMake developer, but, more or less, an advanced user, but I
> will go to FOSDEM next year. ;-)
> At least Stephen Kelly [2] will be there, too.

Yep. Maybe we could arrange to meet in the Sunday evening. I leave on the 
Monday.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMake Daemon blog

[Stephen Kelly]

Hi,

I just made a blog and video about the advanced features and possibilities 
that a daemon mode for CMake can bring:

 https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/

I'll make the code available by the end of the week. I still want to clean 
it up a little bit first :).

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] EXPORT dependency handling

[Stephen Kelly]

Roger Leigh wrote:
>add_library(OME::BioFormats INTERFACE IMPORTED)
>set_target_properties(OME::BioFormats PROPERTIES
> INTERFACE_LINK_LIBRARIES ome-bioformats)
> 
> It's the last two lines.  Internally, the target name is ome-bioformats,
> but I actually want it to be OME::BioFormats as the name of the imported
> interface.  I don't have any need for "ome-bioformats" to be exported at
> all, but EXPORT only allows a real target.  Unless I missed a
> workaround; I tried exporting ALIAS names and interface names, but
> without success.

You might have missed 

 https://cmake.org/cmake/help/v3.4/prop_tgt/EXPORT_NAME.html

Thanks,

Steve


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Milian Wolff wrote:

>> I'm concerned that the memory usage of a daemon implementing the proposed
>> capabilities may be too large to be practical (at least without a major
>> redesign of certain structures that tend to duplicate substrings, or
>> some kind of out-of-core approach).
> 
> This sounds like optimizations to that daemon will benefit CMake.

FYI I merged a reduce-allocations branch to next for testing. It came from 
Milian here:
 
 https://github.com/steveire/CMake/pull/1

Milian also mentioned the possibility of using something like a sqlite 
database (probably what you meant by out-of-core above) for definitions for 
querying by the daemon. 

I also mentioned some possibile optimization possibilities, such as removing 
the closure of definitions created for all directories. I wrote a branch 
which does that some months ago, but it resulted in a slow down. I'll see if 
I can rebase the commit to master and push it to github, together with a 
patch for avoiding computing the hash multiple times in cmDefinitions. 

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] FindPNG: Create an imported PNG::PNG target

[Stephen Kelly]

rle...@codelibre.net wrote:

>>> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}")
>>
>> Shouldn't this refer to zlib instead of png libraries again?
> 
> I would have expected something like
> 
> set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES
> ZLIB::ZLIB)

For reference, this is documented here:

 
https://cmake.org/cmake/help/v3.4/manual/cmake-packages.7.html#creating-relocatable-packages

but as IMPORTED targets are getting added to find modules now, perhaps the 
manual cmake-developer(7) could also get a note about this:

 
https://cmake.org/cmake/help/v3.4/manual/cmake-developer.7.html#a-sample-find-module

or that section could be extended to generally discuss dependencies.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 command line options for deprecation message control

[Stephen Kelly]

Michael Scott wrote:

> If there are any problems with the proposed changes let me know.

Hi Michael,

Thanks for working on this topic over such a long time period to get it 
right.

I closed 

 http://public.kitware.com/Bug/view.php?id=15677

and 

 http://public.kitware.com/Bug/view.php?id=14669

on your behalf because I couldn't assign the bugs to you in mantis.

Thanks,

Steve.



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake daemon mode protocol

[Stephen Kelly]

Stephen Kelly wrote:
> I recommend focussing on the tasks in my OP:
> 
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/11794

To be more clear:

The goal I have is to enable debugging, introspection of the buildsystem and 
the state during execution, code completion etc.

Your goal seems to be completely orthogonal to that and requires an entirely 
different set of steps to achieve (perhaps the first being 'demonstrate 
viability'). I don't think I can help with your goal.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake daemon mode protocol

[Stephen Kelly]

Tobias Hunger wrote:

>> For this case, I suggest that if the user tries to 'open the source
>> directory', you would use QTemporaryDir to build in a temporary location
> and
>> run the daemon there. I believe clion does something equivalent to that.
>> Is that viable? I suppose you are suggesting that cmake do that instead
>> of leaving it for clients to do?
> 
> It is doable. I just do not see why this should be necessary.

I'm aiming to first design as much as possible of a 'minimal viable 
protocol' as a first step. Given the above I think your ideas of running the 
daemon with no build dir are not 'minimal' and I'm convinced they're not 
viable. 

Someone would have to prototype the ideas, but I don't think that's a good 
use of time or energy right now (mostly because I think they're not viable).

I recommend focussing on the tasks in my OP:

 http://thread.gmane.org/gmane.comp.lib.qt.creator/11794

>> Richer information about some semantics like 'task' and 'busy state'
>> could also be provided in a similar way I expect, assuming those could be
> defined.
> 
> This is some basic functionality that we should get right soon, as this
> can influence how long-running tasks need to be designed.

Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in 
mind. Particularly if you can relate them to what is already in my github 
branch.

> So "cmake --build" is out of scope for the daemon?

I listed three ways cmake and an IDE could interface here:

 http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411

'triggering the build' would be a fourth. I don't think it needs to be part 
of the initial discussion of the design. 

Let's try to keep scope small so that we can get on common ground.

> That is why I brought up progress information so early: They make things
> complicated by there suddenly being several responses to a request and you
> need a way to identify those. At that point simpler solutions tend to blow
> up:-)

Yes.

BTW: I don't expect to get any part of the design of the protocol 'right' on 
the first iteration. I think we need to start everything that will need to 
be in the protocol, then iterate. Start high level ignoring details, and 
fill in the details as we iterate and can encode needs in unit tests.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

Brad King wrote:
> I think the responses in this thread have indicated there is interest
> in working toward the full daemon approach.  Perhaps discussion should
> now proceed on the daemon protocol design over in the thread Tobias
> started on cmake-developers:
> 
>  cmake daemon mode protocol
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15424

Yes, let's assume that anyone interested in this topic is now subscribed to 
the cmake mailing list use that thread which does not include the other 
mailing lists. 

Thanks,

Steve.



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake daemon mode protocol

[Stephen Kelly]

Tobias Hunger wrote:

> Hi Stephen,
> 
> I have successfully build and run your cmake server mode changes and
> the python client script does work as advertised.

Thanks for doing that!

> I do have a couple of remarks about it. This is more intended as a
> starting point for discussion as a real proposal. Would something
> along these lines be possible:


> * Start daemon-mode without any additional parameters
> 
> * Daemon responds with "
>   {
> "type": "handShake",
> "version": "3.5.x",
> "supportedProtocols": "3.5"
>   }

As you discovered, the cmake binary might not even support the daemon mode 
at all.

I think what you are really asking for is 'the capabilities of the cmake 
binary'. In that sense, you might also want to know what generators are 
available, whether daemon mode is available (and with which protocol 
versions) etc.

The issue at

 http://public.kitware.com/Bug/view.php?id=15462

proposes to dump that information to stdout with a different -E command.

> 
> * Client Handshake:
>   {
> "type": "handshake",
> "requestProtocolVersion": "3.5"
>   }
> 
> * Daemon:
>   {
> "type:"handshake",
> "protocolVersion": "3.5"
>   }

Something like this is possible too. It's not far off what is already done 
in the branch.

> 
> At this point the normal operation should be possible.
> 
> * Client:
>   {
>  "type": "setProjectInformation",
>  "sourceDirectory": "/some/path",
>  "cookie": "1"
>   }
> 
>   Being able to set the source directory is important so that a fresh
> checkout can be configured. There is no build directory available at
> that time...

I understand the desire to inspect a cmake project without asking the user 
to specify a build dir, but cmake has to write build files somewhere in 
order to test the compiler etc. 

For this case, I suggest that if the user tries to 'open the source 
directory', you would use QTemporaryDir to build in a temporary location and 
run the daemon there. I believe clion does something equivalent to that. 

Is that viable? I suppose you are suggesting that cmake do that instead of 
leaving it for clients to do?

> * Daemon should do progress handling while reading the CMakeLists.txt
> or whatever it does:
>   { "type": "progress", "state": "busy", "task": "someId",
> "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" }
> 
> * Daemon sends occasional:
>   { "type": "progress", "task": "someId", progressTotal: 25,
> progressCurrent: 12, "cookie": "1" }

Yes. CMake can provide approximate values of how complete the configure step 
is. See cmGlobalGenerator::AddMakefile. That could be exposed to the daemon 
'somehow', such as by defining some virtual callback interface. 

Richer information about some semantics like 'task' and 'busy state' could 
also be provided in a similar way I expect, assuming those could be defined.

> * Finally Daemon responds sends data as that is available now.
>   {
> "type": "projectInformation",
> "sourceDirectory": "/some/path",
> "buildDirectory": "",
> "projectName": "SomeProject",
> "cookie": "1"
>   }

At this point in your proposal, cmake has run the configure step in a 
temporary directory, right? So it would be 

  "buildDirectory": "/tmp/foo/bar"

right?

> * Client:
>   {
> "type": "setProjectInformation",
> "buildDirectory": "/some/other/path",
> "cookie": "2"
>   }

As this sets a new build directory, cmake will have to run the configure 
step from scratch in this new location.

> * Daemon does progress indication as above...
> 
> * Daemon responds with project info:
>   {
> "type": "progressInformation",
> "sourceDirectory": "/some/path",
> "buildDirectory": "/some/other/path",
> "projectName": "SomeProject",
> "cookie": "2"
>   }

I must admit I'm not seduced by this idea as it seems to be that it should 
be easy for an IDE to build in a temporary dir itself. 

However, I think it makes sense to design the protocol to handle specifying 
either a sourceDir or a buildDir (or both if from scratch). Starting daemon 
mode without arguments as you suggest could work (though 

Re: [cmake-developers] CMake alternative language

[Stephen Kelly]

Charles Huet wrote:

> When the configure step takes
> about 30 seconds, and all you can do is use MESSAGE() to find what
> happens, this is no walk in the park. A real debugger would do a world of
> good to CMake.

This is one of the things that I address with the daemon work - a 
'recording' is made during the configure step which can then be inspected.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Stephen Kelly]

Tobias Hunger wrote:

> So could we please get a *documented* way that an IDE can *rely on to
> be available* that provides basic information on a
> project/configuration:
> 
> * Source directory, build directory
> * Files that belong to the project (sources, headers, custom cmake
> modules, CMakeLists.txts, resources, ...)
> * Files that belong to the build system (anything that needs watching
> to re-generate the IDE-integration information at the right times)
> * Targets that can be built
> * Files that belong to each target
> * Compiler flags
> * Defines in effect
> * Include paths used
> * The compilers used to build those files

Yes, that's the kind of thing my branch on github provides. That's why I 
worked on those things first.

Did you look at my github branch already by the way?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

Brad King wrote:
>> Alexander goes back to the generator approach we discussed a year ago
>> and explicitly says he won't work on that, so nothing will happen
>> there.
> 
> The generate-json-description approach remains a valid alternative.
> Aleix's work on it got pretty far before Stephen proposed the daemon
> alternative.  

In between I also made a generic-generated-JSON-file-based approach.

> These problems are orthogonal, and your requirements certainly need
> generation-time information regardless of how the build specification
> itself is represented.  

Yes, this is the stuff that the protocol I put on github provides.

> Therefore the discussion here should proceed
> independent of where the alternative language thread goes.

Yes. I count 3 orthogonal ways an IDE and cmake could 'interface':

1) Provide information about translation of sources into objects so that the 
   IDE can understand those sources - eg includes and defines for c++ 
   sources.

2) Provide semantic information about the CMake code, for example to 
   introspect what is defined at what point in the file for debugging 
   purposes, and for code completion purposes.

3) Provide a way for IDEs to *edit* the buildsystem. For example, if an IDE 
   has an 'add class' dialog, or a 'extract class' refactoring action, they 
   need to add a file to a target. 


The first two are what we have mostly discussed in previous threads that I 
linked in the OP.

A generated JSON file in the buildsystem can provide (1), but can not 
provide the other interfaces. 

A well-designed declarative spec could make it easy for an IDE to do (3) but 
can not provide the other interfaces.

A daemon can provide the first two in a high quality way and allows for more 
extensions in the future. As (3) is orthogonal, a daemon and a declarative 
spec for the sources covers all three. 

Even without the declarative spec, the daemon can tell the IDE exactly where 
to put the target_sources() command as an intermediate step (before the 
declarative spec is available), though that's 'ugly' so I didn't list it as 
something 'high quality' that the daemon could provide.
 
> 2.  CMake offers a daemon that IDEs can contact (e.g. via named pipes)
> to ask for the information.  The contract between CMake and IDEs is
> a (to-be-designed) protocol (e.g. JSON snippets).  Updating would
> likely be handled internally by the daemon in response to changes
> to the CMake input files between requests from the IDE.

Right. If only some/deep/nested/CMakeLists.txt changes, and cmake knows that 
definitions do not escape via PARENT_SCOPE, and cmake knows that the targets 
defined in that file are not additionally modified elsewhere, it only has to 
re-evaluate the cmake code for that file and not for the entire buildsystem.

> Stephen no longer has time to continue his work except to guide others.

I can do development, but it would have to be as part of a collaborative 
effort and collaborative future maintenance. The latter part is the main 
reason I want to encourage fresh developers (and particularly IDE 
developers) into the cmake code to work on this, and to have some ownership 
on the code and design.

> Given the above summaries my reaction is that the daemon approach is
> more elegant and desirable in the long run.  However, it will require
> much more time and resources to implement.  It is not clear how much
> more, or if anyone has such time and resources to offer.

Yes. I'm trying to generate interest in people who are capable of joining 
the effort, and interested in doing so. It is difficult :).
 
> An intermediate solution could be to offer the daemon and protocol
> to IDEs but to implement it internally on top of pre-generated JSON
> files.  

That's even more effort, no?

> The schema of the JSON files would remain a private contract
> between "cmake" and "cmake-daemon".  Then over time the implementation
> of the daemon could be improved by computing things internally on
> demand instead of updating and reading the JSON files, but the public-
> facing protocol would not change.  We just need to make sure that the
> protocol is designed to allow such flexibility.  OTOH this approach
> requires designing both the daemon protocol and the JSON format.

Yes. I don't understand the proposal. Why implement the protocol in terms of 
files generated by cmake, instead of implementing the protocol in terms of 
state in cmake (one less step)? 

> Note that the generated JSON approach is essentially what we've been
> doing with the VS IDE since CMake started, just with a different format.

Yes, but also without providing an interface for (2) and (3) above.

> Many developers use the VS IDE to develop their CMake-built projects,
> and they get IntelliSense for completion.  It has worked well for years.
> Perhap

[cmake-developers] CMake daemon for user tools

[Stephen Kelly]

Hello,

I've been working on adding a daemon mode for cmake to provide
information to user tools - such as IDEs - about the buildsystem.

Following the discussion about providing metadata for IDEs to consume
I proposed creating a long-running process which would provide a protocol
to access information about the buildsystem, and about the content of the
cmake files themselves:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004

The original post in that thread lists design goals.

This design is independent of any generator, and compared to the solution of
writing json to a file, this solution doesn't require generating
anything that is
not asked for.  This also side-steps the problem of 'stale' files remaining
in the build directory, and the problem of needing to trigger re-generation
of the file, or watching it for changes.  This solution also allows
parameters (eg the config) to be specified in requests, side-stepping a
difficulty we encountered before to represent things like that.  This
solution also does not require actually generating the buildsystem
files. Only the configure and compute steps of cmake are executed.

I am scheduled to give a talk at FOSDEM about the feature and how user
tools can interact with it:

 https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code

with a preview in Berlin:

 http://www.meetup.com/berlincplusplus/events/227896427/

I have now also pushed a branch to my github clone with the start of the
server mode:

 https://github.com/steveire/CMake/commits/cmake-daemon

Currently the branch only makes targets and backtraces etc available via
the protocol.  I have also created a plan for extending the protocol to
make code completion and variable debugging possible, and analysed the
depedencies of the tasks:

 http://www.steveire.com/cmake-daemon-tasks.png

However, I can't complete those tasks myself: I don't have
relevant experience building IDEs to know how best to design the
protocol, what IDE tools really need, how to design a fail-safe parser
etc.  Additionally, I think a design which incorporates design ideas
and implementation from more than one person will be better in the end.

So, this needs to be a collaborative effort if it is to go anywhere, with
more people writing commits in the cmake repo.

The above (copied below) task list would be enough to get a read-only
browser of a cmake project quite quickly.

Following that, an effort would be needed to handle the difference
between the dirty state of an editor and the on-disk file content. That's
a solvable problem and together with filesystem notifications provided
by libuv, it will lead to features like code completion.

Also necessary eventually would be to make the cmake parser more
fail-safe, so that information is still available if the user
had not yet closed a command argument list for example, and make the
processing more fail-safe in the case where they have written
add_subdirectory(foo), but have not yet created foo/CMakeLists.txt.

I would be looking to people who work on IDEs for guidance on how to do
things like that, as some of them are likely already for handling C++
code in the IDEs.

So, this needs to be a collaborative effort. I can provide guidance to
anyone who wishes to participate in changing the source code of CMake
to make it possible.

Is anyone interested enough in this potential cmake feature to
join the development effort?

Thanks,

Steve.


* Provide basic daemon mode with event loop and communication protocol
-- Written, but not reviewed
* Provide protocol to query the buildsystem structure
-- Written, but not complete or reviewed
* Extend cmListFileParser to record location of start and end of commands
* Rewrite cmIfCommand to record which branches are executed
* Store the location of start and end of user-defined functions
* Provide protocol to query for unexecuted lines
* Define a new snapshot type to occur at an arbitrary point
* Create snapshots after branching to other files (after an include() or
find_package() or add_subdirectory etc)
* Create snapshots after points with external effects (file(WRITE),
configure_file(), execute_process etc)
* Find most recent snapshot occuring before a specified line
* Implement feature to start at a specific snapshot and execute commands
up to a particular line
* Make server find correct snapshot to start at and execute required
commands up to specified line
* Provide protocol to dump variable defintions at a particular line
* Extract implementation of IssueMessage from cmMakefile and
cmLocalGenerator into cmake
* Extract computed target properties from cmTarget::GetProperty into
cmComputedTargetProperties
* Implement cmGeneratorTarget::GetProperties in terms of
cmComputedTargetProperties
* Move implementation of cmTarget::{Get,Set,Append}Property to cmState
* Extract all IssueMessage parts of cmake into a cmMessenger
* Extract the cmSystemTools::Message part of cmMessenger into a virtual

Re: [cmake-developers] Using CMake as a library from Python

[Stephen Kelly]

Charles Huet wrote:

> * cmCacheManager::AddCacheEntry was made public, as cmake::Configure
> cannot be used from python (it check for the existence of a CMakeLists.txt
> file, which does not exist in this scenario) and the cache variables it
> sets seem to be necessary.

Because of the above, I worry that you are basing your work on an old 
version of CMake. As of April 2015 cmState is used as the interface to the 
cache.

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13

Also note that the C++ interfaces in CMake are not stable. In the last year 
they have been changed utterly and that will continue to happen without 
notice. I'm sure you know this, but I thought I'd say it anyway.

> I will try to make a layer of abstraction on top of the python bindings
> before publishing this work on github, in order to show the syntactic
> sugar python can provide, but I will publish this before if anybody is
> interested in working on this.

I would be interested in seeing it.

> Now, does anyone beside me think this is a good idea ?

I did something similar some years ago with QML instead of python, so it 
sounds interesting to me. 

In fact, one of the reasons for introducing cmState and doing all the 
refactoring I did in cmake was to make it possible to cleanly replace the 
language, some day. 

My guess is that you are using python to instantiate a cmAddLibraryCommand 
and then executing it. I think a better approach would be to leave all the 
cm*Command classes behind as they carry a lot of backward compatibility 
baggage and policies which a new language shouldn't be burdened with. 

Even much of cmMakefile shouldn't be used by a new language. Instead certain 
parts of cmMakefile should be extracted as other classes (cmVariableExpander 
which should have the ExpandVariablesInString and ConfigureString stuff, 
cmMessenger for the IssueMessage stuff, some other class for the 
CompileFeature stuff etc). Then cmMakefile would be just about executing and 
scoping the CMake language. A new language would not need that, but would 
use the refactored extracted classes.

So, you would implement new cmPython*Command or whatever which operate on 
those classes and cmState. cmState is designed to be a language-agnostic 
store of data, like a database of buildsystem state.

As I said though, this would require further refactoring of the cmake code. 
I can provide guidance on how to do that if you are interested in pursuing 
that route. It would take some months I think, but be very valuable for many 
reasons and long-term cmake features. Another example of the kind of 
refactoring I mean is putting target state in cmState and making it 
accessible through cmState::Target, similar to how cmState::Directory 
currently works.

Having said all that, Brad favors Lua I believe, and he favors a different 
approach (which no one is working on as far as I know) to adding a new 
language. So wait to hear from him to know whether it is something that 
would be upstreamable.

I would prefer an approach similar to what I described above, which is close 
to what you are doing, so as a proof of concept I would like to see your 
work. 

I would guide/support you in refactoring cmake as needed. The refactoring 
part would definitely be upstreamable. I would very much like to see a proof 
of concept alternative language even if that wasn't upstreamed. It would 
prove that another language is possible, and that's one of the steps to 
replacing the current cmake language I think.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] CMakeFindDependencyMacro limitations

[Stephen Kelly]

Roger Leigh wrote:

> On 21/12/2015 15:07, Stephen Kelly wrote:
>> Roger Leigh wrote:
>>> I can understand why REQUIRED and related
>>> arguments are omitted--that is why find_dependency exists--but I'd quite
>>> like to be able to specify COMPONENTS where needed e.g. with FindBoost,
>>> and this is not currently possible.
>>
>> I don't remember whether this was discussed when designing
>> find_dependency. Perhaps COMPONENTS could be added to the macro now.
>
> Currently, for my own needs, COMPONENTS is the single missing piece.  If
> it would be possible to add this, it would certainly be very useful.
> 
> I'd be happy to provide a patch for COMPONENTS if you like.

I think the reason that the macro does not support COMPONENTS is that I 
don't understand how COMPONENTS is supposed to work. For example:

 find_package(Qt5 COMPONENTS Widgets)
 # Is Qt5_FOUND set to true or false?
 find_package(Qt5 COMPONENTS Quick)
 # ... what about now?

What does _FOUND ever mean if the find_package is called multiple 
times with different components? Does it mean anything?

Should CMake disallow multiple use of find_package with the same package and 
with different components?

If user code has 

 find_package(Qt5 COMPONENTS Widgets)
 find_package(FooBar REQUIRED)

and FooBarConfig.cmake has

 find_dependency(Qt5 COMPONENTS Quick)

then the if(Qt5_FOUND) in the macro will mean it will not try to find the 
Quick component.

So, there may be a need to establish a convention such as 

 __FOUND

and check that for each component in the macro. 

You would also need to think through everything and find out whether that is 
really a full solution. I haven't thought more deeply about it than the 
above.

Note that the above example with Qt 5 can not currently happen in practice 
because the find_dependency macro does not support COMPONENTS, so config 
files must instead use 

 find_dependency(Qt5Quick)

if they want to use the macro currently. This is a good thing.

So, I would like to know if

* adding COMPONENTS support to the find_dependency macro is the right thing 
  to do
* or if the right thing to do is to move away from support for COMPONENTS 
  generally because of its messy semantics
* or if find_package should change to not support multiple calls for the 
  same package. 

I really don't know the answer - I think someone needs to do deep thinking 
about it.

I would prefer the macro not be changed before that deep thinking about 
COMPONENTS generally is done.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] CMakeFindDependencyMacro limitations

[Stephen Kelly]

Roger Leigh wrote:

> I've run into a few limitations in find_dependency.  I'm not sure if
> these are by design or could be fixed, so this is really a request for
> further explanation or design rationale.
> 
> The first issue is this:
> 
>if (NOT ${dep}_FOUND)
> 
> This seems to be making the assumption that the found variable matches
> the dependency name, but the case used varies between modules and the
> name is case sensitive, from my reading of cmake-language.  Is this
> correct?

It is intentional, yes. See

 http://public.kitware.com/Bug/view.php?id=15412

The config-packages generated by cmake are canonical, so modules should set 
the ExactCase_FOUND to be a 'correct module'.

> Even if so, should this optimisation be put here rather than
> in find_package itself? 

I don't know the answer to this.

> If case sensitivity/naming is an issue, could
> the _FOUND variable be passed in as an argument, leaving the existing
> behaviour as the default if unspecified?

I don't think that's a good idea.

> The reason for stripping EXACT isn't clear.  If my package has a strict
> requirement on another package, whether the caller has an exact
> requirement for the version of my package has no bearing on the
> requirements I have for my dependencies as far as I understand.  What's
> the reason for the existing behaviour?

I don't know what you are referring to with 'stripping EXACT'. Perhaps you 
are looking at CMake < 3.0. See commit v3.0.0-rc2~10^2 (find_dependency: 
Don't propagate EXACT argument., 2014-03-06).

> Support for find_package arguments is limited to the dependency name and
> optionally the version.  

... and optionally EXACT.

> I can understand why REQUIRED and related
> arguments are omitted--that is why find_dependency exists--but I'd quite
> like to be able to specify COMPONENTS where needed e.g. with FindBoost,
> and this is not currently possible.

I don't remember whether this was discussed when designing find_dependency. 
Perhaps COMPONENTS could be added to the macro now.

> I was wondering if we could perhaps make find_dependency handle and pass
> through /all/ find_package arguments, minus REQUIRED/QUIET, so that
> find_dependency can expose the additional functionality offered by
> find_package.  Some may not be useful, in which case they could be
> omitted, but some like COMPONENTS may be required for the find_package
> call to be useful.

It might be possible, but might not be a good idea. What else do you want to 
pass in?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] ARMCC toolchain support

[Stephen Kelly]

Brad King wrote:

> Our convention for the compiler id is to refer to the vendor or
> maintaining
> organization behind the compiler. 

Is that "MDK" ?

+  set(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_ARMCC "MDK-ARM")



-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] use-correct-rcc-command-option topic

[Stephen Kelly]

Brad King wrote:

> Steve,
> 
> In regard to:
> 
>  Revert "cmQtAutoGenerators: Fix rcc invocation for Qt 5.0 and 5.1
>  (#15644)" https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08147a9a
> 
> The proper fix is to detect whether rcc supports --list or -list and user
> the preferred one based on the version available, not to revert to the
> broken state.

I consider CMake 3.4 to be the broken state. The patch reverted in that 
topic removed the use of a documented command line option and added the use 
of an undocumented command line option.

I don't see any reason to add maintenance burden for long-obsolete Qt 
versions to new CMake versions. Maintenance burden in CMake is already far 
beyond reasonable :). Adding conditions which are not tested, and which must 
be maintained in future refactoring is the mistake.

> I will not merge the topic as-is.

That's up to you. I wanted to stick my pin in the map on this as the person 
who wrote the feature :).

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] ARMCC toolchain support

[Stephen Kelly]

Andersson, Joakim wrote:

> Hi.
> 
> Sorry, forgot to add the actual patch, here it is.
> Attached is a patch that adds support for the ARMCC toolchain.

I saw this:

+# add the target specific include directory:
+get_filename_component(_compilerDir "${CMAKE_ASM_COMPILER}" PATH)
+get_filename_component(_compilerDir "${_compilerDir}" PATH)
+include_directories("${_compilerDir}/inc" )

and I wondered if that include directory is something that can be determined 
by invoking the compiler, instead of hardcoding it?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] use-correct-rcc-command-option topic

[Stephen Kelly]

Brad King wrote:

> On 10/27/2015 02:55 PM, Stephen Kelly wrote:
>> I wanted to stick my pin in the map on this as the person
>> who wrote the feature :).
> 
> As the person that wrote this feature I expect you to maintain it, please.

My idea of maintaining the feature included not adding conditionals for 
versions of Qt replaced years ago by newer Qt minor releases.

Years ago people used the qt5_add_resources macro, and as far as I'm 
willing/able to put time into, a programmer writing new code in 2015 based 
on Qt 5.1 can do that too.

This seems to be where you want things to be different, but I'm not going to 
test Qt 5.1 or do new work for supporting it :).

I'm also not going to add new automoc support for Qt 3, even though that is 
equally as supported (by upstream and by cmake) as Qt 5.1 is.

I think we understand each other, but we don't agree with each other. So, 
maybe that's the right point to drop this discussion thread :).

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] CMakeForceCompiler

[Stephen Kelly]

Brad King wrote:

> On 10/19/2015 10:46 AM, Brad King wrote:
>>  CMakeForceCompiler: Deprecate this module and its macros
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6
> 
> After fixing a typo in the commit message:
> 
>  CMakeForceCompiler: Deprecate this module and its macros
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed77504d

You're using message(DEPRECATION) - no one will see the warning message you 
added. 

I think message(DEPRECATION) is broken by design and should not be used 
until it warns by default. I think we might have discussed that design 
choice at the time of adding it, but a brief search did not find it.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Generating buildsystem metadata from CMake

[Stephen Kelly]

Alexander Neundorf wrote:

> Maybe this is of interest: the Eclipse CDT developers are currently
> working on improved support for cmake:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
> http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html

Yes, I noticed that too a few days ago.

My work should make reading the CMakeLists.txt file not necessary, as they 
seem to intend to do.

I'll ping them when I have something to show.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] genex-generator-objects topic

[Stephen Kelly]

Brad King wrote:

> Steve,
> 
> Last night's RunCMake.include test failures bisect to:
> 
>  cmMakefile: Store container of cmExportBuildFileGenerators.
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5925f99c
> 
> A clang sanitizer build output is below.  Please take a look.

Looks like unique_ptrs would really help.

I've fixed it up I think.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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