Re: [cmake-developers] Developer tasks - Refactoring

[Stephen Kelly]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anyway, back to Convert()...

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

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

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

In the very end:

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

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

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

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

I guess you can see where this is going:

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

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

Re: [cmake-developers] Developer tasks - Refactoring

[Daniel Pfeifer]

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

Here is what I found.

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon-mode

[Brad King]

On 06/06/2016 11:39 AM, Tobias Hunger wrote:
> This is why I started working on making Stephen's code merge-able and more
> robust. I will also volunteer to help maintain this code going forward.

Great, thanks!

Hopefully I will have time to look at this in more detail soon.  For now
here are a few responses.

> So far I copied over the daemon itself from Stephen. On top of that I added 
> some
> nicer request/respond handling code (you get pretty similar messages from
> everything, you can set a cookie in a request, which will be handed back on
> response/error, there is a defined way to report a response or an error
> condition), progress reporting (directly hooked up to cmake), and a couple of
> basic commands to get started (reset, etc.), and some future-proofing by being
> able to support several versions of the daemon protocol.

Good.  I like the use of libuv.  I've been meaning to add the infrastructure
to make libuv available as something we can use in CMake upstream so that we
can port process execution away from KWSys and to libuv.  The daemon mode will
be a great client for libuv too.

> A big chunk of Stephen's work has not even landed in my branch yet. Since 
> cmake
> reformated all the source in the meantime it is a bit tedious to apply patches
> from his tree and I have simply not yet needed the changes as I did not 
> venture
> where he went yet.

See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
how to rebase across the style transition.  If you rebase the original
"cmake-daemon" branch on that then we can rewrite the style to make
cherry-picking later easier.

> At this time I think I will need to duplicate a chunk of code from one of the
> generators to find the flags. Is that really necessary? If so: Which generator
> should I copy the code from?

We should be able to refactor things to share the flags computation.
Methods like

  cmLocalGenerator::GetTargetFlags
  cmLocalGenerator::GetIncludeDirectories

are meant to be used across multiple generators.  Due to historical
evolution in generator design not everything has been refactored to
cleanly share such infrastructure across all generators.  Stephen made
a lot of progress on that front, but there is still a way to go IIRC.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi everybody,

I want the cmake daemon mode Stephen Kelly proposed a while back. In my opinion
this could become a game changer. Unfortunately Stephen told me that he did not
have the resources to push this forward at this time.

This is why I started working on making Stephen's code merge-able and more
robust. I will also volunteer to help maintain this code going forward.

My main interest is getting project structure reported out of cmake. So this is
what I did start out with.

The cool features Stephen demo-ed in his blog

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

are definitely on my wish list though, but I need first class cmake project
support first -- with all the information Qt Creator can currently not get its
hands on.

So I set up a branch over on github and did some hacking:

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



Status:
===

So far I copied over the daemon itself from Stephen. On top of that I added some
nicer request/respond handling code (you get pretty similar messages from
everything, you can set a cookie in a request, which will be handed back on
response/error, there is a defined way to report a response or an error
condition), progress reporting (directly hooked up to cmake), and a couple of
basic commands to get started (reset, etc.), and some future-proofing by being
able to support several versions of the daemon protocol.

This infrastructure part is pretty solid by now, and has documentation and
tests.

On top of that I started to work towards loading a project and extracting the
project structure from it. This part is still pretty much in flux as I learn
where all the bits and pieces of data are stored in cmake.

This part is without proper documentation and tests at this time.

I do not consider this branch merge-worthy yet, but I would appreciate feedback
on the patch set *A LOT*, ranging from coding style issues up to hints about
things I should add to enable more use-cases, or hints on how to get to
information currently missing from the output.

A big chunk of Stephen's work has not even landed in my branch yet. Since cmake
reformated all the source in the meantime it is a bit tedious to apply patches
from his tree and I have simply not yet needed the changes as I did not venture
where he went yet. It also leaves daemon-mode as a rather separate set of
patches that is not changing core cmake components. I also hope this helps with
review at this time.



Run through:
===

Start "cmake -E daemon" (no additional parameters required). This will enable
daemon-mode and allow you to send magic text via stdin to the daemon, who will
respond with magic text on stdout. We will probably want to change that later to
a channel that does not get interleaved with cmake output, but for now it works
well enough and is really easy to test.

A typical session will currently include the following messages sent to
the cmake daemon:

[== CMake MetaMagic ==[
{"protocolVersion":{"major":0,"minor":1},"type":"handshake"}
]== CMake MetaMagic ==]

This needs to be the first thing sent as it establishes the protocol version,
right after the daemon reports the available protocol versions on start-up.

[== CMake MetaMagic ==[
{"type":"setGlobalSettings", "currentGenerator":"Ninja",
"sourceDirectory":"/home/code/src/cmake", "buildDirectory":"/tmp/cmake-build-
test"}
]== CMake MetaMagic ==]

This sets up a new build directory /tmp/cmake-build-test for the sources found
in /home/code/src/cmake, using the Ninja generator. You should be able to leave
out the currentGenerator and the sourceDirectory if the buildDirectory already
exists.

[== CMake MetaMagic ==[
{"type":"configure"}
]== CMake MetaMagic ==]

Configures the project. You can also try:

[== CMake MetaMagic ==[
{"type":"configure", "cacheArguments":["-Dsomething=else"]}
]== CMake MetaMagic ==]

to pass configure arguments along to cmake.

Next step is:

[== CMake MetaMagic ==[
{"type":"generate"}
]== CMake MetaMagic ==]

which will generate the build system in the build directory. This and configure
will produce progress output along the way.

At this point you can query the project structure:

[== CMake MetaMagic ==[
{"type":"project"}
]== CMake MetaMagic ==]

This will dump a lot of output:-) You can trim down on that a bit by limiting
target types, etc.

Additional commands supported at this time:

[== CMake MetaMagic ==[
{"type":"globalSettings"}
]== CMake MetaMagic ==]

which lists the things you can set via "setGlobalSettings".

[== CMake MetaMagic ==[
{"type":"reset"}
]== CMake MetaMagic ==]

which will reset the daemon to its default state.



Todo:
===

* Handle toolsets for generators

* Get CMakeCache via the daemon (after configure?)

* Get build system files from the daemon (after configure?)

* Get missing information on the project:
   * Defines
   * Compiler flags
   * Information on linkage of targets

* Group similar sources to shorten the output

* 

Re: [cmake-developers] FindVulkan.cmake

[Matthäus G . Chajdas]

Thanks a lot! I've pushed a squashed commit which does everything in one
go, and merged it into next.

Cheers,
  Matthäus

Am 06.06.2016 um 17:22 schrieb Brad King:
> On 06/06/2016 11:09 AM, Matthäus G. Chajdas wrote:
>> thanks a lot. Is this make test or is there something special needed to
>> get the ModuleNotices? make test is super-slow, I wonder if there's a
>> faster way to get to the relevant test.
> 
> Just run:
> 
>ctest -R ModuleNotices
> 
> To run the whole test suite in parallel:
> 
>ctest -j 8
> 
> or:
> 
>make test ARGS='-j 8'
> 
> -Brad
> 

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindVulkan.cmake

[Brad King]

On 06/06/2016 11:09 AM, Matthäus G. Chajdas wrote:
> thanks a lot. Is this make test or is there something special needed to
> get the ModuleNotices? make test is super-slow, I wonder if there's a
> faster way to get to the relevant test.

Just run:

   ctest -R ModuleNotices

To run the whole test suite in parallel:

   ctest -j 8

or:

   make test ARGS='-j 8'

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindVulkan.cmake

[Matthäus G . Chajdas]

Hi Brad,

thanks a lot. Is this make test or is there something special needed to
get the ModuleNotices? make test is super-slow, I wonder if there's a
faster way to get to the relevant test.

Cheers,
  Matthäus

Am 06.06.2016 um 15:36 schrieb Brad King:
> On 06/04/2016 02:54 PM, Matthäus G. Chajdas wrote:
>> I've pushed an add-FindVulkan topic branch which adds a module to search
>> for the Vulkan graphics API (https://www.khronos.org/vulkan/).
>>
>> I'm also happy to maintain this going forward.
> 
> Thanks.  Please run the CMake test suite and fix the ModuleNotices
> test failure.  Then squash the topic back together and merge to
> 'next' for testing.
> 
> -Brad
> 

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

[Brad King]

On 06/06/2016 10:11 AM, "Michael Jäntsch" wrote:
> I would like to report a bug which I found in CMake 3.6.0-rc1. However,
> it is also present in release 3.5.2 and probably earlier releases as well.
>  
> Description:
> The generated rule in rules.ninja for linking static libraries contains
> the command for actual linking and an additional command ": $TARGET_FILE".
> This works fine on linux but fails on windows (":" is not a valid command).

I'm not able to see the behavior you describe.  The Ninja generator is
well-tested on Windows.  The code that generates a ":" command is here:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalNinjaGenerator.cxx;hb=v3.6.0-rc1#l291

but is conditioned to generate "cd ." on Windows hosts instead.

Where did you get the CMake binary you're running?

What toolchain are you using to build?

Can you provide a sample CMakeLists.txt file (or source tarball)
that shows the problem?

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Bug in CMake 3.6.0-rc1: Generated Ninja files do not work on Windows

[Michael Jäntsch]

Hi all,

 

I would like to report a bug which I found in CMake 3.6.0-rc1. However, it is also present in release 3.5.2 and probably earlier releases as well.

 

Description:

The generated rule in rules.ninja for linking static libraries contains the command for actual linking and an additional command ": $TARGET_FILE". This works fine on linux but fails on windows (":" is not a valid command). This additional command arises (for c++) from the CMAKE_CXX_ARCHIVE_FINISH variable which is added to the rule in cmNinjaNormalTargetGenerator::ComputeLinkCmd(). I did not find out where the variable is set.

 

But I found a work around which is to set the CMAKE_CXX_ARCHIVE_FINISH variable to empty in my CMakeLists.txt. If I do that everything works fine. A general solution in 3.6.0 would be great.

 

regards

Michael

 

 
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Productbuild CPack generator

[clinton]

On Jun 6, 2016 7:28 AM, Brad King  wrote:
>
> On 06/02/2016 12:03 PM, clin...@elemtech.com wrote: 
> > I have submitted a productbuild generator this morning. 
>
> Clinton, I see you followed up with some fixups to the topic and have 
> now squashed it down.  I've extended the revised topic with release notes: 
>
> Help: Add notes for 'productbuild' topic 
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63e5eb5f 
>
> Is the topic ready for 'master' now? 
Yes, I think it's ready.
Thanks,
Clint

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindVulkan.cmake

[Brad King]

On 06/04/2016 02:54 PM, Matthäus G. Chajdas wrote:
> I've pushed an add-FindVulkan topic branch which adds a module to search
> for the Vulkan graphics API (https://www.khronos.org/vulkan/).
> 
> I'm also happy to maintain this going forward.

Thanks.  Please run the CMake test suite and fix the ModuleNotices
test failure.  Then squash the topic back together and merge to
'next' for testing.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Productbuild CPack generator

[Brad King]

On 06/05/2016 04:20 PM, Roman Wüger wrote:
> Is it in CMake 3.6.x?

No, this is brand new post-3.6 development.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Productbuild CPack generator

[Brad King]

On 06/02/2016 12:03 PM, clin...@elemtech.com wrote:
> I have submitted a productbuild generator this morning.

Clinton, I see you followed up with some fixups to the topic and have
now squashed it down.  I've extended the revised topic with release notes:

 Help: Add notes for 'productbuild' topic
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63e5eb5f

Is the topic ready for 'master' now?

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016136]: cmake --build can not build several targets

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16136 
== 
Reported By:Tobias Hunger
Assigned To:
== 
Project:CMake
Issue ID:   16136
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-06-06 08:29 EDT
Last Modified:  2016-06-06 08:29 EDT
== 
Summary:cmake --build can not build several targets
Description: 
I am using cmake --build in Qt Creator now and got feedback that all but the
last target passed to cmake --build . --target a --target b are ignored.

It would be really convenient to be able to build more than one target in one go
using cmake --build.

Steps to Reproduce: 
1) Generate any cmake project with two targets defined called A and B.
2) try to build both targets at once using cmake --build . --target A --target B
3) Watch as only target B is built.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-06-06 08:29 Tobias Hunger  New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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