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 lazily generate pcm files as needed)

Partly that is a result of the totally-granular approach you took to 
creating modules (one module per class). If you used the 

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? (ie: from within my project's cmake build files, without modifying
> a cmake release)

There is no way to hook into the system I described without patching CMake. 
Your custom command approach might be the way to do that if it is the 
priority.

Thanks,

Stephen.


-- 

Powered by www.kitware.com

Please keep 

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]

I think this discussion is more suited to the cmake-developers mailing
list. Moving there. Hopefully Brad or someone else can provide other
input from research already done.

On 05/07/2018 12:49 AM, David Blaikie wrote:
>
>> The basic commands required are:
>>
>>   clang++ -fmodules -xc++ -Xclang -emit-module -Xclang
>> -fmodules-codegen -fmodule-name=foo foo.modulemap -o foo.pcm
>>   clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp
>>   clang++ -c foo.pcm
>>   clang++ foo.o use.o -o a.out
>
> Ok. Fundamentally, I am suspicious of having to have a
> -fmodule-file=foo.pcm for every 'import foo' in each cpp file. I
> shouldn't have to manually add that each time I add a new import
> to my cpp file. Even if it can be automated (eg by CMake), I
> shouldn't have to have my buildsystem be regenerated each time I
> add an import to my cpp file either.
>
> That's something I mentioned in the google groups post I made
> which you linked to. How will that work when using Qt or any other
> library?
>
>
> - My understanding/feeling is that this would be similar to how a user
> has to change their link command when they pick up a new dependency.

Perhaps it would be interesting to get an idea of how often users need
to change their buildsystems because of a new link dependency, and how
often users add includes to existing c++ files.

I expect you'll find the latter to be a far bigger number.

I also expect that expecting users to edit their buildsystem, or allow
it to be regenerated every time they add/remove includes would lead to
less adoption of modules. I can see people trying them and then giving
up in frustration.

I think I read somewhere that the buildsystem in google already requires
included '.h' files to be listed explicitly in the buildsystem, so it's
no change in workflow there. For other teams, that would be a change
which could be a change in workflow and something rebelled against.

By the way, do you have any idea how much modules adoption would be
needed to constitute "success"? Is there a goal there?

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

> Now, admittedly, external dependencies are a little more complicated
> than internal (within a single project consisting of multiple
> libraries) - which is why I'd like to focus a bit on the simpler
> internal case first.

Fair enough.

>  
>
> Today, a beginner can find a random C++ book, type in a code
> example from chapter one and put `g++ -I/opt/book_examples
> prog1.cpp` into a terminal and get something compiling and
> running. With modules, they'll potentially have to pass a whole
> list of module files too.
>
>
> Yeah, there's some talk of supporting a mode that doesn't explicitly
> build/use modules in the filesystem, but only in memory for the
> purpose of preserving the isolation semantics of modules. This would
> be used in simple direct-compilation cases like this. Such a library
> might need a configuration file or similar the compiler can parse to
> discover the parameters (warning flags, define flags, whatever else)
> needed to build the BMI.

Perhaps. I'd be interested in how far into the book such a system would
take a beginner. Maybe that's fine, I don't know. Such a system might
not help with code in stack overflow questions/answers though, which
would probably be simpler sticking with includes (eg for Qt/boost).

Library authors will presumably have some say, or try to introduce some
'best practice' for users to follow. And such best practice will be
different for each library.
 
>  
>
> I raised some of these issues a few years ago regarding the clang
> implementation with files named exactly module.modulemap:
>
> 
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html
>
> 
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html
>
> Interestingly, GCC is taking a directory-centric approach in the
> driver (-fmodule-path=) as opposed to the 'add a file to your
> compile line for each import' that Clang and MSVC are taking:
>
>  http://gcc.gnu.org/wiki/cxx-modules
>
> Why is Clang not doing a directory-centric driver-interface? It
> seems to obviously 

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

[Stephen Kelly]

On 04/30/2018 11:30 PM, Stephen Kelly wrote:
> Interestingly, GCC is taking a directory-centric approach in the
> driver (-fmodule-path=) as opposed to the 'add a file to your
> compile line for each import' that Clang and MSVC are taking:
>
>  http://gcc.gnu.org/wiki/cxx-modules
>
> Why is Clang not doing a directory-centric driver-interface? It seems
> to obviously solve problems. 

I just discovered `-fprebuilt-module-path=`. I'm glad it exists (is it
'new'?), but why don't you just use the -I paths?

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

On 04/20/2018 01:39 AM, David Blaikie wrote:
> Hi there,
>
> I'm experimenting with creating examples (& potential changes to CMake
> itself, if needed/useful) of building clang modules (currently using
> the semi-backwards compatible "header modules", with the intent of
> also/moving towards supporting pre-standard C++ modules in development
> in Clang).

Great! Thanks for reaching out. Sorry it has taken me a while to
respond. Have you had other response off-list?

> The basic commands required are:
>
>   clang++ -fmodules -xc++ -Xclang -emit-module -Xclang
> -fmodules-codegen -fmodule-name=foo foo.modulemap -o foo.pcm
>   clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp
>   clang++ -c foo.pcm
>   clang++ foo.o use.o -o a.out

Ok. Fundamentally, I am suspicious of having to have a
-fmodule-file=foo.pcm for every 'import foo' in each cpp file. I
shouldn't have to manually add that each time I add a new import to my
cpp file. Even if it can be automated (eg by CMake), I shouldn't have to
have my buildsystem be regenerated each time I add an import to my cpp
file either.

That's something I mentioned in the google groups post I made which you
linked to. How will that work when using Qt or any other library?

Today, a beginner can find a random C++ book, type in a code example
from chapter one and put `g++ -I/opt/book_examples prog1.cpp` into a
terminal and get something compiling and running. With modules, they'll
potentially have to pass a whole list of module files too.

Lots of people manually maintain Makefile-based buildsystems today, and
most other companies I've been inside of have their own custom tool or
bunch of python scripts, or both. Manually changing such buildsystems to
add -fmodule-file or -fmodule-map-file each time an import is added is a
significant barrier.

Will my project have to compile the modules files for all of my
dependencies? Even more complication for my buildsystem. Do I have to
wait for my dependencies to modularize bottom-up before I can benefit
from modules? If my dependency does add 'module foo' to their header
files, or whatever the current syntax is, can I continue to #include
 or is that a source incompatible change?

I raised some of these issues a few years ago regarding the clang
implementation with files named exactly module.modulemap:

http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html

http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html

Interestingly, GCC is taking a directory-centric approach in the driver
(-fmodule-path=) as opposed to the 'add a file to your compile line
for each import' that Clang and MSVC are taking:

 http://gcc.gnu.org/wiki/cxx-modules

Why is Clang not doing a directory-centric driver-interface? It seems to
obviously solve problems. I wonder if modules can be a success without
coordination between major compiler and buildsystem developers. That's
why I made the git repo - to help work on something more concrete to see
how things scale.

Having just read all of my old posts again, I still worry things like
this will hinder modules 'too much' to be successful. The more (small)
barriers exist, the less chance of success. If modules aren't
successful, then they'll become a poisoned chalice and no one will be
able to work on fixing them. That's actually exactly what I expect to
happen, but I also still hope I'm just missing something :). I really
want to see a committee document from the people working on modules
which actually explores the problems and barriers to adoption and
concludes with 'none of those things matter'. I think it's fixable, but
I haven't seen anyone interested enough to fix the problems (or even to
find out what they are).

Anyway, you are not here for my rants.

> My current very simplistic prototype, to build a module file, its
> respective module object file, and include those in the library/link
> for anything that depends on this library:
>
>   add_custom_command(
>           COMMAND ${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -xc++ -c
> -Xclang -emit-module -fmodules -fmodule-name=Hello
> ${CMAKE_CURRENT_SOURCE_DIR}/module.modulemap -o
> ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm -Xclang -fmodules-codegen
>           DEPENDS module.modulemap hello.h

Why does this command depend on hello.h? If that is changed and
module.modulemap is not, what will happen?

>           OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm
>           COMMENT "Generating hello_module.pcm"
>   )
>   add_library (Hello hello.cxx
> ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)
>   target_include_directories(Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
>   target_compile_options(Hello PUBLIC -fmodules -Xclang
> -fmodule-file=${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)
>
> (this is based on the example in the CMake docs using Hello/Demo)

Good that you got something working.

> This also required one modification to CMake itself to classify a pcm
> 

[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] C++ standard version fallbacks.

[Stephen Kelly]

Craig Scott wrote:

> On Tue, Jun 6, 2017 at 7:50 AM, Stephen Kelly
> <steve...@gmail.com> wrote:
> 
>> Roger Leigh wrote:
>>
>> > Hi folks,
>> >
>> > I'm currently using this logic to use C++14 with a fallback to C++11
>> > when C++14 is unavailable:
>> >
>> >if(NOT CMAKE_CXX_STANDARD)
>> >  set(CMAKE_CXX_STANDARD 14)
>> >endif()
>> >if(NOT CMAKE_CXX_STANDARD_REQUIRED)
>> >  set(CMAKE_CXX_STANDARD_REQUIRED 11)
>> >endif()
>> >
>> > which seems to work OK.
>> >
>> > However, for some new stuff, I'd like to use C++17 when available, but
>> > fall back to C++14, C++11 or C++98.  Is it possible to do this?
>>
>> Probably set CMAKE_CXX_STANDARD
>>
>> without CMAKE_CXX_STANDARD_REQUIRED (That variable doesn't really make
>> sense
>> to me and I think it is overused when not needed).
>>
> 
> If you don't set CMAKE_CXX_STANDARD_REQUIRED, then there's no guarantee
> you get any particular minimum standard.

He wants to fall back all the way to C++98. Am I missing something?

> Roger's example (sorry Roger!)
> highlights part of the confusion about this latter variable (and the
> target property it ultimately controls). He appears to be setting it
> expecting it to specify a minimum version, but that's not how it works. It
> is expected to be a boolean which says whether CMAKE_CXX_STANDARD must be
> honoured or not, which most developers (myself included) tend to find
> unintuitive. 

Ok.

I remember I was opposed to introducing CMAKE_CXX_STANDARD_REQUIRED in the 
first place as I think it is redundant. I recommend populating compile 
features for whatever you absolutely need and let cmake populate the std 
flag. If your code can benefit from a more-recent std flag than the 
requirement, then set CMAKE_CXX_STANDARD to that.

> Roger's use would actually make it a bit better, if that was
> how it worked, but unfortunately there's currently no way to set a
> *minimum* standard version,

If you have a minimum, then you must be relying on some language features 
existing and you can list those.

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

Re: [CMake] C++ standard version fallbacks.

[Stephen Kelly]

Roger Leigh wrote:

> Hi folks,
> 
> I'm currently using this logic to use C++14 with a fallback to C++11
> when C++14 is unavailable:
> 
>if(NOT CMAKE_CXX_STANDARD)
>  set(CMAKE_CXX_STANDARD 14)
>endif()
>if(NOT CMAKE_CXX_STANDARD_REQUIRED)
>  set(CMAKE_CXX_STANDARD_REQUIRED 11)
>endif()
> 
> which seems to work OK.
> 
> However, for some new stuff, I'd like to use C++17 when available, but
> fall back to C++14, C++11 or C++98.  Is it possible to do this?

Probably set CMAKE_CXX_STANDARD 

without CMAKE_CXX_STANDARD_REQUIRED (That variable doesn't really make sense 
to me and I think it is overused when not needed).

> - I'd like it to work on older CMake versions where "17" isn't a valid
> version for the above; is there any way to introspect the supported
> standards?

Not currently. It could be added now (as a global property), but that won't 
help you for existing CMake versions.

> - And I'd like it to fall back intelligently, i.e. if 17 isn't available
> I want it to select the newest standard possible, rather than falling
> back all the way to 98

I think it already does 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

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] Absolute path printing of CMakeLists.txt files in title of CMake error messages.

[Stephen Kelly]

vbspam wrote:

> *What is the real driver behind?*
> 
> - I use KDevelop as my Linux IDE which has as you may know pretty nice
> CMake integration.

I believe KDevelop is getting support for the cmake server, so exposing 
messages through that would probably solve this aspect. Specifically, there 
is a cmMessenger class and messages go through that. If you add virtual 
method(s?) to it you can add an implementation specifically for the server 
which passes the messages over the protocol to the IDE.

> - Another driver is when I do parallel build on build server, the actual
> context of the CMake error line is hard to determine. Here is impossible
> to get the proper context (the only relevant context is the printed line
> itself).

I'm not familiar with 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

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] 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] OBJECT libraries and INTERFACE_SOURCES

[Stephen Kelly]

Giovanni Funchal wrote:

> Hi,
> 
> The help page [1] mentions that:
> 
>> Although object libraries may not be named directly in calls to the
>> target_link_libraries() command, they can be “linked” indirectly by
>> using an Interface Library whose INTERFACE_SOURCES target property
>> is set to name $.
> 
> However, I was unable to get this to work. Doing this:
> 
> add_library(lib-obj OBJECT test.cpp)
> add_library(lib INTERFACE)
> add_dependencies(lib lib-obj)
> set_target_properties(lib PROPERTIES INTERFACE_SOURCES
> $)
> 
> And then trying to specify lib in link_libraries of an executable yields
> an error message "Cannot find source file: ... Tried extensions:... ".
> 
> Am I doing something wrong?

This works for me:

cmake_minimum_required(VERSION 3.3)

project(testit CXX)

add_library(lib-obj OBJECT foo.cpp)
add_library(lib-iface INTERFACE)
set_target_properties(lib-iface PROPERTIES
  INTERFACE_SOURCES $
)
add_executable(main foo-user.cpp)
target_link_libraries(main lib-iface)


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

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-644-g50eb6cf

[Stephen Kelly]

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

The branch, next has been updated
   via  50eb6cf42322dafb0b9f53ac02f956e69a4be188 (commit)
   via  bd4f7bd88af4dd062f953b8f102e55aca098edc1 (commit)
  from  db659b69cddd639e4c44bdb4e4d53a06e424fc8b (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50eb6cf42322dafb0b9f53ac02f956e69a4be188
commit 50eb6cf42322dafb0b9f53ac02f956e69a4be188
Merge: db659b6 bd4f7bd
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Wed Oct 19 09:40:45 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Oct 19 09:40:45 2016 -0400

Merge topic 'split-cmState' into next

bd4f7bd8 Fix style


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4f7bd88af4dd062f953b8f102e55aca098edc1
commit bd4f7bd88af4dd062f953b8f102e55aca098edc1
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Wed Oct 19 15:39:12 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Wed Oct 19 15:40:17 2016 +0200

Fix style

diff --git a/Source/cmTargetPropertyComputer.cxx 
b/Source/cmTargetPropertyComputer.cxx
index 0839439..36d1940 100644
--- a/Source/cmTargetPropertyComputer.cxx
+++ b/Source/cmTargetPropertyComputer.cxx
@@ -83,8 +83,8 @@ bool cmTargetPropertyComputer::WhiteListedInterfaceProperty(
 }
 
 bool cmTargetPropertyComputer::PassesWhitelist(
-  cmStateEnums::TargetType tgtType, std::string const& prop, cmMessenger* 
messenger,
-  cmListFileBacktrace const& context)
+  cmStateEnums::TargetType tgtType, std::string const& prop,
+  cmMessenger* messenger, cmListFileBacktrace const& context)
 {
   if (tgtType == cmStateEnums::INTERFACE_LIBRARY &&
   !WhiteListedInterfaceProperty(prop)) {

---

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


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

Re: [CMake] Editing IMPORTED targets

[Stephen Kelly]

Ivan Shapovalov wrote:

> On 2016-10-03 at 14:43 +0200, Stephen Kelly wrote:
>> Ivan Shapovalov wrote:
>> 
>> > Hello!
>> > 
>> > Using find modules to detect dependencies has a nice feature: it is
>> > then possible to edit the resulting cache entries to link to
>> > different
>> > libraries (or add other libraries along the found ones, for
>> > whatever
>> > purposes), or change directories, or flags, or whatever.
>> > 
>> > Using find configs and IMPORTED targets, however, prevents doing
>> > this,
>> > because IMPORTED targets are not stored in CMake cache. This can be
>> > a
>> > significant disadvantage at times.
>> 
>> Can you be more specific?
>> 
>> Why can the user provide better information than the supplier of the
>> IMPORTED target?
>> 
>> Thanks,
>> 
>> Steve.
>> 
>> 
> 
> Well, sometimes you need to do certain "maintainer-specific" overrides:
> include custom headers before everything, link to custom libraries
> before everything and so on. Think LD_PRELOAD, but at link time.

What is a 'maintainer' in that sentence? A 'maintainer' can change the 
buildsystem CMake files. I suspect that's not an actor you mean. If you can 
be more specific maybe I will understand.

Would 'wrapping' be a good solution?

 add_library(foo_wrapper INTERFACE)
 target_include_directories(foo_wrapper INTERFACE
   ${custom_includes}
   $<TARGET_PROPERTY:Foo::foo,INTERFACE_INCLUDE_DIRECTORIES>
 )
 target_link_libraries(foo_wrapper INTERFACE
   ${custom_libraries}
   Foo::foo
 )


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-539-g0e69f51

[Stephen Kelly]

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

The branch, next has been updated
   via  0e69f517951fefc4f4917d3101259c8a7a7fbc66 (commit)
   via  75ace0a67d0b57eecaf1862e8a5dc68efa0a724b (commit)
  from  d1f0e3064827cbaa929e8d55ae69ec40fda43a45 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e69f517951fefc4f4917d3101259c8a7a7fbc66
commit 0e69f517951fefc4f4917d3101259c8a7a7fbc66
Merge: d1f0e30 75ace0a
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 16 07:54:59 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Oct 16 07:54:59 2016 -0400

Merge topic 'extract-computed-target-properties' into next

75ace0a6 fixup! cmTarget: Move sanity checks and computed property access 
to callers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75ace0a67d0b57eecaf1862e8a5dc68efa0a724b
commit 75ace0a67d0b57eecaf1862e8a5dc68efa0a724b
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 16 13:54:29 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 16 13:54:29 2016 +0200

fixup! cmTarget: Move sanity checks and computed property access to callers

diff --git a/Source/cmGetPropertyCommand.cxx b/Source/cmGetPropertyCommand.cxx
index 0a59933..39445dd 100644
--- a/Source/cmGetPropertyCommand.cxx
+++ b/Source/cmGetPropertyCommand.cxx
@@ -10,16 +10,6 @@
 #include "cmTest.h"
 #include "cmake.h"
 
-#ifdef __clang__
-extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
-  cmTarget const* tgt);
-extern template const char* cmTargetPropertyComputer::ComputeLocation(
-  cmTarget const* tgt, std::string const& config);
-extern template const char* cmTargetPropertyComputer::GetSources(
-  cmTarget const* tgt, cmMessenger* messenger,
-  cmListFileBacktrace const& context);
-#endif
-
 cmGetPropertyCommand::cmGetPropertyCommand()
 {
   this->InfoType = OutValue;
@@ -262,8 +252,8 @@ bool cmGetPropertyCommand::HandleTargetMode()
 cmMessenger* messenger = this->Makefile->GetMessenger();
 if (cmTargetPropertyComputer::PassesWhitelist(
   target->GetType(), this->PropertyName, messenger, bt)) {
-  prop_cstr = cmTargetPropertyComputer::GetProperty(
-target, this->PropertyName, messenger, bt);
+  prop_cstr =
+target->GetComputedProperty(this->PropertyName, messenger, bt);
   if (!prop_cstr) {
 prop_cstr = target->GetProperty(this->PropertyName);
   }
diff --git a/Source/cmGetTargetPropertyCommand.cxx 
b/Source/cmGetTargetPropertyCommand.cxx
index d009bc3..6a816d8 100644
--- a/Source/cmGetTargetPropertyCommand.cxx
+++ b/Source/cmGetTargetPropertyCommand.cxx
@@ -4,16 +4,6 @@
 
 #include "cmTargetPropertyComputer.h"
 
-#ifdef __clang__
-extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
-  cmTarget const* tgt);
-extern template const char* cmTargetPropertyComputer::ComputeLocation(
-  cmTarget const* tgt, std::string const& config);
-extern template const char* cmTargetPropertyComputer::GetSources(
-  cmTarget const* tgt, cmMessenger* messenger,
-  cmListFileBacktrace const& context);
-#endif
-
 // cmSetTargetPropertyCommand
 bool cmGetTargetPropertyCommand::InitialPass(
   std::vector const& args, cmExecutionStatus&)
@@ -39,8 +29,7 @@ bool cmGetTargetPropertyCommand::InitialPass(
   cmMessenger* messenger = this->Makefile->GetMessenger();
   if (cmTargetPropertyComputer::PassesWhitelist(tgt->GetType(), args[2],
 messenger, bt)) {
-prop_cstr =
-  cmTargetPropertyComputer::GetProperty(tgt, args[2], messenger, bt);
+prop_cstr = tgt->GetComputedProperty(args[2], messenger, bt);
 if (!prop_cstr) {
   prop_cstr = tgt->GetProperty(args[2]);
 }
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index b2b7cd6..3a22309 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -1129,6 +1129,13 @@ void cmTarget::CheckProperty(const std::string& prop,
   }
 }
 
+const char* cmTarget::GetComputedProperty(
+  const std::string& prop, cmMessenger* messenger,
+  cmListFileBacktrace const& context) const
+{
+  return cmTargetPropertyComputer::GetProperty(this, prop, messenger, context);
+}
+
 const char* cmTarget::GetProperty(const std::string& prop) const
 {
   static UNORDERED_SET specialProps;
diff --git a/Source/cmTarget.h b/Source/cmTarget.h
index d48e7e2..bd00b3d 100644
--- a/Source/cmTarget.h
+++ b/Source/cmTar

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-537-gd1f0e30

[Stephen Kelly]

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

The branch, next has been updated
   via  d1f0e3064827cbaa929e8d55ae69ec40fda43a45 (commit)
   via  d94460ce3ff089c7746d24378f899008a2e5385d (commit)
   via  4b9292a9458d25a9394190de5ac9d9d056768070 (commit)
   via  a89dc5374b8798e6dbe699b7a074ec7cd9be36e8 (commit)
  from  0fde927b36aa8972da15fefa3e0f01ee22c6bcef (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1f0e3064827cbaa929e8d55ae69ec40fda43a45
commit d1f0e3064827cbaa929e8d55ae69ec40fda43a45
Merge: 0fde927b d94460c
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 16 06:09:54 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Oct 16 06:09:54 2016 -0400

Merge topic 'extract-computed-target-properties' into next

d94460ce cmTarget: Implement GetProperty in terms of cmState::Snapshot
4b9292a9 cmTarget: Group code for checking written properties together
a89dc537 cmTarget: Move sanity checks and computed property access to 
callers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d94460ce3ff089c7746d24378f899008a2e5385d
commit d94460ce3ff089c7746d24378f899008a2e5385d
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 13 00:18:26 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 16 12:09:43 2016 +0200

cmTarget: Implement GetProperty in terms of cmState::Snapshot

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index d8bc64a..b2b7cd6 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -1215,10 +1215,16 @@ const char* cmTarget::GetProperty(const std::string& 
prop) const
   return this->GetName().c_str();
 }
 if (prop == propBINARY_DIR) {
-  return this->GetMakefile()->GetCurrentBinaryDirectory();
+  return this->GetMakefile()
+->GetStateSnapshot()
+.GetDirectory()
+.GetCurrentBinary();
 }
 if (prop == propSOURCE_DIR) {
-  return this->GetMakefile()->GetCurrentSourceDirectory();
+  return this->GetMakefile()
+->GetStateSnapshot()
+.GetDirectory()
+.GetCurrentSource();
 }
   }
 
@@ -1227,7 +1233,8 @@ const char* cmTarget::GetProperty(const std::string& 
prop) const
 const bool chain = this->GetMakefile()->GetState()->IsPropertyChained(
   prop, cmProperty::TARGET);
 if (chain) {
-  return this->Makefile->GetProperty(prop, chain);
+  return this->Makefile->GetStateSnapshot().GetDirectory().GetProperty(
+prop, chain);
 }
   }
   return retVal;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b9292a9458d25a9394190de5ac9d9d056768070
commit 4b9292a9458d25a9394190de5ac9d9d056768070
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 13 00:18:26 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 16 12:09:42 2016 +0200

cmTarget: Group code for checking written properties together

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index ef13b26..d8bc64a 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -852,7 +852,20 @@ void cmTarget::SetProperty(const std::string& prop, const 
char* value)
 e << "NAME property is read-only\n";
 this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str());
 return;
+  } else if (prop == "EXPORT_NAME" && this->IsImported()) {
+std::ostringstream e;
+e << "EXPORT_NAME property can't be set on imported targets (\""
+  << this->Name << "\")\n";
+this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str());
+return;
+  } else if (prop == "SOURCES" && this->IsImported()) {
+std::ostringstream e;
+e << "SOURCES property can't be set on imported targets (\"" << this->Name
+  << "\")\n";
+this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str());
+return;
   }
+
   if (prop == "INCLUDE_DIRECTORIES") {
 this->Internal->IncludeDirectoriesEntries.clear();
 this->Internal->IncludeDirectoriesBacktraces.clear();
@@ -885,11 +898,6 @@ void cmTarget::SetProperty(const std::string& prop, const 
char* value)
   cmListFileBacktrace lfbt = this->Makefile->GetBacktrace();
   this->Internal->CompileDefinitionsBacktraces.push_back(lfbt);
 }
-  } else if (prop == "EXPORT_NAME" && t

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-533-g0fde927b

[Stephen Kelly]

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

The branch, next has been updated
   via  0fde927b36aa8972da15fefa3e0f01ee22c6bcef (commit)
   via  d1e7a46ad99e411a20740ffa651f9affee9ae427 (commit)
  from  2c0f3a34e5bd163b5194da61c9d1c0d89dc4f68d (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0fde927b36aa8972da15fefa3e0f01ee22c6bcef
commit 0fde927b36aa8972da15fefa3e0f01ee22c6bcef
Merge: 2c0f3a3 d1e7a46
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 16 06:09:30 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Oct 16 06:09:30 2016 -0400

Merge topic 'extract-computed-target-properties' into next

d1e7a46a fixup! cmTarget: Move sanity checks and computed property access 
to callers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1e7a46ad99e411a20740ffa651f9affee9ae427
commit d1e7a46ad99e411a20740ffa651f9affee9ae427
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 16 12:08:55 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 16 12:08:55 2016 +0200

fixup! cmTarget: Move sanity checks and computed property access to callers

diff --git a/Source/cmGetPropertyCommand.cxx b/Source/cmGetPropertyCommand.cxx
index b38950a..0a59933 100644
--- a/Source/cmGetPropertyCommand.cxx
+++ b/Source/cmGetPropertyCommand.cxx
@@ -10,6 +10,16 @@
 #include "cmTest.h"
 #include "cmake.h"
 
+#ifdef __clang__
+extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
+  cmTarget const* tgt);
+extern template const char* cmTargetPropertyComputer::ComputeLocation(
+  cmTarget const* tgt, std::string const& config);
+extern template const char* cmTargetPropertyComputer::GetSources(
+  cmTarget const* tgt, cmMessenger* messenger,
+  cmListFileBacktrace const& context);
+#endif
+
 cmGetPropertyCommand::cmGetPropertyCommand()
 {
   this->InfoType = OutValue;
diff --git a/Source/cmGetTargetPropertyCommand.cxx 
b/Source/cmGetTargetPropertyCommand.cxx
index 94f8942..d009bc3 100644
--- a/Source/cmGetTargetPropertyCommand.cxx
+++ b/Source/cmGetTargetPropertyCommand.cxx
@@ -4,6 +4,16 @@
 
 #include "cmTargetPropertyComputer.h"
 
+#ifdef __clang__
+extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
+  cmTarget const* tgt);
+extern template const char* cmTargetPropertyComputer::ComputeLocation(
+  cmTarget const* tgt, std::string const& config);
+extern template const char* cmTargetPropertyComputer::GetSources(
+  cmTarget const* tgt, cmMessenger* messenger,
+  cmListFileBacktrace const& context);
+#endif
+
 // cmSetTargetPropertyCommand
 bool cmGetTargetPropertyCommand::InitialPass(
   std::vector const& args, cmExecutionStatus&)

---

Summary of changes:
 Source/cmGetPropertyCommand.cxx   |   10 ++
 Source/cmGetTargetPropertyCommand.cxx |   10 ++
 2 files changed, 20 insertions(+)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-531-g2c0f3a3

[Stephen Kelly]

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

The branch, next has been updated
   via  2c0f3a34e5bd163b5194da61c9d1c0d89dc4f68d (commit)
   via  b59b6dd9d27de7839c7b23a3094db33298038896 (commit)
   via  b4234e977f65ee7df8adcd3888706dfd0dda (commit)
   via  f796e1b6f6984b200453a13e6b8640353ff9488b (commit)
   via  c75a9d660169ddd1e7be57486d3813ca73886b55 (commit)
   via  46ad0d2183230d1af93242efbdcce20d55514efb (commit)
   via  2628dec12cb22546d2a21032f53fb0ef096faec8 (commit)
   via  315b9a31895ca6bb26eba12bff3a0fe9cd37568a (commit)
   via  d5feb5b34cd9f595bf42aa934738b918785e3e87 (commit)
   via  efba22e1deebcfc3924d5f14c026104eb4b62d28 (commit)
   via  b29425f7aafe07eff526f3c7defb317856b72984 (commit)
   via  f009d8f5e2e4007b93494c5d22ba25b41a4872a1 (commit)
   via  6cd27a853a1c77e5da0a9a14140284a7674cf18c (commit)
   via  8b0e4795687a2ea289d1313db24d75bcf3cd13bc (commit)
   via  88016e2e9f13d60c4a0b88fb64ffd802a2d9e534 (commit)
   via  be87cb0c444595fa1970e257031252669c201d3e (commit)
   via  425cd1670fdd40b752af71e5f28952ae4fcec4ac (commit)
  from  590f2a365ed4ee2cc3a7fd93f55b2ab869fc3004 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c0f3a34e5bd163b5194da61c9d1c0d89dc4f68d
commit 2c0f3a34e5bd163b5194da61c9d1c0d89dc4f68d
Merge: 590f2a3 b59b6dd
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 15 05:26:07 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 15 05:26:07 2016 -0400

Merge topic 'extract-cmRulePlaceholderExpander' into next

b59b6dd9 cmRulePlaceholderExpander: Port clients to direct-use
b423 cmRulePlaceholderExpander: Extract from cmLocalGenerator
f796e1b6 cmLocalGenerator: Move memset to cxx file
c75a9d66 cmLocalGenerator: Use strings instead of a Target in rule 
replacement
46ad0d21 cmLocalGenerator: Use a converter in rule replacement API
2628dec1 cmLocalGenerator: Store variable replacements as state
315b9a31 cmLocalGenerator: Merge loops which populate mapping
d5feb5b3 cmLocalGenerator: Populate variable mapping for all replacements
efba22e1 cmLocalGenerator: Extract compiler option replacement from loop
b29425f7 cmLocalGenerator: Populate a container of mappings for replacements
f009d8f5 cmLocalGenerator: Move compiler option handling to be more direct
6cd27a85 cmLocalGenerator: Move variable to where it can be used easily
8b0e4795 cmLocalGenerator: Use the language from the compiler container
88016e2e cmLocalGenerator: Introduce a container of compiler names
be87cb0c cmLocalGenerator: Simplify loop with range algorithm
425cd167 cmLocalGenerator: Remove the launcher from RuleVariables


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b59b6dd9d27de7839c7b23a3094db33298038896
commit b59b6dd9d27de7839c7b23a3094db33298038896
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 10:34:50 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Oct 15 11:25:12 2016 +0200

cmRulePlaceholderExpander: Port clients to direct-use

Add a factory function to cmLocalGenerator so that variableMappings can
be provided from it, and so that Ninja can always have a hard-coded
TargetImpLib.

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 615168d..1c3a97d 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -133,6 +133,13 @@ cmLocalGenerator::cmLocalGenerator(cmGlobalGenerator* gg, 
cmMakefile* makefile)
   }
 }
 
+cmRulePlaceholderExpander* cmLocalGenerator::CreateRulePlaceholderExpander()
+  const
+{
+  return new cmRulePlaceholderExpander(this->Compilers, this->VariableMappings,
+   this->CompilerSysroot);
+}
+
 cmLocalGenerator::~cmLocalGenerator()
 {
   cmDeleteAll(this->GeneratorTargets);
@@ -561,17 +568,6 @@ cmState::Snapshot cmLocalGenerator::GetStateSnapshot() 
const
   return this->Makefile->GetStateSnapshot();
 }
 
-void cmLocalGenerator::ExpandRuleVariables(cmOutputConverter* outputConverter,
-   std::string& s,
-   const RuleVariables& replaceValues)
-{
-  cmRulePlaceholderExpander rulePlaceholderExpander(
-this->Compilers, this->VariableMappings, this->CompilerSysroot);
-  rulePlaceholderExpander.SetTargetImpLib(this->TargetImplib);
-  rulePlaceholderExpander.ExpandRuleVariables(outputConverter, s,
-

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-514-g590f2a3

[Stephen Kelly]

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

The branch, next has been updated
   via  590f2a365ed4ee2cc3a7fd93f55b2ab869fc3004 (commit)
   via  a5dfe2391b8d60fc2f6b5778687a9a338b6ed561 (commit)
   via  a365ab39a149ee2d71804e8dfd9a8c4636db9fac (commit)
   via  d409cb7bb7724b742efaa289d9183f5f5a840638 (commit)
   via  fa9dbc56a15aec71ac2eda7890efd0116797f373 (commit)
   via  848ae2a663ef83e059561d94b33d551154642231 (commit)
   via  a0a720e6a70133e361762101ce69a0b3f1ab244d (commit)
   via  637e3f3ee131cf30f7337db06314f4a1af22c245 (commit)
   via  05251e6d80b03ae14d6a89765f14c2eb10979bd4 (commit)
   via  fbf1721c94b40ea86eeb183a1916f2066eb64bdc (commit)
   via  390a7d8647c13570dc6416fceb884dc51c8ef6f9 (commit)
   via  e32a6bdd990571bafb8537110128d28a593150b7 (commit)
   via  7863fba1f6f37db2f75834d0d6a3fbbc680e731c (commit)
   via  8096682e4edb542a48bbf66c085911db5f00be02 (commit)
   via  7d57c1a2c926011bc2e4c7a65b802763ec4efbcb (commit)
   via  a55cac4ba475ff61da4146272246512a52247323 (commit)
   via  705fcf522be16eee03b1757274b23ada6547e6bd (commit)
   via  1fb6f672bd2bd041edb772b0627278383a00fb62 (commit)
   via  60b3f216c18aa317656433bcc0b724e6abd8d02f (commit)
   via  aaa5dbbf64392dad518668ac1d046d624dac41f3 (commit)
  from  749587d10ed558c20e8f45d2190999ebdda6c9c9 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=590f2a365ed4ee2cc3a7fd93f55b2ab869fc3004
commit 590f2a365ed4ee2cc3a7fd93f55b2ab869fc3004
Merge: 749587d a5dfe23
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 15 05:14:52 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 15 05:14:52 2016 -0400

Merge topic 'extract-computed-target-properties' into next

a5dfe239 cmTarget: Implement GetProperty in terms of cmState::Snapshot
a365ab39 cmTarget: Group code for checking written properties together
d409cb7b cmTarget: Move sanity checks and computed property access to 
callers
fa9dbc56 cmGeneratorTarget: Implement cmTargetPropertyComputer interface
848ae2a6 cmTargetPropertyComputer: Template some methods on the Target
a0a720e6 cm{,Generator}Target: Add global generator accessors
637e3f3e cmTargetPropertyComputer: Unify whitelist handling from cmTarget
05251e6d cmTargetPropertyComputer: Move whitelist check from cmTarget
fbf1721c cmTargetPropertyComputer: Extract into new files
390a7d86 cmTargetPropertyComputer: Implement GetProperty without cmMakefile
e32a6bdd cmListFileBacktrace: Add a method to retrieve the Bottom of a 
snapshot
7863fba1 cmTarget: Extract GetLocation method
8096682e cmTarget: Extract GetSources method
7d57c1a2 cmTarget: Extract location computation methods
a55cac4b cmTarget: Split property computation into separate class
705fcf52 cmTarget: Move IMPORTED check to callers
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a5dfe2391b8d60fc2f6b5778687a9a338b6ed561
commit a5dfe2391b8d60fc2f6b5778687a9a338b6ed561
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 13 00:18:26 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Oct 15 11:14:21 2016 +0200

cmTarget: Implement GetProperty in terms of cmState::Snapshot

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index d8bc64a..b2b7cd6 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -1215,10 +1215,16 @@ const char* cmTarget::GetProperty(const std::string& 
prop) const
   return this->GetName().c_str();
 }
 if (prop == propBINARY_DIR) {
-  return this->GetMakefile()->GetCurrentBinaryDirectory();
+  return this->GetMakefile()
+->GetStateSnapshot()
+.GetDirectory()
+.GetCurrentBinary();
 }
 if (prop == propSOURCE_DIR) {
-  return this->GetMakefile()->GetCurrentSourceDirectory();
+  return this->GetMakefile()
+->GetStateSnapshot()
+.GetDirectory()
+.GetCurrentSource();
 }
   }
 
@@ -1227,7 +1233,8 @@ const char* cmTarget::GetProperty(const std::string& 
prop) const
 const bool chain = this->GetMakefile()->GetState()->IsPropertyChained(
   prop, cmProperty::TARGET);
 if (chain) {
-  return this->Makefile->GetProperty(prop, chain);
+  return this->Makefile->GetStateSnapshot().GetDirectory().GetProperty(
+prop, chain);
 }
   }
   return retVal;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a365ab39a149ee2d71804e8dfd9a8c4636db9fac
commit a365ab39a149e

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-394-g67c528c

[Stephen Kelly]

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

The branch, next has been updated
   via  67c528c03d2c598e4922f932c5598d5da91bc408 (commit)
   via  6f0cee13fdadd4573e9dd57c1713d9a674abb713 (commit)
   via  a60ea0a957978495bd8a2dacb17447ef9e0bc694 (commit)
   via  8b3af6a7ca2d4938568df8dc70c9d44c62ba9fe1 (commit)
   via  49afda6b4e94d7747058bf5174bda6c333c921c6 (commit)
   via  91bc8ec9b8941f15c9adca532afa2dea9d1c1fa1 (commit)
   via  3743af8aa6db573370b5f4d10b06d35ab507b894 (commit)
   via  780b5ea7c5b416e17f469235c08679fa3417262b (commit)
   via  b9badf851e865ef7076abb49904785b026909a49 (commit)
   via  b2c6630c566344c4289cf312adfa45f939820f54 (commit)
  from  17bef2cd6780731f77be1383f74ddb5d9c44bffc (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67c528c03d2c598e4922f932c5598d5da91bc408
commit 67c528c03d2c598e4922f932c5598d5da91bc408
Merge: 17bef2c 6f0cee1
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Oct 10 18:44:22 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Oct 10 18:44:22 2016 -0400

Merge topic 'extract-cmRulePlaceholderExpander' into next

6f0cee13 cmRulePlaceholderExpander: Port clients to direct-use
a60ea0a9 cmRulePlaceholderExpander: Extract from cmLocalGenerator
8b3af6a7 cmLocalGenerator: Use strings instead of a Target in rule 
replacement
49afda6b cmLocalGenerator: Use a converter in rule replacement API
91bc8ec9 cmLocalGenerator: Store variable replacements as state
3743af8a cmLocalGenerator: Merge loops which populate mapping
780b5ea7 cmLocalGenerator: Populate variable mapping for all replacements
b9badf85 cmLocalGenerator: Extract compiler option replacement from loop
b2c6630c cmLocalGenerator: Populate a container of mappings for replacements


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f0cee13fdadd4573e9dd57c1713d9a674abb713
commit 6f0cee13fdadd4573e9dd57c1713d9a674abb713
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 10:34:50 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Tue Oct 11 00:43:48 2016 +0200

cmRulePlaceholderExpander: Port clients to direct-use

Add a factory function to cmLocalGenerator so that variableMappings can
be provided from it, and so that Ninja can always have a hard-coded
TargetImpLib.

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 615168d..1c3a97d 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -133,6 +133,13 @@ cmLocalGenerator::cmLocalGenerator(cmGlobalGenerator* gg, 
cmMakefile* makefile)
   }
 }
 
+cmRulePlaceholderExpander* cmLocalGenerator::CreateRulePlaceholderExpander()
+  const
+{
+  return new cmRulePlaceholderExpander(this->Compilers, this->VariableMappings,
+   this->CompilerSysroot);
+}
+
 cmLocalGenerator::~cmLocalGenerator()
 {
   cmDeleteAll(this->GeneratorTargets);
@@ -561,17 +568,6 @@ cmState::Snapshot cmLocalGenerator::GetStateSnapshot() 
const
   return this->Makefile->GetStateSnapshot();
 }
 
-void cmLocalGenerator::ExpandRuleVariables(cmOutputConverter* outputConverter,
-   std::string& s,
-   const RuleVariables& replaceValues)
-{
-  cmRulePlaceholderExpander rulePlaceholderExpander(
-this->Compilers, this->VariableMappings, this->CompilerSysroot);
-  rulePlaceholderExpander.SetTargetImpLib(this->TargetImplib);
-  rulePlaceholderExpander.ExpandRuleVariables(outputConverter, s,
-  replaceValues);
-}
-
 const char* cmLocalGenerator::GetRuleLauncher(cmGeneratorTarget* target,
   const std::string& prop)
 {
diff --git a/Source/cmLocalGenerator.h b/Source/cmLocalGenerator.h
index 6f8426d..055e1a9 100644
--- a/Source/cmLocalGenerator.h
+++ b/Source/cmLocalGenerator.h
@@ -24,6 +24,7 @@ class cmComputeLinkInformation;
 class cmCustomCommandGenerator;
 class cmGeneratorTarget;
 class cmGlobalGenerator;
+class cmRulePlaceholderExpander;
 class cmMakefile;
 class cmSourceFile;
 class cmLinkLineComputer;
@@ -85,6 +86,8 @@ public:
 return this->GlobalGenerator;
   }
 
+  virtual cmRulePlaceholderExpander* CreateRulePlaceholderExpander() const;
+
   std::string GetLinkLibsCMP0065(std::string const& linkLanguage,
  cmGeneratorTarget& tgt) const;
 
@@ -218,10 +221,6 @@ public:
   // preprocessed 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-384-g17bef2c

[Stephen Kelly]

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

The branch, next has been updated
   via  17bef2cd6780731f77be1383f74ddb5d9c44bffc (commit)
   via  9dcfa5f09b2b6345c3a83612a69d3e94bc43aac9 (commit)
  from  885c6f5f348a45174cf5e3a799dc8c0f13c37e67 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17bef2cd6780731f77be1383f74ddb5d9c44bffc
commit 17bef2cd6780731f77be1383f74ddb5d9c44bffc
Merge: 885c6f5 9dcfa5f
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Oct 10 18:05:12 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Oct 10 18:05:12 2016 -0400

Merge topic 'extract-cmRulePlaceholderExpander' into next

9dcfa5f0 Fix output bug


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9dcfa5f09b2b6345c3a83612a69d3e94bc43aac9
commit 9dcfa5f09b2b6345c3a83612a69d3e94bc43aac9
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 11 00:04:49 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Tue Oct 11 00:04:49 2016 +0200

Fix output bug

diff --git a/Source/cmRulePlaceholderExpander.cxx 
b/Source/cmRulePlaceholderExpander.cxx
index 796c975..601c3b4 100644
--- a/Source/cmRulePlaceholderExpander.cxx
+++ b/Source/cmRulePlaceholderExpander.cxx
@@ -204,8 +204,8 @@ std::string cmRulePlaceholderExpander::ExpandRuleVariable(
 this->Compilers.find(variable);
 
   if (compIt != this->Compilers.end()) {
-std::string ret =
-  this->VariableMappings["CMAKE_" + compIt->second + "_COMPILER"];
+std::string ret = outputConverter->ConvertToOutputForExisting(
+  this->VariableMappings["CMAKE_" + compIt->second + "_COMPILER"]);
 std::string const& compilerArg1 =
   this->VariableMappings[compIt->first + "_COMPILER_ARG1"];
 std::string const& compilerTarget =

---

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


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-382-g885c6f5

[Stephen Kelly]

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

The branch, next has been updated
   via  885c6f5f348a45174cf5e3a799dc8c0f13c37e67 (commit)
   via  ca40503553b08255ae8a67168ee840b9e7487011 (commit)
   via  8bb3d57e7eaa89fb394e33aa29849ee559f29915 (commit)
   via  0cd57caf76abd5560cf09b12c4e894e505980948 (commit)
   via  fd5440694f9dd2d9d1d70d6bcd58a928c8d2e912 (commit)
   via  adee2f4b870ad5aa27437feaf7360ae984afcf27 (commit)
   via  3855acab5f925de761e384007592f54b471eeacd (commit)
   via  331e584c686e3a20708287d807f18a60d64568b0 (commit)
   via  76624fb8470bdc63b3844f84edc3c941bc524f41 (commit)
   via  5e5c1c9224b7b10df29732ab16d7fbc052faba40 (commit)
   via  881c15b360a11f4951ba185e54fbaf8ec028b237 (commit)
   via  7c4ce8062620e6d1375316a5c8966690c475fc2a (commit)
   via  beac5cbd01a48e0d53114ee0156f79108a6ab6ac (commit)
   via  b2fa025ce3d264d9f3313a83ef77a0ded398d07f (commit)
   via  4bc4312ca064a82b3ac157ef0b67235e5cb02afc (commit)
   via  d7f6a6164e7775eeabec0aa5d66c81a365b3d1f1 (commit)
  from  e5c68d04f4eb28ab4f967fe1f127be6b28c0ec92 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=885c6f5f348a45174cf5e3a799dc8c0f13c37e67
commit 885c6f5f348a45174cf5e3a799dc8c0f13c37e67
Merge: e5c68d0 ca40503
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Oct 10 17:23:44 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Oct 10 17:23:44 2016 -0400

Merge topic 'extract-cmRulePlaceholderExpander' into next

ca405035 cmRulePlaceholderExpander: Port clients to direct-use
8bb3d57e cmRulePlaceholderExpander: Extract from cmLocalGenerator
0cd57caf cmLocalGenerator: Use strings instead of a Target in rule 
replacement
fd544069 cmLocalGenerator: Use a converter in rule replacement API
adee2f4b cmLocalGenerator: Store variable replacements as state
3855acab cmLocalGenerator: Merge loops which populate mapping
331e584c cmLocalGenerator: Populate variable mapping for all replacements
76624fb8 cmLocalGenerator: Extract compiler option replacement from loop
5e5c1c92 cmLocalGenerator: Populate a container of mappings for replacements
881c15b3 cmLocalGenerator: Move compiler option handling to be more direct
7c4ce806 cmLocalGenerator: Move variable to where it can be used easily
beac5cbd cmLocalGenerator: Use the language from the compiler container
b2fa025c cmLocalGenerator: Introduce a container of compiler names
4bc4312c cmLocalGenerator: Simplify loop with range algorithm
d7f6a616 cmLocalGenerator: Remove the launcher from RuleVariables

diff --cc Source/cmMakefileLibraryTargetGenerator.cxx
index 8a621ea,9f5f0c1..cb8b5e8
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@@ -595,10 -609,25 +597,20 @@@ void cmMakefileLibraryTargetGenerator::
  this->LocalGenerator->AddArchitectureFlags(
langFlags, this->GeneratorTarget, linkLanguage, this->ConfigName);
  
 -// remove any language flags that might not work with the
 -// particular os
 -if (forbiddenFlagVar) {
 -  this->RemoveForbiddenFlags(forbiddenFlagVar, linkLanguage, langFlags);
 -}
  vars.LanguageCompileFlags = langFlags.c_str();
  
+ std::string launcher;
+ const char* val = this->LocalGenerator->GetRuleLauncher(
+   this->GeneratorTarget, "RULE_LAUNCH_LINK");
+ if (val && *val) {
+   launcher = val;
+   launcher += " ";
+ }
+ 
+ CM_AUTO_PTR rulePlaceholderExpander(
+   this->LocalGenerator->CreateRulePlaceholderExpander());
  // Construct the main link rule and expand placeholders.
- this->LocalGenerator->TargetImplib = targetOutPathImport;
+ rulePlaceholderExpander->SetTargetImpLib(targetOutPathImport);
  if (useArchiveRules) {
// Construct the individual object list strings.
std::vector object_strings;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca40503553b08255ae8a67168ee840b9e7487011
commit ca40503553b08255ae8a67168ee840b9e7487011
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 10:34:50 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Mon Oct 10 21:58:50 2016 +0200

cmRulePlaceholderExpander: Port clients to direct-use

Add a factory function to cmLocalGenerator so that variableMappings can
be provided from it, and so that Ninja can always have a hard-coded
TargetImpLib.

diff --git a/Source/cmLocalGenerator.cx

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-360-gf62d2c8

[Stephen Kelly]

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

The branch, next has been updated
   via  f62d2c869f7ebbb418bde71bff2ecbfc7a3993b2 (commit)
   via  4134030434ea88024ef46f9f00b19513fc3cec4c (commit)
   via  f03d446e967af91460ff31eb52d840983b3d8cec (commit)
   via  3444105f9fe4fcee390c8d616e1a211a078a630b (commit)
   via  77c4202edc242c96087295585a85a20700bdb26f (commit)
   via  09b6cc66b09b9689ca01faee5e33ef101b46f972 (commit)
   via  0c978063259fb013856b617d680cebcdee51ab1a (commit)
   via  0152a01f11fc46f645fd765cc7b1be76cc07b52a (commit)
   via  011e6870e4a7f19476c162a8c011fd018d9a7e9c (commit)
   via  cbca80f3516d7e5b2def6105a1b26b44bad7b6fe (commit)
   via  d48f69d0f5f265d1c091a614098cae3ff4325fbe (commit)
   via  ff8e321c6ade784b3f1b3b19a7783788872e44a9 (commit)
   via  80f57e67eefc905a726f2f35bd1672a188ea4c99 (commit)
   via  7ef834682547df5e0ccdcd503558dcbf1206a638 (commit)
   via  69295812065a5d07c07347add2fdcf8f36f993ba (commit)
   via  5b361fdda0f2808f0368b746a880981ebda0ade0 (commit)
   via  2e5d1990f382aa42e8a0ad34117ee1e5a9187153 (commit)
   via  b3701f9a5213f2ff5b2bc197e9af5d1f2ff68a9c (commit)
  from  dd75faf01aecc93c32cbc5941d29033e33af0521 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f62d2c869f7ebbb418bde71bff2ecbfc7a3993b2
commit f62d2c869f7ebbb418bde71bff2ecbfc7a3993b2
Merge: dd75faf 4134030
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Oct 10 14:44:12 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Oct 10 14:44:12 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

41340304 cmLinkLineComputer: Extract link libraries computation from 
cmLocalGenerator
f03d446e cmLinkLineComputer: Move FrameworkPath computation from 
cmLocalGenerator
3444105f cmLocalGenerator: Inline last use of local variable
77c4202e cmLinkLineComputer: Move RPath computation from cmLocalGenerator
09b6cc66 cmLinkLineComputer: Move LinkPath computation from cmLocalGenerator
0c978063 cmLinkLineComputer: Move ComputeLinkLibs from cmLocalGenerator
0152a01f cmLocalGenerator: Move variable to where it is used
011e6870 cmLocalGenerator: Use a std::string instead of char*
cbca80f3 cmLocalGenerator: Move stringstream to where it is used
d48f69d0 cmLocalGenerator: Move flag determination up in the function
ff8e321c cmLocalGenerator: Separate stdlib content from library stream
80f57e67 cmLocalGenerator: Separate rpath content from library stream
7ef83468 cmLocalGenerator: Pass link library info to OutputLinkLibraries
69295812 Makefiles: Port CreateLinkLibs to cmLinkLineComputer
5b361fdd cmLinkLineComputer: Extract from cmLocalGenerator
2e5d1990 Ninja: Constify
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4134030434ea88024ef46f9f00b19513fc3cec4c
commit 4134030434ea88024ef46f9f00b19513fc3cec4c
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 12:21:39 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Mon Oct 10 20:38:59 2016 +0200

cmLinkLineComputer: Extract link libraries computation from cmLocalGenerator

Hide some methods which no longer need to be public.

diff --git a/Source/cmLinkLineComputer.cxx b/Source/cmLinkLineComputer.cxx
index 41096ef..24f3578 100644
--- a/Source/cmLinkLineComputer.cxx
+++ b/Source/cmLinkLineComputer.cxx
@@ -152,3 +152,28 @@ std::string cmLinkLineComputer::ComputeFrameworkPath(
   }
   return frameworkPath;
 }
+
+std::string cmLinkLineComputer::ComputeLinkLibraries(
+  cmComputeLinkInformation& cli, std::string const& stdLibString)
+{
+  std::ostringstream fout;
+  fout << this->ComputeRPath(cli);
+
+  // Write the library flags to the build rule.
+  fout << this->ComputeLinkLibs(cli);
+
+  // Add the linker runtime search path if any.
+  std::string rpath_link = cli.GetRPathLinkString();
+  if (!cli.GetRPathLinkFlag().empty() && !rpath_link.empty()) {
+fout << cli.GetRPathLinkFlag();
+fout << this->OutputConverter->EscapeForShell(rpath_link,
+  !this->ForResponse);
+fout << " ";
+  }
+
+  if (!stdLibString.empty()) {
+fout << stdLibString << " ";
+  }
+
+  return fout.str();
+}
diff --git a/Source/cmLinkLineComputer.h b/Source/cmLinkLineComputer.h
index f72368a..1fb9b24 100644
--- a/Source/cmLinkLineComputer.h
+++ b/Source/cmLinkLineComputer.h
@@ -22,18 +22,20 @@ public:
 
   virtua

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-304-gc238285

[Stephen Kelly]

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

The branch, next has been updated
   via  c2382855e6a9706c9f71beb1f57bfafc75587f65 (commit)
   via  7f13f7a99d4fefc39aafc6efe0582fa5ece4f8c9 (commit)
  from  6b05e33c95b2bb392f6c6602da4677747613e35d (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2382855e6a9706c9f71beb1f57bfafc75587f65
commit c2382855e6a9706c9f71beb1f57bfafc75587f65
Merge: 6b05e33 7f13f7a
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 07:14:44 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Oct 9 07:14:44 2016 -0400

Merge topic 'minor-cleanups' into next

7f13f7a9 fixup! cmLocalGenerator: Extract definition retrieval out of loop


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f13f7a99d4fefc39aafc6efe0582fa5ece4f8c9
commit 7f13f7a99d4fefc39aafc6efe0582fa5ece4f8c9
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 13:14:25 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 9 13:14:25 2016 +0200

fixup! cmLocalGenerator: Extract definition retrieval out of loop

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 0a99e87..025b82a 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1176,7 +1176,8 @@ void cmLocalGenerator::GetTargetFlags(
   !(this->Makefile->IsOn("CYGWIN") || this->Makefile->IsOn("MINGW"))) {
 std::vector<cmSourceFile*> sources;
 target->GetSourceFiles(sources, buildType);
-std::string defFlag = 
this->Makefile->GetSafeDefinition("CMAKE_LINK_DEF_FILE_FLAG");
+std::string defFlag =
+  this->Makefile->GetSafeDefinition("CMAKE_LINK_DEF_FILE_FLAG");
 for (std::vector<cmSourceFile*>::const_iterator i = sources.begin();
  i != sources.end(); ++i) {
   cmSourceFile* sf = *i;

---

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


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-302-g6b05e33

[Stephen Kelly]

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

The branch, next has been updated
   via  6b05e33c95b2bb392f6c6602da4677747613e35d (commit)
   via  5de760147f83b507f5b5dda7051eb1f6386e052b (commit)
   via  95ac050958f063223a4a3f660aa5d8521b089c3f (commit)
   via  6e3b88962c6762ab384ef73c9a77444ace4b0738 (commit)
   via  2a49d86d5dec66f7696bd7063459f504cc336a5e (commit)
   via  b0301db23b12351720993a351fedf081ca0fa444 (commit)
   via  267e02097e90d05a16ffd1aa53fb7910b79aa0ec (commit)
   via  009019f2596de08c488588fd2c67a423f9fe92bf (commit)
   via  378849f41e574e72c577b549dfc2d5333ca8f9b5 (commit)
   via  4a3c49b4698f0e8c20c345770f551142088a3037 (commit)
  from  2f5c30a55bdabcf606b26abb89395608170f9ae2 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6b05e33c95b2bb392f6c6602da4677747613e35d
commit 6b05e33c95b2bb392f6c6602da4677747613e35d
Merge: 2f5c30a 5de7601
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 04:49:00 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Oct 9 04:49:00 2016 -0400

Merge topic 'minor-cleanups' into next

5de76014 cmMakefile: Return a string from GetDefineFlags
95ac0509 Test: Remove condition for CMake version no longer supported
6e3b8896 cmLocalGenerator: Extract definition retrieval out of loop
2a49d86d Makefiles: Inline only use of method
b0301db2 Makefiles: Make helper class independent of cmLocalGenerator
267e0209 cmMakefile: Remove pointless condition
009019f2 Makefiles: Extract identical code from condition
378849f4 Makefiles: Replace array access with local variable
4a3c49b4 Makefiles: Separate two coupled calls


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5de760147f83b507f5b5dda7051eb1f6386e052b
commit 5de760147f83b507f5b5dda7051eb1f6386e052b
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 10:47:45 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 9 10:47:45 2016 +0200

cmMakefile: Return a string from GetDefineFlags

Flip condition in GHS for readability.

diff --git a/Source/cmGhsMultiTargetGenerator.cxx 
b/Source/cmGhsMultiTargetGenerator.cxx
index 959dfdb..fac68f5 100644
--- a/Source/cmGhsMultiTargetGenerator.cxx
+++ b/Source/cmGhsMultiTargetGenerator.cxx
@@ -244,7 +244,7 @@ void 
cmGhsMultiTargetGenerator::SetCompilerFlags(std::string const& config,
   flags, this->GeneratorTarget, lang);
 
 // Append old-style preprocessor definition flags.
-if (std::string(" ") != std::string(this->Makefile->GetDefineFlags())) {
+if (this->Makefile->GetDefineFlags() != " ") {
   this->LocalGenerator->AppendFlags(flags,
 this->Makefile->GetDefineFlags());
 }
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 40344ce..de7bead 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -447,7 +447,7 @@ public:
   /**
* Get a list of preprocessor define flags.
*/
-  const char* GetDefineFlags() const { return this->DefineFlags.c_str(); }
+  std::string GetDefineFlags() const { return this->DefineFlags; }
 
   /**
* Make sure CMake can write this file

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95ac050958f063223a4a3f660aa5d8521b089c3f
commit 95ac050958f063223a4a3f660aa5d8521b089c3f
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 10:47:44 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 9 10:47:44 2016 +0200

Test: Remove condition for CMake version no longer supported

diff --git a/Tests/FindPackageModeMakefileTest/CMakeLists.txt 
b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
index 56fcc5d..23832da 100644
--- a/Tests/FindPackageModeMakefileTest/CMakeLists.txt
+++ b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
@@ -20,16 +20,9 @@ if(UNIX  AND  "${CMAKE_GENERATOR}" MATCHES "Makefile" AND
 configure_file(FindFoo.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/FindFoo.cmake 
@ONLY)
 
 # now set up the test:
-if (NOT CMAKE_VERSION VERSION_LESS 2.8.12)
-  file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/cmakeExecutable.mk"
-CONTENT "CMAKE = \"$\"\n"
-  )
-else()
-  get_target_property(cmakeLocation cmake LOCATION)
-  file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/cmakeExecutable.mk"
-"CMAKE = \"${cmakeLocation}\"\n"
-  )
-endif()
+file(GENERATE 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-292-g2f5c30a

[Stephen Kelly]

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

The branch, next has been updated
   via  2f5c30a55bdabcf606b26abb89395608170f9ae2 (commit)
   via  65ca5dfc857fd295495941a65ce3862675f50d59 (commit)
  from  9ba2a76c8636156de00496f62a4d9d2be85b1b56 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2f5c30a55bdabcf606b26abb89395608170f9ae2
commit 2f5c30a55bdabcf606b26abb89395608170f9ae2
Merge: 9ba2a76 65ca5df
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 19:09:55 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 8 19:09:55 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

65ca5dfc fixup! cmLinkLineComputer: Extract from cmLocalGenerator


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65ca5dfc857fd295495941a65ce3862675f50d59
commit 65ca5dfc857fd295495941a65ce3862675f50d59
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sun Oct 9 01:09:29 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sun Oct 9 01:09:29 2016 +0200

fixup! cmLinkLineComputer: Extract from cmLocalGenerator

diff --git a/Source/cmGhsMultiTargetGenerator.cxx 
b/Source/cmGhsMultiTargetGenerator.cxx
index 7bafbb0..dd8b36f 100644
--- a/Source/cmGhsMultiTargetGenerator.cxx
+++ b/Source/cmGhsMultiTargetGenerator.cxx
@@ -5,6 +5,7 @@
 #include "cmGeneratedFileStream.h"
 #include "cmGeneratorTarget.h"
 #include "cmGlobalGhsMultiGenerator.h"
+#include "cmLinkLineComputer.h"
 #include "cmLocalGhsMultiGenerator.h"
 #include "cmMakefile.h"
 #include "cmSourceFile.h"

---

Summary of changes:
 Source/cmGhsMultiTargetGenerator.cxx |1 +
 1 file changed, 1 insertion(+)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-290-g9ba2a76

[Stephen Kelly]

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

The branch, next has been updated
   via  9ba2a76c8636156de00496f62a4d9d2be85b1b56 (commit)
   via  8d9daade39b9ebb190f32597469910a70a8131d0 (commit)
  from  0428c729ec5203a1887bbb078940a4fc0ad20be0 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ba2a76c8636156de00496f62a4d9d2be85b1b56
commit 9ba2a76c8636156de00496f62a4d9d2be85b1b56
Merge: 0428c72 8d9daad
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 17:25:56 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 8 17:25:56 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

8d9daade fixup! cmLinkLineComputer: Move ComputeLinkLibs from 
cmLocalGenerator


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d9daade39b9ebb190f32597469910a70a8131d0
commit 8d9daade39b9ebb190f32597469910a70a8131d0
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 23:25:38 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Oct 8 23:25:38 2016 +0200

fixup! cmLinkLineComputer: Move ComputeLinkLibs from cmLocalGenerator

diff --git a/Source/cmGhsMultiTargetGenerator.cxx 
b/Source/cmGhsMultiTargetGenerator.cxx
index acf06e4..7bafbb0 100644
--- a/Source/cmGhsMultiTargetGenerator.cxx
+++ b/Source/cmGhsMultiTargetGenerator.cxx
@@ -363,8 +363,8 @@ void cmGhsMultiTargetGenerator::WriteTargetLinkLibraries(
 bool useWatcomQuote =
   this->Makefile->IsOn(createRule + "_USE_WATCOM_QUOTE");
 CM_AUTO_PTR linkLineComputer(
-  this->LocalGenerator,
   this->GetGlobalGenerator()->CreateLinkLineComputer(
+this->LocalGenerator,
 this->LocalGenerator->GetStateSnapshot().GetDirectory()));
 linkLineComputer->SetUseWatcomQuote(useWatcomQuote);
 

---

Summary of changes:
 Source/cmGhsMultiTargetGenerator.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-288-g0428c72

[Stephen Kelly]

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

The branch, next has been updated
   via  0428c729ec5203a1887bbb078940a4fc0ad20be0 (commit)
   via  ae6ee87520349c432aad6f1dfa987a1cc630eacd (commit)
  from  742fcc25999fa30d348dc6df35cd07ecbdcb6fe9 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0428c729ec5203a1887bbb078940a4fc0ad20be0
commit 0428c729ec5203a1887bbb078940a4fc0ad20be0
Merge: 742fcc2 ae6ee87
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 16:28:51 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 8 16:28:51 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

ae6ee875 fixup! Makefiles: Port CreateLinkLibs to cmLinkLineComputer


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae6ee87520349c432aad6f1dfa987a1cc630eacd
commit ae6ee87520349c432aad6f1dfa987a1cc630eacd
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 22:28:30 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Oct 8 22:28:30 2016 +0200

fixup! Makefiles: Port CreateLinkLibs to cmLinkLineComputer

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index c45ff7e..5c31e3e 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1226,7 +1226,7 @@ void cmLocalGenerator::GetTargetFlags(
 return;
   }
   this->AddLanguageFlags(flags, linkLanguage, buildType);
-  if (!pcli) {
+  if (pcli) {
 this->OutputLinkLibraries(pcli, linkLineComputer, linkLibs,
   frameworkPath, linkPath);
   }

---

Summary of changes:
 Source/cmLocalGenerator.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-286-g742fcc2

[Stephen Kelly]

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

The branch, next has been updated
   via  742fcc25999fa30d348dc6df35cd07ecbdcb6fe9 (commit)
   via  b57b7870f6e188136ec0bae6ebc555c882feee90 (commit)
   via  076d39926f899f88e30b4128c2c835ab35091a31 (commit)
   via  b06615050293a04b7e7ef8ccf97ec706351d761e (commit)
   via  7a7a02193745d52183cdd203deb1a93d49f797e7 (commit)
   via  639cbcdaf9e7dc5ae9e4156ec2f21ad1c8634acf (commit)
   via  62e5fc1dbf477bb2628dee9d2e9bf143609f441b (commit)
   via  37cab7eb17b505a18f534408307797a5e126663e (commit)
   via  0e16f8f8067ae721d23e842b83e0e24d4e5d2b49 (commit)
   via  47e6e46fcf85e73b65b0f93be4e1d9aeb72b9579 (commit)
   via  2f81fb21790dac9f6036d804d68f108bb498b720 (commit)
   via  cc911145ee8a4a8bb1fcea6fecf77cba37fcf261 (commit)
   via  2bfda685be5c8138d5b5d5c2366dc41665ef7064 (commit)
   via  ac5daf964a49edc00dc23c621cb5fbc6b9deca4e (commit)
   via  61d7cc52ebd5bcaf9676a285268e1dc8c1131908 (commit)
   via  c5800af1919ce735267f1dca4e0d9c5234ca9ce3 (commit)
   via  dffcc796ef7759fcb6bdfad7c576adc88e60a7ca (commit)
   via  c12c7f35633c1b75e4ed2c84e021065fce82716d (commit)
   via  8312fd5c1f82d5acc600c9d796ff99620cbbd3e1 (commit)
  from  1991df2f67e587f01de2836f09015fc1983d1a45 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=742fcc25999fa30d348dc6df35cd07ecbdcb6fe9
commit 742fcc25999fa30d348dc6df35cd07ecbdcb6fe9
Merge: 1991df2 b57b787
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 16:00:36 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 8 16:00:36 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

b57b7870 cmLinkLineComputer: Extract link libraries computation from 
cmLocalGenerator
076d3992 cmLinkLineComputer: Move FrameworkPath computation from 
cmLocalGenerator
b0661505 cmLocalGenerator: Inline last use of local variable
7a7a0219 cmLinkLineComputer: Move RPath computation from cmLocalGenerator
639cbcda cmLinkLineComputer: Move LinkPath computation from cmLocalGenerator
62e5fc1d cmLinkLineComputer: Move ComputeLinkLibs from cmLocalGenerator
37cab7eb cmLocalGenerator: Move variable to where it is used
0e16f8f8 cmLocalGenerator: Use a std::string instead of char*
47e6e46f cmLocalGenerator: Move stringstream to where it is used
2f81fb21 cmLocalGenerator: Move flag determination up in the function
cc911145 cmLocalGenerator: Separate stdlib content from library stream
2bfda685 cmLocalGenerator: Separate rpath content from library stream
ac5daf96 cmLocalGenerator: Pass link library info to OutputLinkLibraries
61d7cc52 Makefiles: Port CreateLinkLibs to cmLinkLineComputer
c5800af1 cmLinkLineComputer: Extract from cmLocalGenerator
dffcc796 Ninja: Constify
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b57b7870f6e188136ec0bae6ebc555c882feee90
commit b57b7870f6e188136ec0bae6ebc555c882feee90
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 12:21:39 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Oct 8 13:47:24 2016 +0200

cmLinkLineComputer: Extract link libraries computation from cmLocalGenerator

Hide some methods which no longer need to be public.

diff --git a/Source/cmLinkLineComputer.cxx b/Source/cmLinkLineComputer.cxx
index 41096ef..24f3578 100644
--- a/Source/cmLinkLineComputer.cxx
+++ b/Source/cmLinkLineComputer.cxx
@@ -152,3 +152,28 @@ std::string cmLinkLineComputer::ComputeFrameworkPath(
   }
   return frameworkPath;
 }
+
+std::string cmLinkLineComputer::ComputeLinkLibraries(
+  cmComputeLinkInformation& cli, std::string const& stdLibString)
+{
+  std::ostringstream fout;
+  fout << this->ComputeRPath(cli);
+
+  // Write the library flags to the build rule.
+  fout << this->ComputeLinkLibs(cli);
+
+  // Add the linker runtime search path if any.
+  std::string rpath_link = cli.GetRPathLinkString();
+  if (!cli.GetRPathLinkFlag().empty() && !rpath_link.empty()) {
+fout << cli.GetRPathLinkFlag();
+fout << this->OutputConverter->EscapeForShell(rpath_link,
+  !this->ForResponse);
+fout << " ";
+  }
+
+  if (!stdLibString.empty()) {
+fout << stdLibString << " ";
+  }
+
+  return fout.str();
+}
diff --git a/Source/cmLinkLineComputer.h b/Source/cmLinkLineComputer.h
index f72368a..1fb9b24 100644
--- a/Source/cmLinkLineComputer.h
+++ b/Source/c

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-267-g1991df2

[Stephen Kelly]

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

The branch, next has been updated
   via  1991df2f67e587f01de2836f09015fc1983d1a45 (commit)
   via  cc5e6b82c2ae8293a400b604e0366578f9097d94 (commit)
  from  e0f428248c51aacfc2b9e53cca5b88aa15042013 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1991df2f67e587f01de2836f09015fc1983d1a45
commit 1991df2f67e587f01de2836f09015fc1983d1a45
Merge: e0f4282 cc5e6b8
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 05:36:14 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 8 05:36:14 2016 -0400

Merge topic 'ninja-cleanups' into next

cc5e6b82 Ninja: Extract identical code from condition


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc5e6b82c2ae8293a400b604e0366578f9097d94
commit cc5e6b82c2ae8293a400b604e0366578f9097d94
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 22:56:32 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Oct 8 11:36:02 2016 +0200

Ninja: Extract identical code from condition

diff --git a/Source/cmLocalNinjaGenerator.cxx b/Source/cmLocalNinjaGenerator.cxx
index 22fae4c..b04c11d 100644
--- a/Source/cmLocalNinjaGenerator.cxx
+++ b/Source/cmLocalNinjaGenerator.cxx
@@ -492,10 +492,8 @@ std::string cmLocalNinjaGenerator::MakeCustomLauncher(
 if (ccg.GetWorkingDirectory().empty()) {
   output =
 this->ConvertToRelativePath(this->GetCurrentBinaryDirectory(), output);
-  output = this->ConvertToOutputFormat(output, cmOutputConverter::SHELL);
-} else {
-  output = this->ConvertToOutputFormat(output, cmOutputConverter::SHELL);
 }
+output = this->ConvertToOutputFormat(output, cmOutputConverter::SHELL);
   }
   vars.Output = output.c_str();
 

---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-265-ge0f4282

[Stephen Kelly]

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

The branch, next has been updated
   via  e0f428248c51aacfc2b9e53cca5b88aa15042013 (commit)
   via  cfcf11093df6477b04e19dad4c4fa56f1032faa5 (commit)
  from  e8ce84727ed59d55c37adbf06cde0e2f114c46e1 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e0f428248c51aacfc2b9e53cca5b88aa15042013
commit e0f428248c51aacfc2b9e53cca5b88aa15042013
Merge: e8ce847 cfcf110
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 05:35:45 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Oct 8 05:35:45 2016 -0400

Merge topic 'ninja-cleanups' into next

cfcf1109 Revert partially


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cfcf11093df6477b04e19dad4c4fa56f1032faa5
commit cfcf11093df6477b04e19dad4c4fa56f1032faa5
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Oct 8 11:34:31 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Oct 8 11:35:22 2016 +0200

Revert partially

diff --git a/Source/cmGlobalNinjaGenerator.cxx 
b/Source/cmGlobalNinjaGenerator.cxx
index 1b4e34c..f5a0e68 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -834,27 +834,9 @@ std::string 
cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string& path)
 {
   cmLocalNinjaGenerator* ng =
 static_cast<cmLocalNinjaGenerator*>(this->LocalGenerators[0]);
-
-  return ConvertToNinjaPath(path, ng->GetStateSnapshot().GetDirectory(),
-this->OutputPathPrefix);
-}
-
-std::string cmGlobalNinjaGenerator::ConvertToNinjaPath(
-  const std::string& path, cmState::Directory stateDir,
-  std::string const& prefix)
-{
-  std::string convPath = path;
-
-  if (cmOutputConverter::ContainedInDirectory(stateDir.GetCurrentBinary(),
-  path, stateDir)) {
-convPath = cmOutputConverter::ForceToRelativePath(
-  stateDir.GetCurrentBinary(), path);
-  }
-
-  if (!cmSystemTools::FileIsFullPath(convPath)) {
-convPath = prefix + convPath;
-  }
-
+  std::string convPath = ng->ConvertToRelativePath(
+this->LocalGenerators[0]->GetState()->GetBinaryDirectory(), path);
+  convPath = this->NinjaOutputPath(convPath);
 #ifdef _WIN32
   std::replace(convPath.begin(), convPath.end(), '/', '\\');
 #endif
@@ -1441,7 +1423,7 @@ void cmGlobalNinjaGenerator::InitOutputPathPrefix()
 
 std::string cmGlobalNinjaGenerator::NinjaOutputPath(std::string const& path)
 {
-  if (cmSystemTools::FileIsFullPath(path)) {
+  if (!this->HasOutputPathPrefix() || cmSystemTools::FileIsFullPath(path)) {
 return path;
   }
   return this->OutputPathPrefix + path;
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index 51a8032..dcf7406 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -233,9 +233,6 @@ public:
 return this->RulesFileStream;
   }
 
-  static std::string ConvertToNinjaPath(const std::string& path,
-cmState::Directory stateDir,
-std::string const& prefix);
   std::string ConvertToNinjaPath(const std::string& path);
   std::string ConvertToNinjaFolderRule(const std::string& path);
 

---

Summary of changes:
 Source/cmGlobalNinjaGenerator.cxx |   26 --
 Source/cmGlobalNinjaGenerator.h   |3 ---
 2 files changed, 4 insertions(+), 25 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-260-g1035d0e

[Stephen Kelly]

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

The branch, next has been updated
   via  1035d0e0d270301d266f2d20b39bf09fa3448972 (commit)
   via  a1cfc4fe3deed4d642773d0ae63dd524c3f2eba1 (commit)
   via  4079ba20d9d9c8d15fd28d9440d56c907dda811c (commit)
   via  17ab8e33f005aab3e493ac4535f63b6f229aacab (commit)
  from  d808f0fdad129f19f1607aa5585a5642fcecf01a (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1035d0e0d270301d266f2d20b39bf09fa3448972
commit 1035d0e0d270301d266f2d20b39bf09fa3448972
Merge: d808f0f a1cfc4f
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 16:08:36 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Oct 7 16:08:36 2016 -0400

Merge topic 'clean-up-link-configuration' into next

a1cfc4fe cmMakefile: Simplify programmer error to an assert
4079ba20 cmMakefile: Implement LinkLibraries as an internal property
17ab8e33 cmMakefile: Inline method into only remaining caller


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a1cfc4fe3deed4d642773d0ae63dd524c3f2eba1
commit a1cfc4fe3deed4d642773d0ae63dd524c3f2eba1
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 20:13:37 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 22:08:03 2016 +0200

cmMakefile: Simplify programmer error to an assert

diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 47d9b47..6ab45bb 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1832,14 +1832,9 @@ cmTarget* cmMakefile::AddLibrary(const std::string& 
lname,
  const std::vector& srcs,
  bool excludeFromAll)
 {
-  // wrong type ? default to STATIC
-  if ((type != cmState::STATIC_LIBRARY) && (type != cmState::SHARED_LIBRARY) &&
-  (type != cmState::MODULE_LIBRARY) && (type != cmState::OBJECT_LIBRARY) &&
-  (type != cmState::INTERFACE_LIBRARY)) {
-this->IssueMessage(cmake::INTERNAL_ERROR,
-   "cmMakefile::AddLibrary given invalid target type.");
-type = cmState::STATIC_LIBRARY;
-  }
+  assert(type == cmState::STATIC_LIBRARY || type == cmState::SHARED_LIBRARY ||
+ type == cmState::MODULE_LIBRARY || type == cmState::OBJECT_LIBRARY ||
+ type == cmState::INTERFACE_LIBRARY);
 
   cmTarget* target = this->AddNewTarget(type, lname);
   // Clear its dependencies. Otherwise, dependencies might persist

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4079ba20d9d9c8d15fd28d9440d56c907dda811c
commit 4079ba20d9d9c8d15fd28d9440d56c907dda811c
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 20:13:37 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 22:07:50 2016 +0200

cmMakefile: Implement LinkLibraries as an internal property

cmMakefile should not have logic particular to individual cmake
commands.  The link_libraries() command is generally obsolete in favor
of target_link_libraries().  An alternative language for CMake probably
would not offer the former.  The quirks and historical behaviors of the
current language should be separate from the core classes of CMake to
allow replacing the language.

diff --git a/Source/cmLinkLibrariesCommand.cxx 
b/Source/cmLinkLibrariesCommand.cxx
index 3fc7bd9..4202cf5 100644
--- a/Source/cmLinkLibrariesCommand.cxx
+++ b/Source/cmLinkLibrariesCommand.cxx
@@ -20,7 +20,7 @@ bool 
cmLinkLibrariesCommand::InitialPass(std::vector const& args,
"a library");
 return false;
   }
-  this->Makefile->AddLinkLibrary(*i, DEBUG_LibraryType);
+  this->Makefile->AppendProperty("LINK_LIBRARIES", "debug");
 } else if (*i == "optimized") {
   ++i;
   if (i == args.end()) {
@@ -28,10 +28,9 @@ bool 
cmLinkLibrariesCommand::InitialPass(std::vector const& args,
"a library");
 return false;
   }
-  this->Makefile->AddLinkLibrary(*i, OPTIMIZED_LibraryType);
-} else {
-  this->Makefile->AddLinkLibrary(*i, GENERAL_LibraryType);
+  this->Makefile->AppendProperty("LINK_LIBRARIES", "optimized");
 }
+this->Makefile->AppendProperty("LINK_LIBRARIES", i->c_str());
   }
 
   return true;
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 6e451b6..47d9b47 1006

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-256-gd808f0f

[Stephen Kelly]

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

The branch, next has been updated
   via  d808f0fdad129f19f1607aa5585a5642fcecf01a (commit)
   via  f17210aec9bf7db8272ab7ce7eea7addd07587fd (commit)
  from  61e69451ace821aaa94a9ba2b2f4e15140222736 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d808f0fdad129f19f1607aa5585a5642fcecf01a
commit d808f0fdad129f19f1607aa5585a5642fcecf01a
Merge: 61e6945 f17210a
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 16:06:06 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Oct 7 16:06:06 2016 -0400

Merge topic 'clean-up-link-configuration' into next

f17210ae Fix style


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f17210aec9bf7db8272ab7ce7eea7addd07587fd
commit f17210aec9bf7db8272ab7ce7eea7addd07587fd
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 22:05:47 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 22:05:47 2016 +0200

Fix style

diff --git a/Source/cmCPluginAPI.cxx b/Source/cmCPluginAPI.cxx
index b2da329..56a469d 100644
--- a/Source/cmCPluginAPI.cxx
+++ b/Source/cmCPluginAPI.cxx
@@ -338,25 +338,22 @@ void CCONV cmAddCustomCommandToTarget(void* arg, const 
char* target,
 }
 
 static void addLinkLibrary(cmMakefile* mf, std::string const& target,
- std::string const& lib, cmTargetLinkLibraryType llt)
+   std::string const& lib, cmTargetLinkLibraryType llt)
 {
   cmTarget* t = mf->FindLocalNonAliasTarget(target);
-  if (!t)
-{
+  if (!t) {
 std::ostringstream e;
-e << "Attempt to add link library \""
-  << lib << "\" to target \""
-  << target << "\" which is not built in this directory.";
+e << "Attempt to add link library \"" << lib << "\" to target \"" << target
+  << "\" which is not built in this directory.";
 mf->IssueMessage(cmake::FATAL_ERROR, e.str());
 return;
-}
+  }
 
   cmTarget* tgt = mf->GetGlobalGenerator()->FindTarget(lib);
-  if(tgt && (tgt->GetType() != cmState::STATIC_LIBRARY) &&
- (tgt->GetType() != cmState::SHARED_LIBRARY) &&
- (tgt->GetType() != cmState::INTERFACE_LIBRARY) &&
- !tgt->IsExecutableWithExports())
-{
+  if (tgt && (tgt->GetType() != cmState::STATIC_LIBRARY) &&
+  (tgt->GetType() != cmState::SHARED_LIBRARY) &&
+  (tgt->GetType() != cmState::INTERFACE_LIBRARY) &&
+  !tgt->IsExecutableWithExports()) {
 std::ostringstream e;
 e << "Target \"" << lib << "\" of type "
   << cmState::GetTargetTypeName(tgt->GetType())
@@ -364,9 +361,9 @@ static void addLinkLibrary(cmMakefile* mf, std::string 
const& target,
   << "One may link only to STATIC or SHARED libraries, or "
   << "to executables with the ENABLE_EXPORTS property set.";
 mf->IssueMessage(cmake::FATAL_ERROR, e.str());
-}
+  }
 
-  t->AddLinkLibrary( *mf, lib, llt );
+  t->AddLinkLibrary(*mf, lib, llt);
 }
 
 void CCONV cmAddLinkLibraryForTarget(void* arg, const char* tgt,
@@ -376,13 +373,13 @@ void CCONV cmAddLinkLibraryForTarget(void* arg, const 
char* tgt,
 
   switch (libtype) {
 case CM_LIBRARY_GENERAL:
-  addLinkLibrary(mf, tgt,value, GENERAL_LibraryType);
+  addLinkLibrary(mf, tgt, value, GENERAL_LibraryType);
   break;
 case CM_LIBRARY_DEBUG:
-  addLinkLibrary(mf, tgt,value, DEBUG_LibraryType);
+  addLinkLibrary(mf, tgt, value, DEBUG_LibraryType);
   break;
 case CM_LIBRARY_OPTIMIZED:
-  addLinkLibrary(mf, tgt,value, OPTIMIZED_LibraryType);
+  addLinkLibrary(mf, tgt, value, OPTIMIZED_LibraryType);
   break;
   }
 }
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index d443423..6ab45bb 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1238,8 +1238,7 @@ void cmMakefile::InitializeFromParent(cmMakefile* parent)
   }
 
   // link libraries
-  this->SetProperty("LINK_LIBRARIES",
-parent->GetProperty("LINK_LIBRARIES"));
+  this->SetProperty("LINK_LIBRARIES", parent->GetProperty("LINK_LIBRARIES"));
 
   // link directories
   this->SetProperty("LINK_DIRECTORIES",
@@ -1804,14 +1803,

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-254-g61e6945

[Stephen Kelly]

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

The branch, next has been updated
   via  61e69451ace821aaa94a9ba2b2f4e15140222736 (commit)
   via  f4458e9fd0120198fab3b862f1e12552fd9d9c4b (commit)
  from  da3c79a376774a27792e349381ea727bc91e1eef (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61e69451ace821aaa94a9ba2b2f4e15140222736
commit 61e69451ace821aaa94a9ba2b2f4e15140222736
Merge: da3c79a f4458e9
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 16:05:06 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Oct 7 16:05:06 2016 -0400

Merge topic 'clean-up-link-configuration' into next

f4458e9f cmMakefile: Simplify programmer error to an assert


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f4458e9fd0120198fab3b862f1e12552fd9d9c4b
commit f4458e9fd0120198fab3b862f1e12552fd9d9c4b
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 20:13:37 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 22:04:54 2016 +0200

cmMakefile: Simplify programmer error to an assert

diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 2414b32..d443423 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1836,14 +1836,9 @@ cmTarget* cmMakefile::AddLibrary(const std::string& 
lname,
  const std::vector& srcs,
  bool excludeFromAll)
 {
-  // wrong type ? default to STATIC
-  if ((type != cmState::STATIC_LIBRARY) && (type != cmState::SHARED_LIBRARY) &&
-  (type != cmState::MODULE_LIBRARY) && (type != cmState::OBJECT_LIBRARY) &&
-  (type != cmState::INTERFACE_LIBRARY)) {
-this->IssueMessage(cmake::INTERNAL_ERROR,
-   "cmMakefile::AddLibrary given invalid target type.");
-type = cmState::STATIC_LIBRARY;
-  }
+  assert(type == cmState::STATIC_LIBRARY || type == cmState::SHARED_LIBRARY ||
+  type == cmState::MODULE_LIBRARY || type == cmState::OBJECT_LIBRARY ||
+  type == cmState::INTERFACE_LIBRARY);
 
   cmTarget* target = this->AddNewTarget(type, lname);
   // Clear its dependencies. Otherwise, dependencies might persist

---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-252-gda3c79a

[Stephen Kelly]

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

The branch, next has been updated
   via  da3c79a376774a27792e349381ea727bc91e1eef (commit)
   via  d8633d344b2393a38746898963f7fdd5c997098a (commit)
  from  9f667ee9f52f436a3d43121d43c8efe4e05709e1 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da3c79a376774a27792e349381ea727bc91e1eef
commit da3c79a376774a27792e349381ea727bc91e1eef
Merge: 9f667ee d8633d3
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 16:04:44 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Oct 7 16:04:44 2016 -0400

Merge topic 'clean-up-link-configuration' into next

d8633d34 Revert "cmMakefile: Move link_libraries() related code out"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8633d344b2393a38746898963f7fdd5c997098a
commit d8633d344b2393a38746898963f7fdd5c997098a
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 22:04:20 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 22:04:20 2016 +0200

Revert "cmMakefile: Move link_libraries() related code out"

This reverts commit 9723f4ddb9cc0767b7b963aa31def62c11b05c50.

diff --git a/Source/cmAddExecutableCommand.cxx 
b/Source/cmAddExecutableCommand.cxx
index 10b4b76..96ad82a 100644
--- a/Source/cmAddExecutableCommand.cxx
+++ b/Source/cmAddExecutableCommand.cxx
@@ -2,8 +2,6 @@
file Copyright.txt or https://cmake.org/licensing for details.  */
 #include "cmAddExecutableCommand.h"
 
-#include "cmLinkLibrariesCommand.h"
-
 // cmExecutableCommand
 bool cmAddExecutableCommand::InitialPass(std::vector const& args,
  cmExecutionStatus&)
@@ -190,9 +188,6 @@ bool 
cmAddExecutableCommand::InitialPass(std::vector const& args,
   std::vector srclists(s, args.end());
   cmTarget* tgt =
 this->Makefile->AddExecutable(exename.c_str(), srclists, excludeFromAll);
-
-  cmLinkLibrariesCommand::PopulateTarget(*tgt, this->Makefile);
-
   if (use_win32) {
 tgt->SetProperty("WIN32_EXECUTABLE", "ON");
   }
diff --git a/Source/cmAddLibraryCommand.cxx b/Source/cmAddLibraryCommand.cxx
index 8c02f75..26e38b8 100644
--- a/Source/cmAddLibraryCommand.cxx
+++ b/Source/cmAddLibraryCommand.cxx
@@ -4,7 +4,6 @@
 
 #include "cmState.h"
 #include "cmake.h"
-#include "cmLinkLibrariesCommand.h"
 
 // cmLibraryCommand
 bool cmAddLibraryCommand::InitialPass(std::vector const& args,
@@ -356,9 +355,7 @@ bool 
cmAddLibraryCommand::InitialPass(std::vector const& args,
 
   srclists.insert(srclists.end(), s, args.end());
 
-  cmTarget* tgt = this->Makefile->AddLibrary(libName, type, srclists, 
excludeFromAll);
-
-  cmLinkLibrariesCommand::PopulateTarget(*tgt, this->Makefile);
+  this->Makefile->AddLibrary(libName, type, srclists, excludeFromAll);
 
   return true;
 }
diff --git a/Source/cmLinkLibrariesCommand.cxx 
b/Source/cmLinkLibrariesCommand.cxx
index ecf3f57..4202cf5 100644
--- a/Source/cmLinkLibrariesCommand.cxx
+++ b/Source/cmLinkLibrariesCommand.cxx
@@ -35,57 +35,3 @@ bool 
cmLinkLibrariesCommand::InitialPass(std::vector const& args,
 
   return true;
 }
-
-void cmLinkLibrariesCommand::PopulateTarget(cmTarget& target, cmMakefile* mf)
-{
-  // for these targets do not add anything
-  switch (target.GetType()) {
-case cmState::UTILITY:
-case cmState::GLOBAL_TARGET:
-case cmState::INTERFACE_LIBRARY:
-  return;
-default:;
-  }
-  if (const char* linkDirsProp = mf->GetProperty("LINK_DIRECTORIES")) {
-std::vector linkDirs;
-cmSystemTools::ExpandListArgument(linkDirsProp, linkDirs);
-
-for (std::vector::iterator j = linkDirs.begin();
- j != linkDirs.end(); ++j) {
-  std::string newdir = *j;
-  // remove trailing slashes
-  if (*j->rbegin() == '/') {
-newdir = j->substr(0, j->size() - 1);
-  }
-  target.AddLinkDirectory(*j);
-}
-  }
-
-  if (const char* linkLibsProp = mf->GetProperty("LINK_LIBRARIES")) {
-std::vector linkLibs;
-cmSystemTools::ExpandListArgument(linkLibsProp, linkLibs);
-
-for (std::vector::iterator j = linkLibs.begin();
- j != linkLibs.end(); ++j) {
-  std::string libraryName = *j;
-  cmTargetLinkLibraryType libType = GENERAL_LibraryType;
-  if (libraryName == "optimized")
-  {
-libType = OPTIMIZED_LibraryType;
-++j;
-libraryName = *j;
-  } else
-  if (libr

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-250-g9f667ee

[Stephen Kelly]

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

The branch, next has been updated
   via  9f667ee9f52f436a3d43121d43c8efe4e05709e1 (commit)
   via  87bde938fe3c66fc6298108c7594578005bbb2a6 (commit)
   via  9723f4ddb9cc0767b7b963aa31def62c11b05c50 (commit)
   via  cd04ce0a7f6317169f6d8738f56b46c658314bd0 (commit)
   via  d89821cdd61896d7500f8ca2378294d9cf7aa27e (commit)
   via  7edfcd0e834a4dc8d3da9cada6ad6b9b46dfb4dd (commit)
   via  6c8dc7f1df6d3492d11ad994a35ee2f0b8a4e60b (commit)
   via  1efca9f427a5c537afc034aadf0c29073bfdfa22 (commit)
   via  d9b5f0a301c23c2c0e56ad3fcb696de71c3d6365 (commit)
   via  1c70c6cc09f0f8be087db2aeae5ee6a3f1b47bda (commit)
   via  2b7baed719e4a6eb918ed6f22ee6031a40b7f316 (commit)
   via  7ba954925a876f4c753a4296236bc7d2f18eb0b8 (commit)
   via  6d98b15fc8b9a065325e3683afe94efce17dd162 (commit)
   via  869037ee86d1c0ab757840adf499ea270d4301e1 (commit)
   via  2f6462a634726d9d0ea8d8552454839d67183016 (commit)
   via  148b83a12185d7611ff7576464087430c3f2719c (commit)
   via  4457a9f181663701961dc209740974f48213e6e7 (commit)
   via  4d039c5b46e3cac29ff1d9ce3e768af1bca6b69a (commit)
   via  c8ec8d6a7ec6c176bc14e7026dc755a9be8689cb (commit)
   via  3e8d47d18b4db6b4621ee5e4864dde234ad8a282 (commit)
   via  3b4895fa35e4a96022abd99b07002a7d2ab3a968 (commit)
   via  2232e97a6ed4a338b814d1ba3d62a7ffa9ef6e7f (commit)
   via  9a1d4e4ba170f4ac34c80593bd2fe8e1481a1181 (commit)
   via  8391b3015a82909828b7ada98e76d45aa11b892b (commit)
  from  befbf7ad51059b6077de1fa34a59bde28284731a (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f667ee9f52f436a3d43121d43c8efe4e05709e1
commit 9f667ee9f52f436a3d43121d43c8efe4e05709e1
Merge: befbf7a 87bde93
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 15:49:21 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Oct 7 15:49:21 2016 -0400

Merge topic 'clean-up-link-configuration' into next

87bde938 cmMakefile: Simplify programmer error to an assert
9723f4dd cmMakefile: Move link_libraries() related code out
cd04ce0a cmMakefile: Implement LinkLibraries as an internal property
d89821cd cmMakefile: Inline method into only remaining caller
7edfcd0e cmMakefile: Inline method into caller
6c8dc7f1 cmake: Simplify find-package mode library addition
1efca9f4 cmMakefile: Remove obsolete parameter
d9b5f0a3 cmTarget: Remove target name from parameter list
1c70c6cc cmMakefile: Use public API to find a target
2b7baed7 cmMakefile: Inline method into only caller
7ba95492 cmMakefile: Use public API to find a target
6d98b15f cmMakefile: Invert if() condition to remove else
869037ee cmMakefile: Remove ALIAS check
2f6462a6 cmMakefile: Collapse two consecutive if()s into one
148b83a1 cmMakefile: DeMorgan-invert condition
4457a9f1 cmMakefile: Return after error and remove else condition
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87bde938fe3c66fc6298108c7594578005bbb2a6
commit 87bde938fe3c66fc6298108c7594578005bbb2a6
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 20:13:37 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 21:33:25 2016 +0200

cmMakefile: Simplify programmer error to an assert

diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 12f971f..c4d6103 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1782,14 +1782,9 @@ cmTarget* cmMakefile::AddLibrary(const std::string& 
lname,
  const std::vector& srcs,
  bool excludeFromAll)
 {
-  // wrong type ? default to STATIC
-  if ((type != cmState::STATIC_LIBRARY) && (type != cmState::SHARED_LIBRARY) &&
-  (type != cmState::MODULE_LIBRARY) && (type != cmState::OBJECT_LIBRARY) &&
-  (type != cmState::INTERFACE_LIBRARY)) {
-this->IssueMessage(cmake::INTERNAL_ERROR,
-   "cmMakefile::AddLibrary given invalid target type.");
-type = cmState::STATIC_LIBRARY;
-  }
+  assert(type == cmState::STATIC_LIBRARY || type == cmState::SHARED_LIBRARY ||
+  type == cmState::MODULE_LIBRARY || type == cmState::OBJECT_LIBRARY ||
+  type == cmState::INTERFACE_LIBRARY);
 
   cmTarget* target = this->AddNewTarget(type, lname);
   // Clear its dependencies. Otherwise, dependencies might persist

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-226-gbefbf7a

[Stephen Kelly]

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

The branch, next has been updated
   via  befbf7ad51059b6077de1fa34a59bde28284731a (commit)
   via  cb56b773baeb123f22a8d4409c1a68bce0d3e45c (commit)
   via  409a2a800115fb55aadf78e23deb85a57b8ffcbe (commit)
   via  0a291271fdbd530a38722bc554e7bbb49cc7245d (commit)
   via  4eb2c4dcaf55ea08c633871fc54dba411803832d (commit)
   via  c12a24cefaebc06d825578270473bf4537568ffb (commit)
   via  cf39fd0f40c77a3a05fd921e66ee814a572e4086 (commit)
   via  d9fde87d1a3a4de382d664bd121af957af6eaaea (commit)
   via  d92c160db333bf65e52da1cb73a068b5d3f1db4f (commit)
  from  4b64d265ee79a39aabe6241f3e0811f38c0c2177 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=befbf7ad51059b6077de1fa34a59bde28284731a
commit befbf7ad51059b6077de1fa34a59bde28284731a
Merge: 4b64d26 cb56b77
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Fri Oct 7 15:48:13 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Oct 7 15:48:13 2016 -0400

Merge topic 'ninja-cleanups' into next

cb56b773 Ninja: Extract a static path conversion method
409a2a80 Ninja: Inline conversion to relative path
0a291271 Ninja: Get the binary directory from cmState::Directory
4eb2c4dc Ninja: Inline output path conversion
c12a24ce Ninja: Simplify method
cf39fd0f Ninja: Extract identical code from condition
d9fde87d Ninja: Replace array access with local variable
d92c160d Ninja: Separate two coupled calls


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cb56b773baeb123f22a8d4409c1a68bce0d3e45c
commit cb56b773baeb123f22a8d4409c1a68bce0d3e45c
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 22:56:33 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 21:37:38 2016 +0200

Ninja: Extract a static path conversion method

It is independent of cmLocalGenerator.

diff --git a/Source/cmGlobalNinjaGenerator.cxx 
b/Source/cmGlobalNinjaGenerator.cxx
index 9a7939e..1b4e34c 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -835,8 +835,14 @@ std::string 
cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string& path)
   cmLocalNinjaGenerator* ng =
 static_cast<cmLocalNinjaGenerator*>(this->LocalGenerators[0]);
 
-  cmState::Directory stateDir = ng->GetStateSnapshot().GetDirectory();
+  return ConvertToNinjaPath(path, ng->GetStateSnapshot().GetDirectory(),
+this->OutputPathPrefix);
+}
 
+std::string cmGlobalNinjaGenerator::ConvertToNinjaPath(
+  const std::string& path, cmState::Directory stateDir,
+  std::string const& prefix)
+{
   std::string convPath = path;
 
   if (cmOutputConverter::ContainedInDirectory(stateDir.GetCurrentBinary(),
@@ -846,7 +852,7 @@ std::string 
cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string& path)
   }
 
   if (!cmSystemTools::FileIsFullPath(convPath)) {
-convPath = this->OutputPathPrefix + convPath;
+convPath = prefix + convPath;
   }
 
 #ifdef _WIN32
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index dcf7406..51a8032 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -233,6 +233,9 @@ public:
 return this->RulesFileStream;
   }
 
+  static std::string ConvertToNinjaPath(const std::string& path,
+cmState::Directory stateDir,
+std::string const& prefix);
   std::string ConvertToNinjaPath(const std::string& path);
   std::string ConvertToNinjaFolderRule(const std::string& path);
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=409a2a800115fb55aadf78e23deb85a57b8ffcbe
commit 409a2a800115fb55aadf78e23deb85a57b8ffcbe
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 22:56:33 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Fri Oct 7 21:37:38 2016 +0200

Ninja: Inline conversion to relative path

diff --git a/Source/cmGlobalNinjaGenerator.cxx 
b/Source/cmGlobalNinjaGenerator.cxx
index 5bec420..9a7939e 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -837,8 +837,13 @@ std::string 
cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string& path)
 
   cmState::Directory stateDir = ng->GetStateSnapshot().GetDirectory();
 
-  std::string convPath =
-ng->ConvertToRelativePath(stateDir.GetCurrentBinary(), p

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-164-gaf6f300

[Stephen Kelly]

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

The branch, next has been updated
   via  af6f3004dcf83123b3d12cf7446edb51bbec1b14 (commit)
   via  2c7bc60834cde0c0e5eff03db092c341dfac78b7 (commit)
  from  ab65a1e18599219c644889c4d4cb1b45c0dc8383 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af6f3004dcf83123b3d12cf7446edb51bbec1b14
commit af6f3004dcf83123b3d12cf7446edb51bbec1b14
Merge: ab65a1e 2c7bc60
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 16:44:59 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 16:44:59 2016 -0400

Merge topic 'CMP0065-LINK_FLAGS' into next

2c7bc608 fixup! CMP0065: Put computed flags into LINK_FLAGS not 
LINK_LIBRARIES


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c7bc60834cde0c0e5eff03db092c341dfac78b7
commit 2c7bc60834cde0c0e5eff03db092c341dfac78b7
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 22:44:41 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 22:44:41 2016 +0200

fixup! CMP0065: Put computed flags into LINK_FLAGS not LINK_LIBRARIES

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index a0ff824..3fabd53 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1438,6 +1438,8 @@ void cmLocalGenerator::OutputLinkLibraries(std::string& 
linkLibraries,
 
   std::string linkLanguage = cli.GetLinkLanguage();
 
+  std::string linkLibs;
+
   std::string libPathFlag =
 this->Makefile->GetRequiredDefinition("CMAKE_LIBRARY_PATH_FLAG");
   std::string libPathTerminator =

---

Summary of changes:
 Source/cmLocalGenerator.cxx |2 ++
 1 file changed, 2 insertions(+)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-162-gab65a1e

[Stephen Kelly]

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

The branch, next has been updated
   via  ab65a1e18599219c644889c4d4cb1b45c0dc8383 (commit)
   via  d96271d9e14354ffb93f80a5ba85fb337767a6c5 (commit)
   via  7f1cd3280cf484b5d565a12ae57022de018faa57 (commit)
   via  2597bcf831dae6a0a7a212607ea4b926ec6b10e0 (commit)
  from  f90c7ba54f1a9a61e930292207d3387df40b2dad (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab65a1e18599219c644889c4d4cb1b45c0dc8383
commit ab65a1e18599219c644889c4d4cb1b45c0dc8383
Merge: f90c7ba d96271d
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 16:35:44 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 16:35:44 2016 -0400

Merge topic 'CMP0065-LINK_FLAGS' into next

d96271d9 CMP0065: Put computed flags into LINK_FLAGS not LINK_LIBRARIES
7f1cd328 cmLocalGenerator: Rename local variable to be more appropriate
2597bcf8 cmLocalGenerator: Extract policy handling into a method


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d96271d9e14354ffb93f80a5ba85fb337767a6c5
commit d96271d9e14354ffb93f80a5ba85fb337767a6c5
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 22:25:44 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 22:33:01 2016 +0200

CMP0065: Put computed flags into LINK_FLAGS not LINK_LIBRARIES

These flags are redundant anyway in the NEW case of the policy, and
could be merged with CMAKE_EXE_EXPORTS_${lang}_FLAG content for that
case.  That is deferred to the future, but now at least the similar code
is located close to each other.

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index a0f6423..a0ff824 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1248,6 +1248,14 @@ void cmLocalGenerator::GetTargetFlags(
 linkFlags += this->Makefile->GetSafeDefinition(exportFlagVar);
 linkFlags += " ";
   }
+
+  std::string cmp0065Flags =
+this->GetLinkLibsCMP0065(linkLanguage, *target);
+  if (!cmp0065Flags.empty()) {
+linkFlags += cmp0065Flags;
+linkFlags += " ";
+  }
+
   const char* targetLinkFlags = target->GetProperty("LINK_FLAGS");
   if (targetLinkFlags) {
 linkFlags += targetLinkFlags;
@@ -1430,8 +1438,6 @@ void cmLocalGenerator::OutputLinkLibraries(std::string& 
linkLibraries,
 
   std::string linkLanguage = cli.GetLinkLanguage();
 
-  std::string linkLibs = this->GetLinkLibsCMP0065(linkLanguage, tgt);
-
   std::string libPathFlag =
 this->Makefile->GetRequiredDefinition("CMAKE_LIBRARY_PATH_FLAG");
   std::string libPathTerminator =
diff --git a/Source/cmMakefileExecutableTargetGenerator.cxx 
b/Source/cmMakefileExecutableTargetGenerator.cxx
index cb20117..42e12ad 100644
--- a/Source/cmMakefileExecutableTargetGenerator.cxx
+++ b/Source/cmMakefileExecutableTargetGenerator.cxx
@@ -192,6 +192,11 @@ void 
cmMakefileExecutableTargetGenerator::WriteExecutableRule(bool relink)
 this->LocalGenerator->AppendFlags(
   linkFlags, this->Makefile->GetDefinition(export_flag_var));
   }
+
+  this->LocalGenerator->AppendFlags(linkFlags,
+this->LocalGenerator->GetLinkLibsCMP0065(
+  linkLanguage, *this->GeneratorTarget));
+
   if (this->GeneratorTarget->GetProperty("LINK_WHAT_YOU_USE")) {
 this->LocalGenerator->AppendFlags(linkFlags, " -Wl,--no-as-needed");
   }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f1cd3280cf484b5d565a12ae57022de018faa57
commit 7f1cd3280cf484b5d565a12ae57022de018faa57
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 22:25:05 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 22:25:05 2016 +0200

cmLocalGenerator: Rename local variable to be more appropriate

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 6cc03e8..a0f6423 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1531,7 +1531,7 @@ void cmLocalGenerator::OutputLinkLibraries(std::string& 
linkLibraries,
 std::string cmLocalGenerator::GetLinkLibsCMP0065(
   std::string const& linkLanguage, cmGeneratorTarget& tgt) const
 {
-  std::string linkLibs;
+  std::string linkFlags;
 
   // Flags to link an executable to shared libraries.
   if (tgt.GetType() == cmState::EXECUTABLE &&
@@ -

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-155-gc8a4533

[Stephen Kelly]

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

The branch, next has been updated
   via  c8a45332313cac5acc6661f8bcf4993d1fb81b49 (commit)
   via  20e62f74c5a030a25fe1c3a6c835d67eea152d8f (commit)
   via  fd93b3605bc931b5ce2386816973e106fa1ec646 (commit)
   via  1365e18b9b5ddfb5bc13da5bcdefeb566be12f08 (commit)
   via  1ed5f6b39b80ab337551f1fa9601b3257ddd4be7 (commit)
   via  8377d9e00b7a00f1687b947aaf3c9e10b6779df4 (commit)
   via  00173b71d97f81cc9db9b573998bd4359aa2c25b (commit)
   via  d5911ef014fcffd14d397759ca638519733a48ad (commit)
   via  c3264f48c2960325b9141d3ec58c6b49afe120c9 (commit)
   via  52168f3210ca07a8d80991958d588789c2693d63 (commit)
   via  5213f8936fd5a70e1f38939e5d1894e7fabb9e02 (commit)
   via  b61c268bd04425597e2e9c5f213dea3cdad3cb19 (commit)
   via  e278f5a84806a2b228182dc4a2cc98a1eaa19f8c (commit)
  from  78a3604d252b6f42d192807b9bac84f46e6ec76f (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8a45332313cac5acc6661f8bcf4993d1fb81b49
commit c8a45332313cac5acc6661f8bcf4993d1fb81b49
Merge: 78a3604 20e62f7
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 15:00:27 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 15:00:27 2016 -0400

Merge topic 'cleanup-Convert' into next

20e62f74 cmLocalGenerator: Simplify ConvertToLinkReference
fd93b360 cmOutputConverter: Add a flag for IsUnix
1365e18b Convert: Inline platform-specific methods
1ed5f6b3 Makefiles: Introduce local RelativePath method
8377d9e0 Fortran: Inline conversion to relative path
00173b71 Fortran: Wrap path convert in a call with a more-suitable name
d5911ef0 Makefiles: Hardcode the relative location of the CMakeCache file
c3264f48 Convert: Extract method to determine if paths are in directory
52168f32 Convert: Remove asserts which are duplicated in delegate method
5213f893 Convert: Remove early return check
b61c268b Convert: Extract local variables for readability
e278f5a8 Convert: Extract local variables


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20e62f74c5a030a25fe1c3a6c835d67eea152d8f
commit 20e62f74c5a030a25fe1c3a6c835d67eea152d8f
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 22:56:32 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 20:02:10 2016 +0200

cmLocalGenerator: Simplify ConvertToLinkReference

Make conversion to output format the caller responsibility, so that the
method only 'converts to a link reference'.

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index 6887a31..14ea1a9 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -75,8 +75,10 @@ void 
cmCommonTargetGenerator::AddModuleDefinitionFlag(std::string& flags)
   // Append the flag and value.  Use ConvertToLinkReference to help
   // vs6's "cl -link" pass it to the linker.
   std::string flag = defFileFlag;
-  flag += (this->LocalGenerator->ConvertToLinkReference(
-this->ModuleDefinitionFile->GetFullPath()));
+  flag += this->LocalGenerator->ConvertToOutputFormat(
+this->LocalGenerator->ConvertToLinkReference(
+  this->ModuleDefinitionFile->GetFullPath()),
+cmOutputConverter::SHELL);
   this->LocalGenerator->AppendFlags(flags, flag);
 }
 
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index f24b717..b2569a2 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1374,8 +1374,7 @@ std::string cmLocalGenerator::GetTargetFortranFlags(
   return std::string();
 }
 
-std::string cmLocalGenerator::ConvertToLinkReference(std::string const& lib,
- OutputFormat format)
+std::string cmLocalGenerator::ConvertToLinkReference(std::string const& lib)
 {
 #if defined(_WIN32) && !defined(__CYGWIN__)
   // Work-ardound command line parsing limitations in MSVC 6.0
@@ -1392,17 +1391,14 @@ std::string 
cmLocalGenerator::ConvertToLinkReference(std::string const& lib,
 // Append the rest of the path with no space.
 sp += lib.substr(pos);
 
-// Convert to an output path.
-return this->ConvertToOutputFormat(sp.c_str(), format);
+return sp;
   }
 }
   }
 #endif
 
   // Normal behavior.
-  return this->ConvertToOutputFormat(
-this->ConvertToRelativePath(this->GetCurrentBinaryDirectory(), lib),
-format);
+  return this-&

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-commits] CMake branch, next, updated. v3.7.0-rc1-142-g78a3604

[Stephen Kelly]

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

The branch, next has been updated
   via  78a3604d252b6f42d192807b9bac84f46e6ec76f (commit)
   via  d9718500fa01d3045ca86e85be68ab9dfee4cbed (commit)
  from  0d83b5464de903900cbe02e9bc484c30b37bca2b (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78a3604d252b6f42d192807b9bac84f46e6ec76f
commit 78a3604d252b6f42d192807b9bac84f46e6ec76f
Merge: 0d83b54 d971850
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 14:01:44 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 14:01:44 2016 -0400

Merge topic 'cleanup-Convert' into next

d9718500 Revert "cmOutputConverter: Remove Convert..ForExisting method 
(#16138)"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9718500fa01d3045ca86e85be68ab9dfee4cbed
commit d9718500fa01d3045ca86e85be68ab9dfee4cbed
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 20:00:51 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 20:00:51 2016 +0200

Revert "cmOutputConverter: Remove Convert..ForExisting method (#16138)"

This reverts commit 0fb47ff836af7fbd74998bfeb3067708b9f7db68.

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 8fcfb32..b2569a2 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -731,8 +731,7 @@ std::string cmLocalGenerator::ExpandRuleVariable(
 std::string replace = this->Makefile->GetSafeDefinition(variable);
 // if the variable is not a FLAG then treat it like a path
 if (variable.find("_FLAG") == variable.npos) {
-  std::string ret =
-this->ConvertToOutputFormat(replace, cmOutputConverter::SHELL);
+  std::string ret = this->ConvertToOutputForExisting(replace);
   // if there is a required first argument to the compiler add it
   // to the compiler string
   if (compilerArg1) {
@@ -829,7 +828,7 @@ std::string cmLocalGenerator::ConvertToIncludeReference(
   std::string const& path, OutputFormat format, bool forceFullPaths)
 {
   static_cast(forceFullPaths);
-  return this->ConvertToOutputFormat(path, format);
+  return this->ConvertToOutputForExisting(path, format);
 }
 
 std::string cmLocalGenerator::GetIncludeFlags(
@@ -1497,7 +1496,8 @@ void cmLocalGenerator::OutputLinkLibraries(std::string& 
linkLibraries,
   std::vector const& libDirs = cli.GetDirectories();
   for (std::vector::const_iterator libDir = libDirs.begin();
libDir != libDirs.end(); ++libDir) {
-std::string libpath = this->ConvertToOutputFormat(*libDir, shellFormat);
+std::string libpath =
+  this->ConvertToOutputForExisting(*libDir, shellFormat);
 linkPath += " " + libPathFlag;
 linkPath += libpath;
 linkPath += libPathTerminator;
diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index 401319e..915119c 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -2081,19 +2081,18 @@ void cmLocalUnixMakefileGenerator3::CreateCDCommand(
 // back because the shell keeps the working directory between
 // commands.
 std::string cmd = cd_cmd;
-cmd += this->ConvertToOutputFormat(tgtDir, cmOutputConverter::SHELL);
+cmd += this->ConvertToOutputForExisting(tgtDir);
 commands.insert(commands.begin(), cmd);
 
 // Change back to the starting directory.
 cmd = cd_cmd;
-cmd += this->ConvertToOutputFormat(relDir, cmOutputConverter::SHELL);
+cmd += this->ConvertToOutputForExisting(relDir);
 commands.push_back(cmd);
   } else {
 // On UNIX we must construct a single shell command to change
 // directory and build because make resets the directory between
 // each command.
-std::string outputForExisting =
-  this->ConvertToOutputFormat(tgtDir, cmOutputConverter::SHELL);
+std::string outputForExisting = this->ConvertToOutputForExisting(tgtDir);
 std::string prefix = cd_cmd + outputForExisting + " && ";
 std::transform(commands.begin(), commands.end(), commands.begin(),
std::bind1st(std::plus(), prefix));
diff --git a/Source/cmOutputConverter.cxx b/Source/cmOutputConverter.cxx
index 05e7d63..84a433c 100644
--- a/Source/cmOutputConverter.cxx
+++ b/Source/cmOutputConverter.cxx
@@ -18,6 +18,25 @@ cmOutputConverter::cmOutputConverter(cmState::Snapshot 
snapshot)
   assert(this-&g

[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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-131-g23d732f

[Stephen Kelly]

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

The branch, next has been updated
   via  23d732fa83e7e0ae07aad810e1867238900a51f0 (commit)
   via  8f612e2aa4496e3ef88ee80c2ed33e7ba4d6ea64 (commit)
   via  f6a0ca3e63547e728d2eea19803d24ed9825d467 (commit)
   via  d27726cf694036fe22622ce93736a9d0f9896fd6 (commit)
   via  1a973ccfd069fb9300d2a6078cf8cf3f25c3b5a2 (commit)
   via  6334f0e256eb8c89660f41ac9eee68035b78902d (commit)
   via  a2683d3cccd196764d24f9cd6eab4ab64f239819 (commit)
   via  ac67d12cef8f91be025c9b5491d79419970c4684 (commit)
   via  859b341859ac13aa8e872101240fc8c47c766e23 (commit)
   via  f9bde4d2941bf65df78d22dbb713f6f79a7133fa (commit)
   via  0e81268978550f0573845b7e626e47de85d67279 (commit)
   via  4dfbdc908600a3fc98de34b765ba255646b6e648 (commit)
   via  88be3514f5d7a1187880bb89481954b6da26ebb6 (commit)
   via  0fb47ff836af7fbd74998bfeb3067708b9f7db68 (commit)
   via  51bc6bddb91283da25d098492c9cc1b50e3008fc (commit)
   via  8e0c1599a1015cf80c4db35d108509986236b756 (commit)
  from  eea5dbab2e1db3b265035346d52a2b2c6df53a5c (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23d732fa83e7e0ae07aad810e1867238900a51f0
commit 23d732fa83e7e0ae07aad810e1867238900a51f0
Merge: eea5dba 8f612e2
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 12:45:43 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 12:45:43 2016 -0400

Merge topic 'cleanup-Convert' into next

8f612e2a cmLocalGenerator: Simplify ConvertToLinkReference
f6a0ca3e cmOutputConverter: Add a flag for IsUnix
d27726cf Convert: Inline platform-specific methods
1a973ccf Makefiles: Introduce local RelativePath method
6334f0e2 Fortran: Inline conversion to relative path
a2683d3c Fortran: Wrap path convert in a call with a more-suitable name
ac67d12c Makefiles: Hardcode the relative location of the CMakeCache file
859b3418 Convert: Extract method to determine if paths are in directory
f9bde4d2 Convert: Remove asserts which are duplicated in delegate method
0e812689 Convert: Remove early return check
4dfbdc90 Convert: Extract local variables for readability
88be3514 Convert: Extract local variables
0fb47ff8 cmOutputConverter: Remove Convert..ForExisting method (#16138)
51bc6bdd cmOutputConverter: remove unused code
8e0c1599 Xcode: Inline ConvertToRelativePath calls


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8f612e2aa4496e3ef88ee80c2ed33e7ba4d6ea64
commit 8f612e2aa4496e3ef88ee80c2ed33e7ba4d6ea64
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 22:56:32 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 18:45:18 2016 +0200

cmLocalGenerator: Simplify ConvertToLinkReference

Make conversion to output format the caller responsibility, so that the
method only 'converts to a link reference'.

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index 6887a31..14ea1a9 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -75,8 +75,10 @@ void 
cmCommonTargetGenerator::AddModuleDefinitionFlag(std::string& flags)
   // Append the flag and value.  Use ConvertToLinkReference to help
   // vs6's "cl -link" pass it to the linker.
   std::string flag = defFileFlag;
-  flag += (this->LocalGenerator->ConvertToLinkReference(
-this->ModuleDefinitionFile->GetFullPath()));
+  flag += this->LocalGenerator->ConvertToOutputFormat(
+this->LocalGenerator->ConvertToLinkReference(
+  this->ModuleDefinitionFile->GetFullPath()),
+cmOutputConverter::SHELL);
   this->LocalGenerator->AppendFlags(flags, flag);
 }
 
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 1f9e4cf..8fcfb32 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1375,8 +1375,7 @@ std::string cmLocalGenerator::GetTargetFortranFlags(
   return std::string();
 }
 
-std::string cmLocalGenerator::ConvertToLinkReference(std::string const& lib,
- OutputFormat format)
+std::string cmLocalGenerator::ConvertToLinkReference(std::string const& lib)
 {
 #if defined(_WIN32) && !defined(__CYGWIN__)
   // Work-ardound command line parsing limitations in MSVC 6.0
@@ -1393,17 +1392,14 @@ std::string 
cmLocalGenerator::ConvertToLinkReference(std::string const& lib,
 // Append the rest of the path

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-115-geea5dba

[Stephen Kelly]

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

The branch, next has been updated
   via  eea5dbab2e1db3b265035346d52a2b2c6df53a5c (commit)
   via  f5c9da0999ca2edfa337796a1e2da9726198c9bf (commit)
  from  f38d2ed7d391c788baec7e215ee0c1b1d95982d1 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eea5dbab2e1db3b265035346d52a2b2c6df53a5c
commit eea5dbab2e1db3b265035346d52a2b2c6df53a5c
Merge: f38d2ed f5c9da0
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 12:43:32 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 12:43:32 2016 -0400

Merge topic 'codelite-global-setting' into next

f5c9da09 fixup! Codelite: Consume the CMAKE_CODELITE_USE_TARGETS setting 
globally


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f5c9da0999ca2edfa337796a1e2da9726198c9bf
commit f5c9da0999ca2edfa337796a1e2da9726198c9bf
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 18:42:59 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 18:42:59 2016 +0200

fixup! Codelite: Consume the CMAKE_CODELITE_USE_TARGETS setting globally

diff --git a/Help/variable/CMAKE_CODELITE_USE_TARGETS.rst 
b/Help/variable/CMAKE_CODELITE_USE_TARGETS.rst
index 4aede03..96d678f 100644
--- a/Help/variable/CMAKE_CODELITE_USE_TARGETS.rst
+++ b/Help/variable/CMAKE_CODELITE_USE_TARGETS.rst
@@ -3,5 +3,5 @@ CMAKE_CODELITE_USE_TARGETS
 
 Change the way the CodeLite generator creates projectfiles.
 
-If this variable is set to ``ON`` the generator creates projectfiles
-based on targets rather than projects.
+If this variable is set to ``ON`` in the top-level CMakeLists file,
+the generator creates projectfiles based on targets rather than projects.

---

Summary of changes:
 Help/variable/CMAKE_CODELITE_USE_TARGETS.rst |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-113-gf38d2ed

[Stephen Kelly]

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

The branch, next has been updated
   via  f38d2ed7d391c788baec7e215ee0c1b1d95982d1 (commit)
   via  c8c24d8dd52fd3e79f6019f605161024d35082b8 (commit)
   via  f59e87792943904dcb11e16380883e87395d115f (commit)
  from  6a0843d3b684ff3dd57f9e29aaf9947dcc81c253 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f38d2ed7d391c788baec7e215ee0c1b1d95982d1
commit f38d2ed7d391c788baec7e215ee0c1b1d95982d1
Merge: 6a0843d c8c24d8d
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 12:42:08 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 6 12:42:08 2016 -0400

Merge topic 'codelite-global-setting' into next

c8c24d8d Codelite: Consume the CMAKE_CODELITE_USE_TARGETS setting globally
f59e8779 cmGlobalGenerator: Add API to get settings from top-level 
cmMakefile


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8c24d8dd52fd3e79f6019f605161024d35082b8
commit c8c24d8dd52fd3e79f6019f605161024d35082b8
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 18:35:02 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 18:41:07 2016 +0200

Codelite: Consume the CMAKE_CODELITE_USE_TARGETS setting globally

diff --git a/Source/cmExtraCodeLiteGenerator.cxx 
b/Source/cmExtraCodeLiteGenerator.cxx
index 629c5b6..360c852 100644
--- a/Source/cmExtraCodeLiteGenerator.cxx
+++ b/Source/cmExtraCodeLiteGenerator.cxx
@@ -60,7 +60,6 @@ void cmExtraCodeLiteGenerator::Generate()
   // loop projects and locate the root project.
   // and extract the information for creating the worspace
   // root makefile
-  const cmMakefile* rmf = CM_NULLPTR;
   for (std::map<std::string, std::vector<cmLocalGenerator*> >::const_iterator
  it = projectMap.begin();
it != projectMap.end(); ++it) {
@@ -75,7 +74,6 @@ void cmExtraCodeLiteGenerator::Generate()
   workspaceFileName = workspaceOutputDir + "/";
   workspaceFileName += workspaceProjectName + ".workspace";
   this->WorkspacePath = it->second[0]->GetCurrentBinaryDirectory();
-  rmf = it->second[0]->GetMakefile();
   ;
   break;
 }
@@ -89,7 +87,7 @@ void cmExtraCodeLiteGenerator::Generate()
   xml.Attribute("Name", workspaceProjectName);
 
   bool const targetsAreProjects =
-rmf && rmf->IsOn("CMAKE_CODELITE_USE_TARGETS");
+this->GlobalGenerator->GlobalSettingIsOn("CMAKE_CODELITE_USE_TARGETS");
 
   std::vector ProjectNames;
   if (targetsAreProjects) {

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f59e87792943904dcb11e16380883e87395d115f
commit f59e87792943904dcb11e16380883e87395d115f
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Oct 6 18:01:36 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Thu Oct 6 18:41:06 2016 +0200

cmGlobalGenerator: Add API to get settings from top-level cmMakefile

At generate-time, definitions are sometimes read from a nearby cmMakefile,
making the value directory-specific because they are read once per
directory.  Often however, the intention is more
often to create a 'global' setting, such that the user writes for
example:

 set(CMAKE_IMPORT_LIBRARY_SUFFIX something)

once at the top level of their project.

Many of these are also set by internal platform files, such as
CMAKE_EXTRA_LINK_EXTENSIONS.

The set() definitions are not really suitable for 'global' settings
because they can be different for each directory, and code consuming the
settings must assume they are different for each directory, and read it
freshly each time with new allocations.

CMake has other variable types which are global in scope, such as global
properties, and cache variables.  These are less convenient to populate
for users, so establish a convention and API using the value as it is at
the end of the top-level CMakeLists file.

diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index a446862..7132ade 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1007,6 +1007,25 @@ void cmGlobalGenerator::FillExtensionToLanguageMap(const 
std::string& l,
   }
 }
 
+const char* cmGlobalGenerator::GetGlobalSetting(std::string const& name) const
+{
+  assert(!this->Makefiles.empty());
+  return this->Makefiles[0]->GetDefinition(name);
+}
+
+bool cmGlobalGenerator::GlobalSet

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-67-g280cf7a

[Stephen Kelly]

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

The branch, next has been updated
   via  280cf7aa4e2cad24440039f4b7105c5096caf437 (commit)
   via  62e83877c58a9e81d68a30553f54f18a3ed8eb0b (commit)
  from  fae02d5e5126fba375e26ec66f216a1d16f29413 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=280cf7aa4e2cad24440039f4b7105c5096caf437
commit 280cf7aa4e2cad24440039f4b7105c5096caf437
Merge: fae02d5 62e8387
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 18:00:00 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Oct 4 18:00:00 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

62e83877 fixup! cmLinkLineComputer: Extract from cmLocalGenerator


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62e83877c58a9e81d68a30553f54f18a3ed8eb0b
commit 62e83877c58a9e81d68a30553f54f18a3ed8eb0b
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 23:59:44 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Tue Oct 4 23:59:44 2016 +0200

fixup! cmLinkLineComputer: Extract from cmLocalGenerator

diff --git a/Source/cmMSVC60LinkLineComputer.cxx 
b/Source/cmMSVC60LinkLineComputer.cxx
index fbd8022..89432ff 100644
--- a/Source/cmMSVC60LinkLineComputer.cxx
+++ b/Source/cmMSVC60LinkLineComputer.cxx
@@ -3,6 +3,8 @@
 
 #include "cmMSVC60LinkLineComputer.h"
 
+#include "cmSystemTools.h"
+
 cmMSVC60LinkLineComputer::cmMSVC60LinkLineComputer(cmState::Directory stateDir)
   : cmLinkLineComputer(stateDir)
 {

---

Summary of changes:
 Source/cmMSVC60LinkLineComputer.cxx |2 ++
 1 file changed, 2 insertions(+)


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

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-65-gfae02d5

[Stephen Kelly]

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

The branch, next has been updated
   via  fae02d5e5126fba375e26ec66f216a1d16f29413 (commit)
   via  866e4d53ea3a1084e8ba1dd672af83ff3d62c697 (commit)
  from  74adf4e543d506a44500d0aa9bf1203c2270b217 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fae02d5e5126fba375e26ec66f216a1d16f29413
commit fae02d5e5126fba375e26ec66f216a1d16f29413
Merge: 74adf4e 866e4d5
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 17:10:02 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Oct 4 17:10:02 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

866e4d53 fixup! cmLinkLineComputer: Extract from cmLocalGenerator


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=866e4d53ea3a1084e8ba1dd672af83ff3d62c697
commit 866e4d53ea3a1084e8ba1dd672af83ff3d62c697
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 23:08:51 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Tue Oct 4 23:09:30 2016 +0200

fixup! cmLinkLineComputer: Extract from cmLocalGenerator

diff --git a/Source/cmMakefileExecutableTargetGenerator.cxx 
b/Source/cmMakefileExecutableTargetGenerator.cxx
index 8bc7ddf..9ee3933 100644
--- a/Source/cmMakefileExecutableTargetGenerator.cxx
+++ b/Source/cmMakefileExecutableTargetGenerator.cxx
@@ -212,16 +212,9 @@ void 
cmMakefileExecutableTargetGenerator::WriteExecutableRule(bool relink)
 linkFlags, this->GeneratorTarget->GetProperty(linkFlagsConfig));
 
   {
-CM_AUTO_PTR linkLineComputer;
-
-if (this->Makefile->IsOn("MSVC60")) {
-  linkLineComputer.reset(
-this->GlobalGenerator->CreateMSVC60LinkLineComputer(
-  this->LocalGenerator->GetStateSnapshot().GetDirectory()));
-} else {
-  linkLineComputer.reset(this->GlobalGenerator->CreateLinkLineComputer(
+CM_AUTO_PTR linkLineComputer(
+  this->CreateLinkLineComputer(
 this->LocalGenerator->GetStateSnapshot().GetDirectory()));
-}
 
 this->AddModuleDefinitionFlag(linkLineComputer.get(), linkFlags);
   }
diff --git a/Source/cmMakefileLibraryTargetGenerator.cxx 
b/Source/cmMakefileLibraryTargetGenerator.cxx
index f6f4a00..b12e779 100644
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@ -8,7 +8,6 @@
 #include "cmLinkLineComputer.h"
 #include "cmLocalGenerator.h"
 #include "cmLocalUnixMakefileGenerator3.h"
-#include "cmMSVC60LinkLineComputer.h"
 #include "cmMakefile.h"
 #include "cmOSXBundleGenerator.h"
 #include "cmOutputConverter.h"
@@ -162,15 +161,9 @@ void 
cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules(bool relink)
   this->LocalGenerator->AddConfigVariableFlags(
 extraFlags, "CMAKE_SHARED_LINKER_FLAGS", this->ConfigName);
 
-  CM_AUTO_PTR linkLineComputer;
-
-  if (this->Makefile->IsOn("MSVC60")) {
-linkLineComputer.reset(this->GlobalGenerator->CreateMSVC60LinkLineComputer(
-  this->LocalGenerator->GetStateSnapshot().GetDirectory()));
-  } else {
-linkLineComputer.reset(this->GlobalGenerator->CreateLinkLineComputer(
+  CM_AUTO_PTR linkLineComputer(
+this->CreateLinkLineComputer(
   this->LocalGenerator->GetStateSnapshot().GetDirectory()));
-  }
 
   this->AddModuleDefinitionFlag(linkLineComputer.get(), extraFlags);
 
@@ -198,15 +191,9 @@ void 
cmMakefileLibraryTargetGenerator::WriteModuleLibraryRules(bool relink)
   this->LocalGenerator->AddConfigVariableFlags(
 extraFlags, "CMAKE_MODULE_LINKER_FLAGS", this->ConfigName);
 
-  CM_AUTO_PTR linkLineComputer;
-
-  if (this->Makefile->IsOn("MSVC60")) {
-linkLineComputer.reset(this->GlobalGenerator->CreateMSVC60LinkLineComputer(
-  this->LocalGenerator->GetStateSnapshot().GetDirectory()));
-  } else {
-linkLineComputer.reset(this->GlobalGenerator->CreateLinkLineComputer(
+  CM_AUTO_PTR linkLineComputer(
+this->CreateLinkLineComputer(
   this->LocalGenerator->GetStateSnapshot().GetDirectory()));
-  }
 
   this->AddModuleDefinitionFlag(linkLineComputer.get(), extraFlags);
 
diff --git a/Source/cmMakefileTargetGenerator.cxx 
b/Source/cmMakefileTargetGenerator.cxx
index d6c496f..95f883e 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -1580,6 +1580,15 @@ std::string 
cmMakefileTargetGenerator::Crea

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-63-g74adf4e

[Stephen Kelly]

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

The branch, next has been updated
   via  74adf4e543d506a44500d0aa9bf1203c2270b217 (commit)
   via  dfa27f07b492d1aaa94b32a11b4e24ca73d5e420 (commit)
   via  511ed264e1b2816d519fb45bd1a86f650d35dbed (commit)
   via  6e77e10712d852322e28a9283e7b1385fed01da0 (commit)
   via  e5f9caf1260a17aea799487aa7abb2950d3252ce (commit)
   via  abb1e1d227f3f5e61fa22c57c7f6f0fdca745ace (commit)
   via  ee661eb0e937bbb683f1deb24faf927add5f060a (commit)
   via  ec5115eab84226573a8d6903db68d432c1fe147a (commit)
   via  44aa69e750a730fde6610acecfef09663d42098f (commit)
   via  4bd19454ed652c54d278546992f9c3606e1de966 (commit)
   via  8081600219bc8638dd8ce99e6d25a7f35c0cc8f0 (commit)
   via  fb932b367e1678c3d4395d7af422fa9627666f1a (commit)
   via  608e6fe5f24bc6cbf8f4296994fa3878b49a4557 (commit)
   via  5dcf248bc167a04886fb5388c42d1d11aae61cec (commit)
   via  3288481c22337a8bdd785d0cd8b725d5abc1351d (commit)
   via  c7926fe8890a80bb3e9072e903dcadcf4faac4cf (commit)
   via  a41cf74b1836899ad9e3c80a8013446e849049ed (commit)
   via  41aa789e0b1d498e0a160bc2848c9a16fea9d2b5 (commit)
   via  cc7832e9bcfea870de73911f1017bdef6a9ff956 (commit)
   via  aa1ab4c0c975ca81ca7005e0359573836e930530 (commit)
   via  1704cd340e9851e0041d275be54bb7be21b40288 (commit)
   via  8de218ceaf8bd1c6a122f245228aa885c82985a7 (commit)
   via  986d8c78d428c6d7ac5d3a8e4ada86e65901ad99 (commit)
   via  21b23658deecb8a8ae0b0be1c7dbd53adb694fe2 (commit)
   via  94af779a19c7ed4227a396fd26f1bc22ee26699a (commit)
   via  06455f35cf076326134621cc44a446681e6c90e4 (commit)
   via  ca5ef925eb1ae2a1e63ae1b0762ddbbef19e49a2 (commit)
   via  490b2d6ee5146c7f097ba8a2759bf720d528abce (commit)
  from  1d6b62aa619dd4eba44c77587fc51349b73c9ce5 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74adf4e543d506a44500d0aa9bf1203c2270b217
commit 74adf4e543d506a44500d0aa9bf1203c2270b217
Merge: 1d6b62a dfa27f0
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 16:57:34 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Oct 4 16:57:34 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

dfa27f07 cmLinkLineComputer: Extract from cmLocalGenerator
511ed264 cmLocalGenerator: Inline conversion into link computation
6e77e107 Ninja: Inline code into ConvertToLinkReference
e5f9caf1 Ninja: Add a new accessor method
abb1e1d2 Ninja: Extract a static path conversion method
ee661eb0 Ninja: Inline conversion to relative path
ec5115ea Ninja: Get the binary directory from cmState::Directory
44aa69e7 Ninja: Inline output path conversion
4bd19454 Ninja: Simplify method
80816002 cmLocalGenerator: Simplify ConvertToLinkReference
fb932b36 cmOutputConverter: Add a flag for IsUnix
608e6fe5 Convert: Inline platform-specific methods
5dcf248b Ninja: Extract identical code from condition
3288481c Ninja: Replace array access with local variable
c7926fe8 Ninja: Separate two coupled calls
a41cf74b Makefiles: Introduce local RelativePath method
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfa27f07b492d1aaa94b32a11b4e24ca73d5e420
commit dfa27f07b492d1aaa94b32a11b4e24ca73d5e420
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Tue Oct 4 22:56:34 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Tue Oct 4 22:56:34 2016 +0200

cmLinkLineComputer: Extract from cmLocalGenerator

CMake has several classes which have too many responsibilities.
cmLocalGenerator is one of them.  Start to extract the link line
computation.  Create generator-specific implementations of the interface
to account for generator-specific behavior.

Unfortunately MSVC60 has different behavior to everything else and CMake
still generates makefiles for it.  Isolate it with MSVC60-specific
names.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index ec49481..81108ad 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -300,6 +300,8 @@ set(SRCS
   cmInstallDirectoryGenerator.cxx
   cmLinkedTree.h
   cmLinkItem.h
+  cmLinkLineComputer.cxx
+  cmLinkLineComputer.h
   cmListFileCache.cxx
   cmListFileCache.h
   cmListFileLexer.c
@@ -318,6 +320,8 @@ set(SRCS
   cmMakefileUtilityTargetGenerator.cxx
   cmMessenger.cxx
   cmMessenger.h
+  cmMSVC60LinkLineComputer.cxx
+  cmMSVC60LinkLineComputer.h
   cmOSXBundleGenerator.cxx
   cmOSXBundleGenerator.h
   cmOutputConverte

Re: [CMake] Editing IMPORTED targets

[Stephen Kelly]

Ivan Shapovalov wrote:

> Hello!
> 
> Using find modules to detect dependencies has a nice feature: it is
> then possible to edit the resulting cache entries to link to different
> libraries (or add other libraries along the found ones, for whatever
> purposes), or change directories, or flags, or whatever.
> 
> Using find configs and IMPORTED targets, however, prevents doing this,
> because IMPORTED targets are not stored in CMake cache. This can be a
> significant disadvantage at times.

Can you be more specific?

Why can the user provide better information than the supplier of the 
IMPORTED target?

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

[Cmake-commits] CMake branch, next, updated. v3.6.2-2259-g828f247

[Stephen Kelly]

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

The branch, next has been updated
   via  828f247c9bb36f6e378c773497b6ce0b333839b5 (commit)
   via  3e3ebeab9cc64e236d0c1c6d1de19869291fbcb2 (commit)
  from  98220cb3c9dc8a01db12ecfb224ffbd45052fc7b (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=828f247c9bb36f6e378c773497b6ce0b333839b5
commit 828f247c9bb36f6e378c773497b6ce0b333839b5
Merge: 98220cb 3e3ebea
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Sep 19 16:05:19 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Sep 19 16:05:19 2016 -0400

Merge topic 'cleanup-Convert' into next

3e3ebeab Convert: Simplify switch


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3e3ebeab9cc64e236d0c1c6d1de19869291fbcb2
commit 3e3ebeab9cc64e236d0c1c6d1de19869291fbcb2
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:48:57 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Mon Sep 19 22:04:48 2016 +0200

Convert: Simplify switch

Make it more clear what is happening here.

diff --git a/Source/cmOutputConverter.cxx b/Source/cmOutputConverter.cxx
index cc3ee93f..4f12ae0 100644
--- a/Source/cmOutputConverter.cxx
+++ b/Source/cmOutputConverter.cxx
@@ -53,15 +53,14 @@ std::string cmOutputConverter::ConvertToRelativePath(
 
   switch (relative) {
 case HOME_OUTPUT:
-  result = this->ConvertToRelativePath(
-this->GetState()->GetBinaryDirectory(), source);
+  result = this->GetState()->GetBinaryDirectory();
   break;
 case START_OUTPUT:
-  result = this->ConvertToRelativePath(
-this->StateSnapshot.GetDirectory().GetCurrentBinary(), source);
+  result = this->StateSnapshot.GetDirectory().GetCurrentBinary();
   break;
   }
-  return result;
+
+  return this->ConvertToRelativePath(result, source);
 }
 
 std::string cmOutputConverter::Convert(const std::string& source,

---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.6.2-2257-g98220cb

[Stephen Kelly]

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

The branch, next has been updated
   via  98220cb3c9dc8a01db12ecfb224ffbd45052fc7b (commit)
   via  b5fa39ca3bdbcae327a04d4efb1cbe2477acc413 (commit)
  from  27d1525298d909d3272f287e479ec401d78cf29a (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98220cb3c9dc8a01db12ecfb224ffbd45052fc7b
commit 98220cb3c9dc8a01db12ecfb224ffbd45052fc7b
Merge: 27d1525 b5fa39c
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Sep 19 16:04:32 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Sep 19 16:04:32 2016 -0400

Merge topic 'cleanup-Convert' into next

b5fa39ca Partial revert


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b5fa39ca3bdbcae327a04d4efb1cbe2477acc413
commit b5fa39ca3bdbcae327a04d4efb1cbe2477acc413
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Sep 19 22:03:34 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Mon Sep 19 22:03:41 2016 +0200

Partial revert

Avoid conflicting with other branch.

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index fdf0b0e..6167e2c 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -47,6 +47,13 @@ std::string const& cmCommonTargetGenerator::GetConfigName() 
const
   return this->ConfigName;
 }
 
+std::string cmCommonTargetGenerator::Convert(
+  std::string const& source, cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output)
+{
+  return this->LocalGenerator->Convert(source, relative, output);
+}
+
 const char* cmCommonTargetGenerator::GetFeature(const std::string& feature)
 {
   return this->GeneratorTarget->GetFeature(feature, this->ConfigName);
@@ -197,9 +204,8 @@ std::string cmCommonTargetGenerator::GetManifests()
   std::vector manifests;
   for (std::vector::iterator mi = manifest_srcs.begin();
mi != manifest_srcs.end(); ++mi) {
-manifests.push_back(this->LocalGenerator->ConvertToOutputFormat(
-  this->LocalGenerator->ConvertToRelativePath(
-this->LocalGenerator->GetWorkingDirectory(), (*mi)->GetFullPath()),
+manifests.push_back(this->Convert(
+  (*mi)->GetFullPath(), this->LocalGenerator->GetWorkingDirectory(),
   cmOutputConverter::SHELL));
   }
 
diff --git a/Source/cmCommonTargetGenerator.h b/Source/cmCommonTargetGenerator.h
index 4c52fe5..b433c18 100644
--- a/Source/cmCommonTargetGenerator.h
+++ b/Source/cmCommonTargetGenerator.h
@@ -57,6 +57,10 @@ protected:
   // The windows module definition source file (.def), if any.
   cmSourceFile const* ModuleDefinitionFile;
 
+  std::string Convert(std::string const& source,
+  cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output);
+
   void AppendFortranFormatFlags(std::string& flags,
 cmSourceFile const& source);
 
diff --git a/Source/cmDependsFortran.cxx b/Source/cmDependsFortran.cxx
index ba0617f..d7e2c33 100644
--- a/Source/cmDependsFortran.cxx
+++ b/Source/cmDependsFortran.cxx
@@ -428,16 +428,14 @@ bool cmDependsFortran::WriteDependenciesReal(const char* 
obj,
   std::string modFile = mod_dir;
   modFile += "/";
   modFile += *i;
-  modFile = this->LocalGenerator->ConvertToOutputFormat(
-this->LocalGenerator->ConvertToRelativePath(binDir, modFile),
-cmOutputConverter::SHELL);
+  modFile = this->LocalGenerator->Convert(
+modFile, cmOutputConverter::HOME_OUTPUT, cmOutputConverter::SHELL);
   std::string stampFile = stamp_dir;
   stampFile += "/";
   stampFile += m;
   stampFile += ".mod.stamp";
-  stampFile = this->LocalGenerator->ConvertToOutputFormat(
-this->LocalGenerator->ConvertToRelativePath(binDir, stampFile),
-cmOutputConverter::SHELL);
+  stampFile = this->LocalGenerator->Convert(
+stampFile, cmOutputConverter::HOME_OUTPUT, cmOutputConverter::SHELL);
   makeDepends << "\t$(CMAKE_COMMAND) -E cmake_copy_f90_mod " << modFile
   << " " << stampFile;
   cmMakefile* mf = this->LocalGenerator->GetMakefile();
diff --git a/Source/cmLocalCommonGenerator.cxx 
b/Source/cmLocalCommonGenerator.cxx
index 97323c9..0e79293 100644
--- a/Source/cmLocalCommonGenerator.cxx
+++ b/Source/cmLocalCommonGenerator.cxx
@@ -18,9 +18,8 @@
 
 cl

[Cmake-commits] CMake branch, next, updated. v3.6.2-2253-g253d0ee

[Stephen Kelly]

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

The branch, next has been updated
   via  253d0ee84d3b86d8594bd7b82ed60f5464150295 (commit)
   via  bd17b5db0ea713558c2eb6f17082e0346b40f754 (commit)
   via  74546d2fad1f329d26ea78b8dd79fb7c0983f333 (commit)
   via  9c75197a6a074ca39ef4ac812a0d006097f9595d (commit)
   via  c4cdb97b64167f6413f877b630d2e4affe783fc3 (commit)
   via  6f0b87d59589dc441e6408a4884cb464e361 (commit)
   via  29332ff96a1d237e55e367f4a335b51a095158e7 (commit)
   via  cc72d3dd553f0764ec74d76bd5d181875d9531f5 (commit)
   via  2ea0de3749ed34091ef4e3a6bfcc20a5c46d4575 (commit)
   via  b861903f601cba1b4f2f77c82dd33aedf3ac8f78 (commit)
   via  7c8a64c710f8ba74c0688c2ba3d8276c05811a78 (commit)
   via  fbec0e8a0523909ffac9bdc0a6961724acdf65d6 (commit)
   via  3e1b1556227b87bd7dafd46e65611eafc15c323c (commit)
   via  5e87fe3fa4fa0246c34a98c803f67873cb3d18ce (commit)
   via  a215ad8b1def445b86b457fe85026bfd9395ea1b (commit)
   via  c026b3ab9f409474c207a4e28d982d135e5c182f (commit)
   via  52e967ce80d0e5e56c3c028dcf6b3346d0386907 (commit)
   via  f1d845ae74dd9ba0520b1f97c851e439f1c4df07 (commit)
   via  0a98c74c1ba025957b2a3933d9897750109390bf (commit)
   via  495e26ae57fc8f6a38f77ea0d0984fa2a3abe6c1 (commit)
   via  4f68b2070fb90c50eb677dc74298f30ca13648a6 (commit)
  from  7696577b49c993f43dd779554c6d03eb9f65ae74 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=253d0ee84d3b86d8594bd7b82ed60f5464150295
commit 253d0ee84d3b86d8594bd7b82ed60f5464150295
Merge: 7696577 bd17b5d
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Sep 19 15:48:57 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Sep 19 15:48:57 2016 -0400

Merge topic 'cleanup-Convert' into next

bd17b5db cmOutputConverter: Remove now-obsolete Convert method
74546d2f Convert: Inline uses of START_OUTPUT
9c75197a Convert: Remove HOME_OUTPUT enum value
c4cdb97b Ninja: Update comment variable reference
6f0b87d5 Convert: Move access to BinaryDirectory out of loops
29332ff9 Convert: Inline uses of HOME_OUTPUT
cc72d3dd Common: Use a string instead of enum for WorkingDirectory
2ea0de37 Convert: Simplify switch
b861903f Convert: Remove obsolete MAKERULE enum value
7c8a64c7 Convert: Move access to BinaryDirectory out of loops
fbec0e8a Convert: Inline HOME_OUTPUT MAKERULE conversion
3e1b1556 Convert: Inline MAKERULE conversions
5e87fe3f Convert: Move access to BinaryDirectory out of loops
a215ad8b Convert: Avoid HOME_OUTPUT enum when converting to relative paths
c026b3ab Convert: Move access to CurrentBinaryDirectory out of loops
52e967ce Convert: Avoid START_OUTPUT enum when converting to relative paths
...

diff --cc Source/cmLocalCommonGenerator.cxx
index 2de28b8,97323c9..1e708c8
--- a/Source/cmLocalCommonGenerator.cxx
+++ b/Source/cmLocalCommonGenerator.cxx
@@@ -53,13 -54,11 +54,14 @@@ std::string cmLocalCommonGenerator::Get
}
  
// Add a module output directory flag if necessary.
 -  std::string mod_dir = target->GetFortranModuleDirectory();
 +  std::string mod_dir = target->GetFortranModuleDirectory(
 +this->WorkingDirectory == cmOutputConverter::HOME_OUTPUT
 +  ? this->GetBinaryDirectory()
 +  : this->GetCurrentBinaryDirectory());
if (!mod_dir.empty()) {
- mod_dir =
-   this->Convert(mod_dir, this->WorkingDirectory, 
cmOutputConverter::SHELL);
+ mod_dir = this->ConvertToOutputFormat(
+   this->ConvertToRelativePath(this->WorkingDirectory, mod_dir),
+   cmOutputConverter::SHELL);
} else {
  mod_dir =
this->Makefile->GetSafeDefinition("CMAKE_Fortran_MODDIR_DEFAULT");

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd17b5db0ea713558c2eb6f17082e0346b40f754
commit bd17b5db0ea713558c2eb6f17082e0346b40f754
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 19:01:20 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Mon Sep 19 21:36:15 2016 +0200

cmOutputConverter: Remove now-obsolete Convert method

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index df68280..fdf0b0e 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -47,13 +47,6 @@ std::string const& cmCommonTargetGenerator::GetConfigName() 
const
   return this->ConfigName;
 }
 
-std::string cmCommonTargetGenerator::Convert(
-  std::string const& source, cmOutp

[Cmake-commits] CMake branch, next, updated. v3.6.2-2175-g52d2520

[Stephen Kelly]

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

The branch, next has been updated
   via  52d2520d39abeefe97ce69ff3029f487bf285d53 (commit)
   via  6afd35b98a2316685a071a43d0e56448e7ab9ed5 (commit)
  from  e61400cafdfce42049cbd7c88cf56ddc4217b483 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52d2520d39abeefe97ce69ff3029f487bf285d53
commit 52d2520d39abeefe97ce69ff3029f487bf285d53
Merge: e61400c 6afd35b
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Sep 17 13:49:50 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Sep 17 13:49:50 2016 -0400

Merge topic 'cleanup-Convert' into next

6afd35b9 cmState: remove unused code


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6afd35b98a2316685a071a43d0e56448e7ab9ed5
commit 6afd35b98a2316685a071a43d0e56448e7ab9ed5
Author: Daniel Pfeifer <dan...@pfeifer-mail.de>
AuthorDate: Thu Jun 16 23:15:03 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Sep 17 19:49:21 2016 +0200

cmState: remove unused code

Remove the code that was used by cmOutputConverter exclusively.

diff --git a/Source/cmState.cxx b/Source/cmState.cxx
index 073c239..ffb104b 100644
--- a/Source/cmState.cxx
+++ b/Source/cmState.cxx
@@ -77,8 +77,6 @@ struct cmState::BuildsystemDirectoryStateType
   std::string Location;
   std::string OutputLocation;
 
-  std::vector CurrentSourceDirectoryComponents;
-  std::vector CurrentBinaryDirectoryComponents;
   // The top-most directories for relative path conversion.  Both the
   // source and destination location of a relative path conversion
   // must be underneath one of these directories (both under source or
@@ -591,10 +589,6 @@ void cmState::SetSourceDirectory(std::string const& 
sourceDirectory)
 {
   this->SourceDirectory = sourceDirectory;
   cmSystemTools::ConvertToUnixSlashes(this->SourceDirectory);
-
-  cmSystemTools::SplitPath(
-cmSystemTools::CollapseFullPath(this->SourceDirectory),
-this->SourceDirectoryComponents);
 }
 
 const char* cmState::GetSourceDirectory() const
@@ -602,19 +596,10 @@ const char* cmState::GetSourceDirectory() const
   return this->SourceDirectory.c_str();
 }
 
-std::vector const& cmState::GetSourceDirectoryComponents() const
-{
-  return this->SourceDirectoryComponents;
-}
-
 void cmState::SetBinaryDirectory(std::string const& binaryDirectory)
 {
   this->BinaryDirectory = binaryDirectory;
   cmSystemTools::ConvertToUnixSlashes(this->BinaryDirectory);
-
-  cmSystemTools::SplitPath(
-cmSystemTools::CollapseFullPath(this->BinaryDirectory),
-this->BinaryDirectoryComponents);
 }
 
 void cmState::SetWindowsShell(bool windowsShell)
@@ -692,11 +677,6 @@ const char* cmState::GetBinaryDirectory() const
   return this->BinaryDirectory.c_str();
 }
 
-std::vector const& cmState::GetBinaryDirectoryComponents() const
-{
-  return this->BinaryDirectoryComponents;
-}
-
 void cmState::Directory::ComputeRelativePathTopSource()
 {
   // Relative path conversion inside the source tree is not used to
@@ -978,8 +958,6 @@ void cmState::Directory::SetCurrentSource(std::string 
const& dir)
   cmSystemTools::ConvertToUnixSlashes(loc);
   loc = cmSystemTools::CollapseFullPath(loc);
 
-  cmSystemTools::SplitPath(
-loc, this->DirectoryState->CurrentSourceDirectoryComponents);
   this->ComputeRelativePathTopSource();
 
   this->Snapshot_.SetDefinition("CMAKE_CURRENT_SOURCE_DIR", loc);
@@ -997,8 +975,6 @@ void cmState::Directory::SetCurrentBinary(std::string 
const& dir)
   cmSystemTools::ConvertToUnixSlashes(loc);
   loc = cmSystemTools::CollapseFullPath(loc);
 
-  cmSystemTools::SplitPath(
-loc, this->DirectoryState->CurrentBinaryDirectoryComponents);
   this->ComputeRelativePathTopBinary();
 
   this->Snapshot_.SetDefinition("CMAKE_CURRENT_BINARY_DIR", loc);
@@ -1009,18 +985,6 @@ void cmState::Snapshot::SetListFile(const std::string& 
listfile)
   *this->Position->ExecutionListFile = listfile;
 }
 
-std::vector const&
-cmState::Directory::GetCurrentSourceComponents() const
-{
-  return this->DirectoryState->CurrentSourceDirectoryComponents;
-}
-
-std::vector const&
-cmState::Directory::GetCurrentBinaryComponents() const
-{
-  return this->DirectoryState->CurrentBinaryDirectoryComponents;
-}
-
 const char* cmState::Directory::GetRelativePathTopSource() const
 {
   return this->DirectoryState->RelativePathTopSource.c_str();
diff --git a/Source/cmState.h b/Source/cmState.h
index 9ab4213..0fac42c

[Cmake-commits] CMake branch, next, updated. v3.6.2-2173-ge61400c

[Stephen Kelly]

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

The branch, next has been updated
   via  e61400cafdfce42049cbd7c88cf56ddc4217b483 (commit)
   via  92d14662cd0b5adebe17c3ae0c1662fc9ee5f728 (commit)
  from  229c3f4b30b3cd49d12e2ad74fdf92c7503f0bdc (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e61400cafdfce42049cbd7c88cf56ddc4217b483
commit e61400cafdfce42049cbd7c88cf56ddc4217b483
Merge: 229c3f4 92d1466
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Sep 17 13:48:22 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Sep 17 13:48:22 2016 -0400

Merge topic 'cleanup-Convert' into next

92d14662 Revert most of this branch


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92d14662cd0b5adebe17c3ae0c1662fc9ee5f728
commit 92d14662cd0b5adebe17c3ae0c1662fc9ee5f728
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Sep 17 19:47:03 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Sep 17 19:47:18 2016 +0200

Revert most of this branch

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index fdf0b0e..6167e2c 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -47,6 +47,13 @@ std::string const& cmCommonTargetGenerator::GetConfigName() 
const
   return this->ConfigName;
 }
 
+std::string cmCommonTargetGenerator::Convert(
+  std::string const& source, cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output)
+{
+  return this->LocalGenerator->Convert(source, relative, output);
+}
+
 const char* cmCommonTargetGenerator::GetFeature(const std::string& feature)
 {
   return this->GeneratorTarget->GetFeature(feature, this->ConfigName);
@@ -197,9 +204,8 @@ std::string cmCommonTargetGenerator::GetManifests()
   std::vector manifests;
   for (std::vector::iterator mi = manifest_srcs.begin();
mi != manifest_srcs.end(); ++mi) {
-manifests.push_back(this->LocalGenerator->ConvertToOutputFormat(
-  this->LocalGenerator->ConvertToRelativePath(
-this->LocalGenerator->GetWorkingDirectory(), (*mi)->GetFullPath()),
+manifests.push_back(this->Convert(
+  (*mi)->GetFullPath(), this->LocalGenerator->GetWorkingDirectory(),
   cmOutputConverter::SHELL));
   }
 
diff --git a/Source/cmCommonTargetGenerator.h b/Source/cmCommonTargetGenerator.h
index 4c52fe5..b433c18 100644
--- a/Source/cmCommonTargetGenerator.h
+++ b/Source/cmCommonTargetGenerator.h
@@ -57,6 +57,10 @@ protected:
   // The windows module definition source file (.def), if any.
   cmSourceFile const* ModuleDefinitionFile;
 
+  std::string Convert(std::string const& source,
+  cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output);
+
   void AppendFortranFormatFlags(std::string& flags,
 cmSourceFile const& source);
 
diff --git a/Source/cmDependsC.cxx b/Source/cmDependsC.cxx
index 3296ffc..fbbf42f 100644
--- a/Source/cmDependsC.cxx
+++ b/Source/cmDependsC.cxx
@@ -239,18 +239,19 @@ bool cmDependsC::WriteDependencies(const 
std::set& sources,
   // written by the original local generator for this directory
   // convert the dependencies to paths relative to the home output
   // directory.  We must do the same here.
-  std::string binDir = this->LocalGenerator->GetBinaryDirectory();
-  std::string obj_i = this->LocalGenerator->ConvertToRelativePath(binDir, obj);
-  std::string obj_m = cmSystemTools::ConvertToOutputPath(obj_i.c_str());
+  std::string obj_i = this->LocalGenerator->ConvertToRelativePath(
+obj, cmOutputConverter::HOME_OUTPUT);
+  std::string obj_m = this->LocalGenerator->ConvertToOutputFormat(
+obj_i, cmOutputConverter::MAKERULE);
   internalDepends << obj_i << std::endl;
 
   for (std::set::const_iterator i = dependencies.begin();
i != dependencies.end(); ++i) {
-makeDepends
-  << obj_m << ": "
-  << cmSystemTools::ConvertToOutputPath(
-   this->LocalGenerator->ConvertToRelativePath(binDir, *i).c_str())
-  << std::endl;
+makeDepends << obj_m << ": "
+<< this->LocalGenerator->Convert(
+ *i, cmOutputConverter::HOME_OUTPUT,
+ cmOutputConverter::MAKERULE)
+<< std::endl;
 internalDepends << " " << *i <<

[Cmake-commits] CMake branch, next, updated. v3.6.2-2168-g4e952da

[Stephen Kelly]

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

The branch, next has been updated
   via  4e952dabb663c8c65844d608d76f7bb7c691ab00 (commit)
   via  d4f89562594107111e197d4022546ec2c033fe4f (commit)
  from  fe8976265416da8333cd7497d8d41db177b23769 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e952dabb663c8c65844d608d76f7bb7c691ab00
commit 4e952dabb663c8c65844d608d76f7bb7c691ab00
Merge: fe89762 d4f8956
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Sep 17 06:15:31 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Sep 17 06:15:31 2016 -0400

Merge topic 'predictable-add_custom_command-output' into next

d4f89562 fixup! Make the add_custom_command output more predictable


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4f89562594107111e197d4022546ec2c033fe4f
commit d4f89562594107111e197d4022546ec2c033fe4f
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Sep 17 12:15:11 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Sep 17 12:15:11 2016 +0200

fixup! Make the add_custom_command output more predictable

diff --git a/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt 
b/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt
index b643b57..cd542d8 100644
--- a/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt
+++ b/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt
@@ -1,7 +1,7 @@
 CMake Error at AppendNotOutput.cmake:1 \(add_custom_command\):
   add_custom_command given APPEND option with output
 
-  ".*RunCMake/add_custom_command/AppendNotOutput-build/out"
+  .*RunCMake/add_custom_command/AppendNotOutput-build/out.*
 
   which is not already a custom command output.
 Call Stack \(most recent call first\):

---

Summary of changes:
 Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, next, updated. v3.6.2-2166-gfe89762

[Stephen Kelly]

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

The branch, next has been updated
   via  fe8976265416da8333cd7497d8d41db177b23769 (commit)
   via  18d4ce24bba376cddd0f0430de906814535b9069 (commit)
  from  cade5c78ff25278826bc1690084230a04994a6e6 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe8976265416da8333cd7497d8d41db177b23769
commit fe8976265416da8333cd7497d8d41db177b23769
Merge: cade5c7 18d4ce2
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Sep 17 04:55:12 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Sep 17 04:55:12 2016 -0400

Merge topic 'predictable-add_custom_command-output' into next

18d4ce24 Make the add_custom_command output more predictable


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18d4ce24bba376cddd0f0430de906814535b9069
commit 18d4ce24bba376cddd0f0430de906814535b9069
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Sep 8 01:20:35 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Sep 17 10:22:24 2016 +0200

Make the add_custom_command output more predictable

I otherwise get:

   Expected stderr to match:

expect-err> CMake Error at AppendNotOutput.cmake:1 
\(add_custom_command\):
expect-err>   add_custom_command given APPEND option with output.*
expect-err>   which is not already a custom command output.
expect-err> Call Stack \(most recent call first\):
expect-err>   CMakeLists.txt:3 \(include\)

   Actual stderr:

actual-err> CMake Error at AppendNotOutput.cmake:1 (add_custom_command):
actual-err>   add_custom_command given APPEND option with output
actual-err>   "/home/stephen/dev/src/cmake/with
actual-err> 
space/Tests/RunCMake/add_custom_command/AppendNotOutput-build/out" which is
actual-err>   not already a custom command output.
actual-err> Call Stack (most recent call first):
actual-err>   CMakeLists.txt:3 (include)

Using a specific line for paths is a style already used elsewhere for
the same reason, such as CMP0041 output.

diff --git a/Source/cmAddCustomCommandCommand.cxx 
b/Source/cmAddCustomCommandCommand.cxx
index 2c4a4ca..2e28498 100644
--- a/Source/cmAddCustomCommandCommand.cxx
+++ b/Source/cmAddCustomCommandCommand.cxx
@@ -263,8 +263,8 @@ bool cmAddCustomCommandCommand::InitialPass(
 
 // No command for this output exists.
 std::ostringstream e;
-e << "given APPEND option with output \"" << output[0]
-  << "\" which is not already a custom command output.";
+e << "given APPEND option with output\n\"" << output[0]
+  << "\"\nwhich is not already a custom command output.";
 this->SetError(e.str());
 return false;
   }
diff --git a/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt 
b/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt
index 96d0972..b643b57 100644
--- a/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt
+++ b/Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt
@@ -1,5 +1,8 @@
 CMake Error at AppendNotOutput.cmake:1 \(add_custom_command\):
-  add_custom_command given APPEND option with output.*
+  add_custom_command given APPEND option with output
+
+  ".*RunCMake/add_custom_command/AppendNotOutput-build/out"
+
   which is not already a custom command output.
 Call Stack \(most recent call first\):
   CMakeLists.txt:3 \(include\)

---

Summary of changes:
 Source/cmAddCustomCommandCommand.cxx |4 ++--
 Tests/RunCMake/add_custom_command/AppendNotOutput-stderr.txt |5 -
 2 files changed, 6 insertions(+), 3 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.6.2-2164-gcade5c7

[Stephen Kelly]

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

The branch, next has been updated
   via  cade5c78ff25278826bc1690084230a04994a6e6 (commit)
   via  5683e63cca186ef87e4601616be013421a8aad54 (commit)
   via  daf862ae62ad9c11e6352a02068922b42acf2919 (commit)
   via  2ad43682e3f665a59e54746d039a7577b976ca6f (commit)
   via  95ac2339588d0d16f21327c16b098f4c54b5d67b (commit)
   via  bcab65ad983297e1455f43ea9e06f38170e9bb75 (commit)
   via  aab066a87b18d6ca2be47fbd5c2a6b8dd8e287a9 (commit)
   via  ca466374c54031b22018519868d70c9e917df8d1 (commit)
   via  0e9c972fc2cc3d4338890a5e4528bfd7a8b22fc1 (commit)
   via  ce2c74c4783f0de4493268c27b3aecd5ddecb135 (commit)
   via  6f1f8f6299a8f7e05e839573b5f1ae4ce1ad1ea2 (commit)
   via  8e1d9db85bd462c8226550f4bea988ff6b220ac5 (commit)
   via  c282b12f815a95135c2347f022263efcdea1544b (commit)
   via  257265241a791b96a219133d0eba22b9e2b71468 (commit)
   via  8f4b0756bd6bd8e5a1a6055af373972abf66de54 (commit)
   via  b25b70e36e2620b4e8480af62fb7d77babff59a4 (commit)
   via  2fe53afb2ca99257143cb89e633b7a4fe84265cb (commit)
   via  1b855d76829ea3633eea0ec608e5cbabf18c06ff (commit)
   via  983421d8048c44f33704dba4b1302eeadd600463 (commit)
   via  94a51b0185fde6210056cd3b3b5526bb5e0ed830 (commit)
   via  5d3f0e12ed94c4048ef24025f1674692474b7602 (commit)
   via  3d87bd9725341f76ba95f6063b177021dd84a583 (commit)
   via  11ad1af8a35a744413b405c5c86e1dbdab38c430 (commit)
   via  8d47a20f131147d4cf38e63df0c382ec5844a833 (commit)
   via  149af87b86362449a99301860af5aac1a3b4b20c (commit)
  from  a1d30dcccfa79e3f79ab13c88749a8d0f04f14aa (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cade5c78ff25278826bc1690084230a04994a6e6
commit cade5c78ff25278826bc1690084230a04994a6e6
Merge: a1d30dc 5683e63
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Sep 17 04:50:52 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Sep 17 04:50:52 2016 -0400

Merge topic 'cleanup-Convert' into next

5683e63c cmOutputConverter: Remove now-obsolete Convert method
daf862ae Convert: Inline uses of START_OUTPUT
2ad43682 Convert: Remove HOME_OUTPUT enum value
95ac2339 Ninja: Update comment variable reference
bcab65ad Convert: Move access to BinaryDirectory out of loops
aab066a8 Convert: Inline uses of HOME_OUTPUT
ca466374 Common: Use a string instead of enum for WorkingDirectory
0e9c972f Convert: Simplify switch
ce2c74c4 Convert: Remove obsolete MAKERULE enum value
6f1f8f62 Convert: Move access to BinaryDirectory out of loops
8e1d9db8 Convert: Inline HOME_OUTPUT MAKERULE conversion
c282b12f Convert: Inline MAKERULE conversions
25726524 Convert: Move access to BinaryDirectory out of loops
8f4b0756 Convert: Avoid HOME_OUTPUT enum when converting to relative paths
b25b70e3 Convert: Move access to CurrentBinaryDirectory out of loops
2fe53afb Convert: Avoid START_OUTPUT enum when converting to relative paths
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5683e63cca186ef87e4601616be013421a8aad54
commit 5683e63cca186ef87e4601616be013421a8aad54
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 19:01:20 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Sep 17 10:32:48 2016 +0200

cmOutputConverter: Remove now-obsolete Convert method

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index df68280..fdf0b0e 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -47,13 +47,6 @@ std::string const& cmCommonTargetGenerator::GetConfigName() 
const
   return this->ConfigName;
 }
 
-std::string cmCommonTargetGenerator::Convert(
-  std::string const& source, cmOutputConverter::RelativeRoot relative,
-  cmOutputConverter::OutputFormat output)
-{
-  return this->LocalGenerator->Convert(source, relative, output);
-}
-
 const char* cmCommonTargetGenerator::GetFeature(const std::string& feature)
 {
   return this->GeneratorTarget->GetFeature(feature, this->ConfigName);
diff --git a/Source/cmCommonTargetGenerator.h b/Source/cmCommonTargetGenerator.h
index b433c18..4c52fe5 100644
--- a/Source/cmCommonTargetGenerator.h
+++ b/Source/cmCommonTargetGenerator.h
@@ -57,10 +57,6 @@ protected:
   // The windows module definition source file (.def), if any.
   cmSourceFile const* ModuleDefinitionFile;
 
-  std::string Convert(std::string const& sou

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

Re: [CMake] User-overriding IMPORTED targets (overlaying libraries, ...)

[Stephen Kelly]

Ivan Shapovalov wrote:

> Of course, I can always edit the FooConfig.cmake file manually, but I'd
> better avoid patching anything (installing new files or running any
> cmake commands is OK).
> 
> Is there any nice way to solve this?

After 

 find_package(Foo CONFIG)

do

 set_property(TARGET Foo::Foo PROPERTY LOCATION "foo_overlay.so")

Apply whatever platform-specific conditions, suffix and prefix are 
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

Re: [CMake] set_directory_properties ADDITIONAL_MAKE_CLEAN_FILES globbing pattern?

[Stephen Kelly]

Steve Lorimer wrote:

> Is this just not possible?


Indeed - this is not possible.

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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1571-g0dd8dc6

[Stephen Kelly]

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

The branch, next has been updated
   via  0dd8dc67bc08d52744d501bdbedd077d2a1641a9 (commit)
   via  9cc5a4dd1f6d764830c7da33fa0c735124b6cd80 (commit)
   via  d71230b33fea484a758726f12dc98bed95b5336c (commit)
   via  f4028af43e062cb4b01e743236fd3efc3d0ff47d (commit)
   via  e5d8ff5cf57be72c60911b6e2bf5e47dd8ad4c04 (commit)
  from  32389a10550df33224522978f5b9d6794c628d55 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0dd8dc67bc08d52744d501bdbedd077d2a1641a9
commit 0dd8dc67bc08d52744d501bdbedd077d2a1641a9
Merge: 32389a1 9cc5a4d
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:41:31 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:41:31 2016 -0400

Merge topic 'cleanup-Convert' into next

9cc5a4dd Convert: Make variables a bit more clear
d71230b3 Convert: Remove UNCHANGED enum value
f4028af4 Convert: Remove 'FULL' conversion
e5d8ff5c Convert: Replace Convert(FULL) with equivalent


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cc5a4dd1f6d764830c7da33fa0c735124b6cd80
commit 9cc5a4dd1f6d764830c7da33fa0c735124b6cd80
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:58 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:41:18 2016 +0200

Convert: Make variables a bit more clear

diff --git a/Source/cmOutputConverter.cxx b/Source/cmOutputConverter.cxx
index f056a1b..630da42 100644
--- a/Source/cmOutputConverter.cxx
+++ b/Source/cmOutputConverter.cxx
@@ -49,26 +49,26 @@ std::string cmOutputConverter::ConvertToOutputForExisting(
 std::string cmOutputConverter::ConvertToRelativePath(
   const std::string& source, RelativeRoot relative) const
 {
-  std::string result = source;
+  std::string result;
 
   switch (relative) {
 case HOME:
   result = this->ConvertToRelativePath(
-this->GetState()->GetSourceDirectoryComponents(), result);
+this->GetState()->GetSourceDirectoryComponents(), source);
   break;
 case START:
   result = this->ConvertToRelativePath(
 this->StateSnapshot.GetDirectory().GetCurrentSourceComponents(),
-result);
+source);
   break;
 case HOME_OUTPUT:
   result = this->ConvertToRelativePath(
-this->GetState()->GetBinaryDirectoryComponents(), result);
+this->GetState()->GetBinaryDirectoryComponents(), source);
   break;
 case START_OUTPUT:
   result = this->ConvertToRelativePath(
 this->StateSnapshot.GetDirectory().GetCurrentBinaryComponents(),
-result);
+source);
   break;
   }
   return result;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d71230b33fea484a758726f12dc98bed95b5336c
commit d71230b33fea484a758726f12dc98bed95b5336c
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:57 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:41:17 2016 +0200

Convert: Remove UNCHANGED enum value

It is no longer used.

diff --git a/Source/cmCommonTargetGenerator.h b/Source/cmCommonTargetGenerator.h
index d3f9d64..b433c18 100644
--- a/Source/cmCommonTargetGenerator.h
+++ b/Source/cmCommonTargetGenerator.h
@@ -57,9 +57,9 @@ protected:
   // The windows module definition source file (.def), if any.
   cmSourceFile const* ModuleDefinitionFile;
 
-  std::string Convert(
-std::string const& source, cmOutputConverter::RelativeRoot relative,
-cmOutputConverter::OutputFormat output = cmOutputConverter::UNCHANGED);
+  std::string Convert(std::string const& source,
+  cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output);
 
   void AppendFortranFormatFlags(std::string& flags,
 cmSourceFile const& source);
diff --git a/Source/cmOutputConverter.h b/Source/cmOutputConverter.h
index c2403db..9af9659 100644
--- a/Source/cmOutputConverter.h
+++ b/Source/cmOutputConverter.h
@@ -45,7 +45,6 @@ public:
   };
   enum OutputFormat
   {
-UNCHANGED,
 MAKERULE,
 SHELL,
 WATCOMQUOTE,
@@ -54,7 +53,7 @@ public:
   std::string ConvertToOutputFormat(const std::string& source,
 OutputFormat output) const;
   std::string Convert(const std::string& remote, RelativeRoot local,
-  OutputFormat output = UNCHANGED) const;
+  OutputFormat output) cons

[Cmake-commits] CMake branch, next, updated. v3.6.1-1566-g32389a1

[Stephen Kelly]

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

The branch, next has been updated
   via  32389a10550df33224522978f5b9d6794c628d55 (commit)
   via  9040d96d3dad86d081f76f957e9dfc54b7379406 (commit)
  from  799348a2d38e6237561168184fcab801262ffe3a (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=32389a10550df33224522978f5b9d6794c628d55
commit 32389a10550df33224522978f5b9d6794c628d55
Merge: 799348a 9040d96
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:41:09 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:41:09 2016 -0400

Merge topic 'cleanup-Convert' into next

9040d96d format code


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9040d96d3dad86d081f76f957e9dfc54b7379406
commit 9040d96d3dad86d081f76f957e9dfc54b7379406
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 15:40:44 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:40:47 2016 +0200

format code

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index 660483e..7fa35b8 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -665,14 +665,16 @@ void cmLocalUnixMakefileGenerator3::WriteMakeVariables(
   makefileStream
 << "# The top-level source directory on which CMake was run.\n"
 << "CMAKE_SOURCE_DIR = "
-<< 
this->ConvertToOutputFormat(cmSystemTools::CollapseFullPath(this->GetSourceDirectory()),
+<< this->ConvertToOutputFormat(
+  cmSystemTools::CollapseFullPath(this->GetSourceDirectory()),
  cmOutputConverter::SHELL)
 << "\n"
 << "\n";
   makefileStream
 << "# The top-level build directory on which CMake was run.\n"
 << "CMAKE_BINARY_DIR = "
-<< 
this->ConvertToOutputFormat(cmSystemTools::CollapseFullPath(this->GetBinaryDirectory()),
+<< this->ConvertToOutputFormat(
+  cmSystemTools::CollapseFullPath(this->GetBinaryDirectory()),
  cmOutputConverter::SHELL)
 << "\n"
 << "\n";

---

Summary of changes:
 Source/cmLocalUnixMakefileGenerator3.cxx |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1564-g799348a

[Stephen Kelly]

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

The branch, next has been updated
   via  799348a2d38e6237561168184fcab801262ffe3a (commit)
   via  0bfbf20d0abf33e79f29b30989681b93905b71bb (commit)
   via  e638beafc895732f2e1ebb91bd6f5c8ea7989f28 (commit)
   via  8770a8e095d9c6a8da636054bdf0ac72f3659e42 (commit)
   via  25cb07603b4381a857f39189bd96e3dfec9bef20 (commit)
   via  ef50bcbd7b73dab0bd20ec0b9ae72aab01511bc6 (commit)
   via  effa38cd6f4ef4b71e04733002871c492bc203e5 (commit)
   via  d34a12ad76c1566ecc4fe02ed25670b0d679540f (commit)
   via  1e3dba183f2b00b25ef9a8ce3b02b8ee3f0fc256 (commit)
   via  fa8df52d0e03b45cb8a46f2c6e9647cee33fd60a (commit)
   via  0a47e1d9ac4ffac21874daae332422e125e3aa41 (commit)
   via  1bf869716b00f925b6a315737d8c5553b2d04a26 (commit)
   via  8be68b73457470bf886b9d633142c8d3e91f1d80 (commit)
   via  d7bc7c89771a582fb390d2f8c922515acddaa2b5 (commit)
   via  5761b1dd875d857991a0827e65b7128b73d7f8f7 (commit)
   via  16dad45d29f6fc8a84c2ff5ae2ca7c098b532c9c (commit)
   via  e80e6644bb7f4eaf681390b5071a01856d6545d4 (commit)
   via  ab07619914e3857c213d733c8c46a1a439a85ed1 (commit)
   via  85997982e51177c966c691dcd660b133b74f6229 (commit)
  from  e0cb8675975b1ca4d3576c1f0847ff9a6bad1b1e (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=799348a2d38e6237561168184fcab801262ffe3a
commit 799348a2d38e6237561168184fcab801262ffe3a
Merge: e0cb867 0bfbf20
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:28:12 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:28:12 2016 -0400

Merge topic 'cleanup-Convert' into next

0bfbf20d Convert: Make variables a bit more clear
e638beaf Convert: Remove UNCHANGED enum value
8770a8e0 Convert: Remove 'FULL' conversion
25cb0760 Convert: Replace Convert(FULL) with equivalent
ef50bcbd Ninja: Replace ternary with if()
effa38cd Convert: Replace trivial conversion with new method
d34a12ad Convert: Replace UNCHANGED conversions with new API call
1e3dba18 Convert: Extract ConvertToRelativePath from Convert()
fa8df52d Convert: Replace FULL conversions with equivalent
0a47e1d9 VS: Replace FULL/UNCHANGED conversion with equivalent
1bf86971 Convert: Remove NONE conversion
8be68b73 Convert: Replace uses of Convert(NONE)
d7bc7c89 VS: Replace variable with an if()
5761b1dd Makefiles: Replace ternaries with if()s
16dad45d Makefiles: Inline MakeLauncher into only caller
e80e6644 Makefiles: Simplify MakeLauncher return value
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0bfbf20d0abf33e79f29b30989681b93905b71bb
commit 0bfbf20d0abf33e79f29b30989681b93905b71bb
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:58 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:26:38 2016 +0200

Convert: Make variables a bit more clear

diff --git a/Source/cmOutputConverter.cxx b/Source/cmOutputConverter.cxx
index f056a1b..630da42 100644
--- a/Source/cmOutputConverter.cxx
+++ b/Source/cmOutputConverter.cxx
@@ -49,26 +49,26 @@ std::string cmOutputConverter::ConvertToOutputForExisting(
 std::string cmOutputConverter::ConvertToRelativePath(
   const std::string& source, RelativeRoot relative) const
 {
-  std::string result = source;
+  std::string result;
 
   switch (relative) {
 case HOME:
   result = this->ConvertToRelativePath(
-this->GetState()->GetSourceDirectoryComponents(), result);
+this->GetState()->GetSourceDirectoryComponents(), source);
   break;
 case START:
   result = this->ConvertToRelativePath(
 this->StateSnapshot.GetDirectory().GetCurrentSourceComponents(),
-result);
+source);
   break;
 case HOME_OUTPUT:
   result = this->ConvertToRelativePath(
-this->GetState()->GetBinaryDirectoryComponents(), result);
+this->GetState()->GetBinaryDirectoryComponents(), source);
   break;
 case START_OUTPUT:
   result = this->ConvertToRelativePath(
 this->StateSnapshot.GetDirectory().GetCurrentBinaryComponents(),
-result);
+source);
   break;
   }
   return result;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e638beafc895732f2e1ebb91bd6f5c8ea7989f28
commit e638beafc895732f2e1ebb91bd6f5c8ea7989f28
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:57 2016 +0200
Commit: Stephen Kelly <steve...@gmail.

[Cmake-commits] CMake branch, next, updated. v3.6.1-1545-ge0cb867

[Stephen Kelly]

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

The branch, next has been updated
   via  e0cb8675975b1ca4d3576c1f0847ff9a6bad1b1e (commit)
   via  638f907bc6f61935714d688df20611fc65385c27 (commit)
  from  11a80af5b291997c173df0451fddfa3aaa4f4752 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e0cb8675975b1ca4d3576c1f0847ff9a6bad1b1e
commit e0cb8675975b1ca4d3576c1f0847ff9a6bad1b1e
Merge: 11a80af 638f907
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:17:11 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:17:11 2016 -0400

Merge topic 'cleanup-Convert' into next

638f907b Makefiles: Replace method with Wacom specific API


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=638f907bc6f61935714d688df20611fc65385c27
commit 638f907bc6f61935714d688df20611fc65385c27
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:53 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:16:50 2016 +0200

Makefiles: Replace method with Wacom specific API

The existing method uses RelativeRoot NONE and FULL values.  In
principle, those should be segregated interfaces.  Mixing
NONE and FULL into the RelativeRoot enum is a case of

 http://thedailywtf.com/articles/What_Is_Truth_0x3f_

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index f2ef5c8..2ef9a39 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -592,8 +592,8 @@ void cmLocalUnixMakefileGenerator3::WriteMakeRule(
   }
 }
 
-std::string cmLocalUnixMakefileGenerator3::ConvertShellCommand(
-  std::string const& cmd, cmOutputConverter::RelativeRoot root)
+std::string cmLocalUnixMakefileGenerator3::MaybeConvertWacomShellCommand(
+  std::string const& cmd)
 {
   if (this->IsWatcomWMake() && cmSystemTools::FileIsFullPath(cmd.c_str()) &&
   cmd.find_first_of("( )") != cmd.npos) {
@@ -606,7 +606,7 @@ std::string 
cmLocalUnixMakefileGenerator3::ConvertShellCommand(
cmOutputConverter::SHELL);
 }
   }
-  return this->Convert(cmd, root, cmOutputConverter::SHELL);
+  return std::string();
 }
 
 void cmLocalUnixMakefileGenerator3::WriteMakeVariables(
@@ -638,8 +638,13 @@ void cmLocalUnixMakefileGenerator3::WriteMakeVariables(
 #endif
   }
 
-  std::string cmakeShellCommand = this->ConvertShellCommand(
-cmSystemTools::GetCMakeCommand(), cmOutputConverter::FULL);
+  std::string cmakeShellCommand =
+this->MaybeConvertWacomShellCommand(cmSystemTools::GetCMakeCommand());
+  if (cmakeShellCommand.empty()) {
+cmakeShellCommand =
+  this->Convert(cmSystemTools::GetCMakeCommand(), cmOutputConverter::FULL,
+cmOutputConverter::SHELL);
+  }
 
   /* clang-format off */
   makefileStream
@@ -975,7 +980,12 @@ void cmLocalUnixMakefileGenerator3::AppendCustomCommand(
   std::string launcher = this->MakeLauncher(
 ccg, target, workingDir.empty() ? cmOutputConverter::START_OUTPUT
 : cmOutputConverter::NONE);
-  cmd = launcher + this->ConvertShellCommand(cmd, cmOutputConverter::NONE);
+  std::string shellCommand = this->MaybeConvertWacomShellCommand(cmd);
+  if (shellCommand.empty()) {
+shellCommand = this->Convert(cmd, cmOutputConverter::NONE,
+ cmOutputConverter::SHELL);
+  }
+  cmd = launcher + shellCommand;
 
   ccg.AppendArguments(c, cmd);
   if (content) {
diff --git a/Source/cmLocalUnixMakefileGenerator3.h 
b/Source/cmLocalUnixMakefileGenerator3.h
index 243cc3d..9541f65 100644
--- a/Source/cmLocalUnixMakefileGenerator3.h
+++ b/Source/cmLocalUnixMakefileGenerator3.h
@@ -250,8 +250,7 @@ protected:
   void CheckMultipleOutputs(bool verbose);
 
 private:
-  std::string ConvertShellCommand(std::string const& cmd,
-  cmOutputConverter::RelativeRoot root);
+  std::string MaybeConvertWacomShellCommand(std::string const& cmd);
   std::string MakeLauncher(cmCustomCommandGenerator const& ccg,
cmGeneratorTarget* target,
cmOutputConverter::RelativeRoot relative);

---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1543-g11a80af

[Stephen Kelly]

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

The branch, next has been updated
   via  11a80af5b291997c173df0451fddfa3aaa4f4752 (commit)
   via  62f19fc531e2d3cc292005bcfaedc341966c01e9 (commit)
  from  a0d49a9213400b3bbb9f2505d09e47c3680a4680 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11a80af5b291997c173df0451fddfa3aaa4f4752
commit 11a80af5b291997c173df0451fddfa3aaa4f4752
Merge: a0d49a9 62f19fc
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:16:39 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:16:39 2016 -0400

Merge topic 'cleanup-Convert' into next

62f19fc5 fixup! Makefiles: Replace method with Wacom specific API


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62f19fc531e2d3cc292005bcfaedc341966c01e9
commit 62f19fc531e2d3cc292005bcfaedc341966c01e9
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 15:16:15 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:16:15 2016 +0200

fixup! Makefiles: Replace method with Wacom specific API

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index 085cc91..2ef9a39 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -982,7 +982,8 @@ void cmLocalUnixMakefileGenerator3::AppendCustomCommand(
 : cmOutputConverter::NONE);
   std::string shellCommand = this->MaybeConvertWacomShellCommand(cmd);
   if (shellCommand.empty()) {
-shellCommand = this->Convert(cmd, cmOutputConverter::NONE, 
cmOutputConverter::SHELL);
+shellCommand = this->Convert(cmd, cmOutputConverter::NONE,
+ cmOutputConverter::SHELL);
   }
   cmd = launcher + shellCommand;
 

---

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


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1541-ga0d49a9

[Stephen Kelly]

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

The branch, next has been updated
   via  a0d49a9213400b3bbb9f2505d09e47c3680a4680 (commit)
   via  8bdd65e82731fc93ad9a9c63658b104c50fca82b (commit)
  from  4812110823f42f84573a23c87459afa91349995f (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a0d49a9213400b3bbb9f2505d09e47c3680a4680
commit a0d49a9213400b3bbb9f2505d09e47c3680a4680
Merge: 4812110 8bdd65e
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:14:41 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:14:41 2016 -0400

Merge topic 'cleanup-Convert' into next

8bdd65e8 Makefiles: Replace method with Wacom specific API


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bdd65e82731fc93ad9a9c63658b104c50fca82b
commit 8bdd65e82731fc93ad9a9c63658b104c50fca82b
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:53 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:14:28 2016 +0200

Makefiles: Replace method with Wacom specific API

The existing method uses RelativeRoot NONE and FULL values.  In
principle, those should be segregated interfaces.  Mixing
NONE and FULL into the RelativeRoot enum is a case of

 http://thedailywtf.com/articles/What_Is_Truth_0x3f_

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index f2ef5c8..085cc91 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -592,8 +592,8 @@ void cmLocalUnixMakefileGenerator3::WriteMakeRule(
   }
 }
 
-std::string cmLocalUnixMakefileGenerator3::ConvertShellCommand(
-  std::string const& cmd, cmOutputConverter::RelativeRoot root)
+std::string cmLocalUnixMakefileGenerator3::MaybeConvertWacomShellCommand(
+  std::string const& cmd)
 {
   if (this->IsWatcomWMake() && cmSystemTools::FileIsFullPath(cmd.c_str()) &&
   cmd.find_first_of("( )") != cmd.npos) {
@@ -606,7 +606,7 @@ std::string 
cmLocalUnixMakefileGenerator3::ConvertShellCommand(
cmOutputConverter::SHELL);
 }
   }
-  return this->Convert(cmd, root, cmOutputConverter::SHELL);
+  return std::string();
 }
 
 void cmLocalUnixMakefileGenerator3::WriteMakeVariables(
@@ -638,8 +638,13 @@ void cmLocalUnixMakefileGenerator3::WriteMakeVariables(
 #endif
   }
 
-  std::string cmakeShellCommand = this->ConvertShellCommand(
-cmSystemTools::GetCMakeCommand(), cmOutputConverter::FULL);
+  std::string cmakeShellCommand =
+this->MaybeConvertWacomShellCommand(cmSystemTools::GetCMakeCommand());
+  if (cmakeShellCommand.empty()) {
+cmakeShellCommand =
+  this->Convert(cmSystemTools::GetCMakeCommand(), cmOutputConverter::FULL,
+cmOutputConverter::SHELL);
+  }
 
   /* clang-format off */
   makefileStream
@@ -975,7 +980,11 @@ void cmLocalUnixMakefileGenerator3::AppendCustomCommand(
   std::string launcher = this->MakeLauncher(
 ccg, target, workingDir.empty() ? cmOutputConverter::START_OUTPUT
 : cmOutputConverter::NONE);
-  cmd = launcher + this->ConvertShellCommand(cmd, cmOutputConverter::NONE);
+  std::string shellCommand = this->MaybeConvertWacomShellCommand(cmd);
+  if (shellCommand.empty()) {
+shellCommand = this->Convert(cmd, cmOutputConverter::NONE, 
cmOutputConverter::SHELL);
+  }
+  cmd = launcher + shellCommand;
 
   ccg.AppendArguments(c, cmd);
   if (content) {
diff --git a/Source/cmLocalUnixMakefileGenerator3.h 
b/Source/cmLocalUnixMakefileGenerator3.h
index 243cc3d..9541f65 100644
--- a/Source/cmLocalUnixMakefileGenerator3.h
+++ b/Source/cmLocalUnixMakefileGenerator3.h
@@ -250,8 +250,7 @@ protected:
   void CheckMultipleOutputs(bool verbose);
 
 private:
-  std::string ConvertShellCommand(std::string const& cmd,
-  cmOutputConverter::RelativeRoot root);
+  std::string MaybeConvertWacomShellCommand(std::string const& cmd);
   std::string MakeLauncher(cmCustomCommandGenerator const& ccg,
cmGeneratorTarget* target,
cmOutputConverter::RelativeRoot relative);

---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1539-g4812110

[Stephen Kelly]

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

The branch, next has been updated
   via  4812110823f42f84573a23c87459afa91349995f (commit)
   via  dc0edf29b65c50d25da84ecca0c48131f5da69c0 (commit)
  from  978941f83ab3e4bd80ac52100a13c68a85bb8ce0 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4812110823f42f84573a23c87459afa91349995f
commit 4812110823f42f84573a23c87459afa91349995f
Merge: 978941f dc0edf2
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:14:16 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:14:16 2016 -0400

Merge topic 'cleanup-Convert' into next

dc0edf29 Fixup commit


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc0edf29b65c50d25da84ecca0c48131f5da69c0
commit dc0edf29b65c50d25da84ecca0c48131f5da69c0
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 15:12:41 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:13:56 2016 +0200

Fixup commit

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index cb82d0a..085cc91 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -982,7 +982,7 @@ void cmLocalUnixMakefileGenerator3::AppendCustomCommand(
 : cmOutputConverter::NONE);
   std::string shellCommand = this->MaybeConvertWacomShellCommand(cmd);
   if (shellCommand.empty()) {
-shellCommand = this->Convert(cmd, cmOutputConverter::NONE);
+shellCommand = this->Convert(cmd, cmOutputConverter::NONE, 
cmOutputConverter::SHELL);
   }
   cmd = launcher + shellCommand;
 

---

Summary of changes:
 Source/cmLocalUnixMakefileGenerator3.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1537-g978941f

[Stephen Kelly]

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

The branch, next has been updated
   via  978941f83ab3e4bd80ac52100a13c68a85bb8ce0 (commit)
   via  99483b9f9828e459e3e7887cea02d82aae887866 (commit)
  from  677090f0749b78f9cc44e33c7a77c6eda977be0f (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=978941f83ab3e4bd80ac52100a13c68a85bb8ce0
commit 978941f83ab3e4bd80ac52100a13c68a85bb8ce0
Merge: 677090f 99483b9
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 09:13:44 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 09:13:44 2016 -0400

Merge topic 'cleanup-Convert' into next

99483b9f Revert "Makefiles: Remove uselss uses of Convert"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99483b9f9828e459e3e7887cea02d82aae887866
commit 99483b9f9828e459e3e7887cea02d82aae887866
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 15:13:29 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 15:13:29 2016 +0200

Revert "Makefiles: Remove uselss uses of Convert"

This reverts commit ad4b7e05980bd53686fd48ba341c954985ad3056.

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index b3d601a..cb82d0a 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -835,7 +835,8 @@ std::string 
cmLocalUnixMakefileGenerator3::GetRelativeTargetDirectory(
 {
   std::string dir = this->HomeRelativeOutputPath;
   dir += this->GetTargetDirectory(target);
-  return dir;
+  return this->Convert(dir, cmOutputConverter::NONE,
+   cmOutputConverter::UNCHANGED);
 }
 
 void cmLocalUnixMakefileGenerator3::AppendFlags(std::string& flags,
@@ -981,7 +982,7 @@ void cmLocalUnixMakefileGenerator3::AppendCustomCommand(
 : cmOutputConverter::NONE);
   std::string shellCommand = this->MaybeConvertWacomShellCommand(cmd);
   if (shellCommand.empty()) {
-shellCommand = cmd;
+shellCommand = this->Convert(cmd, cmOutputConverter::NONE);
   }
   cmd = launcher + shellCommand;
 

---

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


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1535-g677090f

[Stephen Kelly]

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

The branch, next has been updated
   via  677090f0749b78f9cc44e33c7a77c6eda977be0f (commit)
   via  ad4b7e05980bd53686fd48ba341c954985ad3056 (commit)
  from  2b114c41b54c4d14745b2b98c57ccc7c92111f7e (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=677090f0749b78f9cc44e33c7a77c6eda977be0f
commit 677090f0749b78f9cc44e33c7a77c6eda977be0f
Merge: 2b114c4 ad4b7e0
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 08:47:44 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 08:47:44 2016 -0400

Merge topic 'cleanup-Convert' into next

ad4b7e05 Makefiles: Remove uselss uses of Convert


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad4b7e05980bd53686fd48ba341c954985ad3056
commit ad4b7e05980bd53686fd48ba341c954985ad3056
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:53 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 14:47:13 2016 +0200

Makefiles: Remove uselss uses of Convert

Convert with NONE and UNCHANGED is a no-op.

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index cb82d0a..b3d601a 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -835,8 +835,7 @@ std::string 
cmLocalUnixMakefileGenerator3::GetRelativeTargetDirectory(
 {
   std::string dir = this->HomeRelativeOutputPath;
   dir += this->GetTargetDirectory(target);
-  return this->Convert(dir, cmOutputConverter::NONE,
-   cmOutputConverter::UNCHANGED);
+  return dir;
 }
 
 void cmLocalUnixMakefileGenerator3::AppendFlags(std::string& flags,
@@ -982,7 +981,7 @@ void cmLocalUnixMakefileGenerator3::AppendCustomCommand(
 : cmOutputConverter::NONE);
   std::string shellCommand = this->MaybeConvertWacomShellCommand(cmd);
   if (shellCommand.empty()) {
-shellCommand = this->Convert(cmd, cmOutputConverter::NONE);
+shellCommand = cmd;
   }
   cmd = launcher + shellCommand;
 

---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1533-g2b114c4

[Stephen Kelly]

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

The branch, next has been updated
   via  2b114c41b54c4d14745b2b98c57ccc7c92111f7e (commit)
   via  1fc076d1fe196d2112da45a6aced04ca39594401 (commit)
  from  738e3e9d9af191e7f118e182bb3ba3690430e2af (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2b114c41b54c4d14745b2b98c57ccc7c92111f7e
commit 2b114c41b54c4d14745b2b98c57ccc7c92111f7e
Merge: 738e3e9 1fc076d
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 08:46:13 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 08:46:13 2016 -0400

Merge topic 'cleanup-Convert' into next

1fc076d1 Revert part of branch


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1fc076d1fe196d2112da45a6aced04ca39594401
commit 1fc076d1fe196d2112da45a6aced04ca39594401
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 14:45:29 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 14:45:45 2016 +0200

Revert part of branch

diff --git a/Source/cmCommonTargetGenerator.h b/Source/cmCommonTargetGenerator.h
index b433c18..d3f9d64 100644
--- a/Source/cmCommonTargetGenerator.h
+++ b/Source/cmCommonTargetGenerator.h
@@ -57,9 +57,9 @@ protected:
   // The windows module definition source file (.def), if any.
   cmSourceFile const* ModuleDefinitionFile;
 
-  std::string Convert(std::string const& source,
-  cmOutputConverter::RelativeRoot relative,
-  cmOutputConverter::OutputFormat output);
+  std::string Convert(
+std::string const& source, cmOutputConverter::RelativeRoot relative,
+cmOutputConverter::OutputFormat output = cmOutputConverter::UNCHANGED);
 
   void AppendFortranFormatFlags(std::string& flags,
 cmSourceFile const& source);
diff --git a/Source/cmDependsC.cxx b/Source/cmDependsC.cxx
index 928f7ec..18e123e 100644
--- a/Source/cmDependsC.cxx
+++ b/Source/cmDependsC.cxx
@@ -238,8 +238,8 @@ bool cmDependsC::WriteDependencies(const 
std::set& sources,
   // written by the original local generator for this directory
   // convert the dependencies to paths relative to the home output
   // directory.  We must do the same here.
-  std::string obj_i = this->LocalGenerator->ConvertToRelativePath(
-obj, cmOutputConverter::HOME_OUTPUT);
+  std::string obj_i =
+this->LocalGenerator->Convert(obj, cmOutputConverter::HOME_OUTPUT);
   std::string obj_m = this->LocalGenerator->ConvertToOutputFormat(
 obj_i, cmOutputConverter::MAKERULE);
   internalDepends << obj_i << std::endl;
diff --git a/Source/cmDependsFortran.cxx b/Source/cmDependsFortran.cxx
index 8c0acce..c57b558 100644
--- a/Source/cmDependsFortran.cxx
+++ b/Source/cmDependsFortran.cxx
@@ -193,15 +193,15 @@ bool cmDependsFortran::Finalize(std::ostream& makeDepends,
   stamp += ".mod.stamp";
   fcStream << "\n";
   fcStream << "  \""
-   << this->LocalGenerator->ConvertToRelativePath(
+   << this->LocalGenerator->Convert(
 mod_lower, cmOutputConverter::START_OUTPUT)
<< "\"\n";
   fcStream << "  \""
-   << this->LocalGenerator->ConvertToRelativePath(
+   << this->LocalGenerator->Convert(
 mod_upper, cmOutputConverter::START_OUTPUT)
<< "\"\n";
   fcStream << "  \""
-   << this->LocalGenerator->ConvertToRelativePath(
+   << this->LocalGenerator->Convert(
 stamp, cmOutputConverter::START_OUTPUT)
<< "\"\n";
 }
@@ -317,8 +317,8 @@ bool cmDependsFortran::WriteDependenciesReal(const char* 
obj,
   const char* src = info.Source.c_str();
 
   // Write the include dependencies to the output stream.
-  std::string obj_i = this->LocalGenerator->ConvertToRelativePath(
-obj, cmOutputConverter::HOME_OUTPUT);
+  std::string obj_i =
+this->LocalGenerator->Convert(obj, cmOutputConverter::HOME_OUTPUT);
   std::string obj_m = this->LocalGenerator->ConvertToOutputFormat(
 obj_i, cmOutputConverter::MAKERULE);
   internalDepends << obj_i << std::endl;
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx 
b/Source/cmExtraEclipseCDT4Generator.cxx
index 945ee40..e617b08 100644
--- a/Source/cm

[Cmake-commits] CMake branch, next, updated. v3.6.1-1531-g738e3e9

[Stephen Kelly]

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

The branch, next has been updated
   via  738e3e9d9af191e7f118e182bb3ba3690430e2af (commit)
   via  6ad153786f119e994662c2ec05059cdf46d9dbad (commit)
   via  a11a408a6edcb956fe9ba7a141cfbfd8e94078d6 (commit)
   via  bfa30fa10056b0ee07a58b7d09bc87617fbb7cd2 (commit)
   via  12520e0f723916bb803946d6ba6f5f929bba0120 (commit)
   via  f9d90d054510548490d0a7555b186201ae9f1a45 (commit)
   via  f57933cac8dfd8d4c64d970b1991c263154b0a82 (commit)
   via  bed34f1bd81edd04d55a46cf43658b8339aac1de (commit)
   via  861e2da31d76947b8358930c9f43eed0aa15b642 (commit)
   via  bb1985c5408ac6c130c3f94197fcd987b7e7edc2 (commit)
   via  8c020fc541e6a00736c9897f791e1a3ea76ef0d6 (commit)
   via  e3da80d92561e8a5fdc65fb0a5db18e09cf9ef1e (commit)
   via  fe916d26c37622ee0c6198385dcf86ea7fb545dc (commit)
   via  e7c62e41461995c3ad73be65cb7a9f63e77081b9 (commit)
   via  fcb3a56802c4bf8757424375baf3c4fe053aafbd (commit)
   via  9a296bc30b860e3360fbc4b7adaa1113461a1c89 (commit)
   via  e99e08cc167535daf324d81d510ca8f818ce924c (commit)
   via  ca4bddc08179c8c9c1585f1949bbc840869c1d9f (commit)
   via  064724040af65c7edc985877b637560620136565 (commit)
   via  be096139cf7380f89d8aaad3ea283559b27b2614 (commit)
   via  cd351ef2c427284eea0ab494eba5d4f24bc0e050 (commit)
   via  fbd83948675f4b1cb487d59390cfe1689f801fc0 (commit)
   via  c341f4679ad00cb65c7660b474ddabd13d0ef498 (commit)
   via  6960516b6b053816313d2ff5ee4e9375a84829cb (commit)
   via  e0fd2d0446101847dd40cfe4cc451667d04ddcd9 (commit)
   via  ad70a236f4368c21c08bcd4ea4d28425176c4e17 (commit)
   via  e3ca17e13b8d2aecc6d97ac800d65c6c35378a98 (commit)
   via  0bbdbd95c9515a4714ef1d57a17c7271bc4d1774 (commit)
   via  9440d5776bf48778d452e2d3a48d4e93d7b6f7a7 (commit)
  from  61cdf5d4af56e5e5f7d30448828cc7a35a8ae4a7 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=738e3e9d9af191e7f118e182bb3ba3690430e2af
commit 738e3e9d9af191e7f118e182bb3ba3690430e2af
Merge: 61cdf5d 6ad1537
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 07:45:30 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sat Aug 27 07:45:30 2016 -0400

Merge topic 'cleanup-Convert' into next

6ad15378 Convert: Make variables a bit more clear
a11a408a Convert: Remove UNCHANGED enum value
bfa30fa1 Convert: Remove 'FULL' conversion
12520e0f Convert: Replace Convert(FULL) with equivalent
f9d90d05 Ninja: Replace ternary with if()
f57933ca Convert: Replace trivial conversion with new method
bed34f1b Convert: Replace UNCHANGED conversions with new API call
861e2da3 Convert: Extract ConvertToRelativePath from Convert()
bb1985c5 Convert: Replace FULL conversions with equivalent
8c020fc5 VS: Replace FULL/UNCHANGED conversion with equivalent
e3da80d9 Convert: Remove NONE conversion
fe916d26 Convert: Replace uses of Convert(NONE)
e7c62e41 VS: Replace variable with an if()
fcb3a568 Makefiles: Replace ternaries with if()s
9a296bc3 Makefiles: Inline MakeLauncher into only caller
e99e08cc Makefiles: Simplify MakeLauncher return value
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6ad153786f119e994662c2ec05059cdf46d9dbad
commit 6ad153786f119e994662c2ec05059cdf46d9dbad
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Sat Aug 27 13:44:58 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Sat Aug 27 13:44:58 2016 +0200

Convert: Make variables a bit more clear

diff --git a/Source/cmOutputConverter.cxx b/Source/cmOutputConverter.cxx
index f056a1b..630da42 100644
--- a/Source/cmOutputConverter.cxx
+++ b/Source/cmOutputConverter.cxx
@@ -49,26 +49,26 @@ std::string cmOutputConverter::ConvertToOutputForExisting(
 std::string cmOutputConverter::ConvertToRelativePath(
   const std::string& source, RelativeRoot relative) const
 {
-  std::string result = source;
+  std::string result;
 
   switch (relative) {
 case HOME:
   result = this->ConvertToRelativePath(
-this->GetState()->GetSourceDirectoryComponents(), result);
+this->GetState()->GetSourceDirectoryComponents(), source);
   break;
 case START:
   result = this->ConvertToRelativePath(
 this->StateSnapshot.GetDirectory().GetCurrentSourceComponents(),
-result);
+source);
   break;
 case HOME_OUTPUT:
   result = this->ConvertToRelativePath(
-this->GetState()-

[Cmake-commits] CMake branch, next, updated. v3.6.1-1417-gd644883

[Stephen Kelly]

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

The branch, next has been updated
   via  d64488359696c8ad9519daff699ac9f1d93b2b4f (commit)
   via  d0c8e915ef09b5596befa7b7b05e2b1ae189141d (commit)
  from  a03507820e8b11bc65bd678433c173b92b3549f6 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d64488359696c8ad9519daff699ac9f1d93b2b4f
commit d64488359696c8ad9519daff699ac9f1d93b2b4f
Merge: a035078 d0c8e91
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Wed Aug 24 16:11:17 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Aug 24 16:11:17 2016 -0400

Merge topic 'extract-cmMessenger' into next

d0c8e915 fixup! cmMessenger: Extract from cmake class


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0c8e915ef09b5596befa7b7b05e2b1ae189141d
commit d0c8e915ef09b5596befa7b7b05e2b1ae189141d
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Wed Aug 24 22:07:44 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Wed Aug 24 22:07:44 2016 +0200

fixup! cmMessenger: Extract from cmake class

diff --git a/bootstrap b/bootstrap
index 742fa2b..6c6713e 100755
--- a/bootstrap
+++ b/bootstrap
@@ -266,6 +266,7 @@ CMAKE_CXX_SOURCES="\
   cmPropertyDefinition \
   cmPropertyDefinitionMap \
   cmMakefile \
+  cmMessenger \
   cmExportBuildFileGenerator \
   cmExportFileGenerator \
   cmExportInstallFileGenerator \

---

Summary of changes:
 bootstrap |1 +
 1 file changed, 1 insertion(+)


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1411-g873ec69

[Stephen Kelly]

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

The branch, next has been updated
   via  873ec699047784aa9072e8fb471aa597e573d084 (commit)
   via  1c66f23abbcf9c9cef4b72e601893336553bc186 (commit)
   via  29332a3ba6593ebc2406ffda9cbf6c9e3d33a875 (commit)
   via  2d315d2f59e3bbd4544cc33b718750f1f3a6cea5 (commit)
   via  c37d2ef32fff9f9d991ef78905ed2097718489c1 (commit)
   via  850a4ae4abbb5d5a61862bd26bdc1e9ecdb3a6e6 (commit)
   via  db7de303c2a1e35b672016833db4bf85148c98c2 (commit)
  from  075c74e6b33c65d0c63fc35010c211a4caab (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=873ec699047784aa9072e8fb471aa597e573d084
commit 873ec699047784aa9072e8fb471aa597e573d084
Merge: 075c74e 1c66f23
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Wed Aug 24 15:20:09 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Aug 24 15:20:09 2016 -0400

Merge topic 'extract-cmMessenger' into next

1c66f23a Parser: Port away from cmMakefile
29332a3b cmMessenger: Extract from cmake class
2d315d2f cmMakefile: Port nested error logic away from cmExecutionStatus
c37d2ef3 cmMakefile: Simplify IssueMessage implementation
850a4ae4 Parser: Issue messages through cmake, not cmSystemTools
db7de303 Parser: Store the Backtrace for use in issuing messages


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c66f23abbcf9c9cef4b72e601893336553bc186
commit 1c66f23abbcf9c9cef4b72e601893336553bc186
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Thu Jan 28 22:10:28 2016 +0100
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Wed Aug 24 20:37:32 2016 +0200

Parser: Port away from cmMakefile

It is an unneeded dependency.

diff --git a/Source/cmListFileCache.cxx b/Source/cmListFileCache.cxx
index 9204d14..39d9e97 100644
--- a/Source/cmListFileCache.cxx
+++ b/Source/cmListFileCache.cxx
@@ -12,7 +12,7 @@
 #include "cmListFileCache.h"
 
 #include "cmListFileLexer.h"
-#include "cmMakefile.h"
+#include "cmMessenger.h"
 #include "cmOutputConverter.h"
 #include "cmSystemTools.h"
 #include "cmVersion.h"
@@ -21,7 +21,8 @@
 
 struct cmListFileParser
 {
-  cmListFileParser(cmListFile* lf, cmMakefile* mf, const char* filename);
+  cmListFileParser(cmListFile* lf, cmListFileBacktrace lfbt,
+   cmMessenger* messenger, const char* filename);
   ~cmListFileParser();
   void IssueFileOpenError(std::string const& text) const;
   void IssueError(std::string const& text) const;
@@ -30,8 +31,8 @@ struct cmListFileParser
   bool AddArgument(cmListFileLexer_Token* token,
cmListFileArgument::Delimiter delim);
   cmListFile* ListFile;
-  cmMakefile* Makefile;
   cmListFileBacktrace Backtrace;
+  cmMessenger* Messenger;
   const char* FileName;
   cmListFileLexer* Lexer;
   cmListFileFunction Function;
@@ -43,11 +44,12 @@ struct cmListFileParser
   } Separation;
 };
 
-cmListFileParser::cmListFileParser(cmListFile* lf, cmMakefile* mf,
+cmListFileParser::cmListFileParser(cmListFile* lf, cmListFileBacktrace lfbt,
+   cmMessenger* messenger,
const char* filename)
   : ListFile(lf)
-  , Makefile(mf)
-  , Backtrace(mf->GetBacktrace())
+  , Backtrace(lfbt)
+  , Messenger(messenger)
   , FileName(filename)
   , Lexer(cmListFileLexer_New())
 {
@@ -60,7 +62,7 @@ cmListFileParser::~cmListFileParser()
 
 void cmListFileParser::IssueFileOpenError(const std::string& text) const
 {
-  this->Makefile->IssueMessage(cmake::FATAL_ERROR, text);
+  this->Messenger->IssueMessage(cmake::FATAL_ERROR, text, this->Backtrace);
 }
 
 void cmListFileParser::IssueError(const std::string& text) const
@@ -70,8 +72,7 @@ void cmListFileParser::IssueError(const std::string& text) 
const
   lfc.Line = cmListFileLexer_GetCurrentLine(this->Lexer);
   cmListFileBacktrace lfbt = this->Backtrace;
   lfbt = lfbt.Push(lfc);
-  this->Makefile->GetCMakeInstance()->IssueMessage(cmake::FATAL_ERROR, text,
-   lfbt);
+  this->Messenger->IssueMessage(cmake::FATAL_ERROR, text, lfbt);
   cmSystemTools::SetFatalErrorOccured();
 }
 
@@ -129,7 +130,8 @@ bool cmListFileParser::ParseFile()
   return true;
 }
 
-bool cmListFile::ParseFile(const char* filename, cmMakefile* mf)
+bool cmListFile::ParseFile(const char* filename, cmMessenger* messenger,
+   cmListFileBacktrace const& lfbt)
 {
   if (!cmSyste

[Cmake-commits] CMake branch, next, updated. v3.6.1-1313-g41b3c6b

[Stephen Kelly]

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

The branch, next has been updated
   via  41b3c6b77a37839c5bbf93c2f4b2a19de55ab19b (commit)
   via  d10f2d8b29f54388f74beaaf4a56275d881f5b85 (commit)
   via  6a1e4d673a8ecf9aaf3d7335c84d454c40f417f9 (commit)
  from  cdf7e5800504307b820f742fc3944391d6e37292 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41b3c6b77a37839c5bbf93c2f4b2a19de55ab19b
commit 41b3c6b77a37839c5bbf93c2f4b2a19de55ab19b
Merge: cdf7e58 d10f2d8
Author:     Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Aug 22 17:55:49 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Aug 22 17:55:49 2016 -0400

Merge topic 'version-cleanups' into next

d10f2d8b Version: Remove check for existence of CVS repository
6a1e4d67 Version: Use cmakedefine01 for boolean


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d10f2d8b29f54388f74beaaf4a56275d881f5b85
commit d10f2d8b29f54388f74beaaf4a56275d881f5b85
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Mon Aug 22 23:46:01 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Mon Aug 22 23:54:46 2016 +0200

Version: Remove check for existence of CVS repository

diff --git a/Source/CMakeVersionSource.cmake b/Source/CMakeVersionSource.cmake
index bc5975e..4f22ded 100644
--- a/Source/CMakeVersionSource.cmake
+++ b/Source/CMakeVersionSource.cmake
@@ -29,11 +29,4 @@ if(EXISTS ${CMake_SOURCE_DIR}/.git/HEAD)
   endif()
 endif()
   endif()
-elseif(EXISTS ${CMake_SOURCE_DIR}/CVS/Repository)
-  file(READ ${CMake_SOURCE_DIR}/CVS/Repository repo)
-  set(branch "")
-  if("${repo}" MATCHES "\\.git/([^\r\n]*)")
-set(branch "${CMAKE_MATCH_1}")
-  endif()
-  set(CMake_VERSION_SOURCE "cvs${branch}")
 endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a1e4d673a8ecf9aaf3d7335c84d454c40f417f9
commit 6a1e4d673a8ecf9aaf3d7335c84d454c40f417f9
Author: Stephen Kelly <steve...@gmail.com>
AuthorDate: Wed Jul 27 00:07:32 2016 +0200
Commit: Stephen Kelly <steve...@gmail.com>
CommitDate: Mon Aug 22 23:52:14 2016 +0200

Version: Use cmakedefine01 for boolean

The CMake_VERSION_IS_DIRTY CMake variable is not set by
CMakeVersionCompute or its delegate if not building from git, or if the
git executable is not found.

That means that cmVersionConfig.h would be generated to contain an empty
C++ define for CMake_VERSION_IS_DIRTY.

cmake::ReportCapabilities() requires the preprocessor define to have a
value, so use the standard construct for booleans of cmakedefine01.

diff --git a/Source/cmVersionConfig.h.in b/Source/cmVersionConfig.h.in
index 92abfbe..ab3c1af 100644
--- a/Source/cmVersionConfig.h.in
+++ b/Source/cmVersionConfig.h.in
@@ -13,5 +13,5 @@
 #define CMake_VERSION_MINOR @CMake_VERSION_MINOR@
 #define CMake_VERSION_PATCH @CMake_VERSION_PATCH@
 #define CMake_VERSION_SUFFIX "@CMake_VERSION_SUFFIX@"
-#define CMake_VERSION_IS_DIRTY @CMake_VERSION_IS_DIRTY@
+#cmakedefine01 CMake_VERSION_IS_DIRTY
 #define CMake_VERSION "@CMake_VERSION@"

---

Summary of changes:
 Source/CMakeVersionSource.cmake |7 ---
 Source/cmVersionConfig.h.in |2 +-
 2 files changed, 1 insertion(+), 8 deletions(-)


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

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

Re: [CMake] Automatic inclusion of import targets found by find_package()?

[Stephen Kelly]

Robert Dailey wrote:

> Is there more automation here that I'm not seeing? Thanks in advance.

Yes, the documentation tells you to include what you need in the config 
file:

 
https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-a-package-configuration-file

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

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