Re: [cmake-developers] cmake -E capabilities [v3]
On 08/16/2016 02:39 PM, Tobias Hunger wrote: > Did you make any progress with libuv? I would love to start pushing > the server-mode patches. All the other pieces are in place already! Great. I haven't gotten a chance to import libuv yet. Now that you're ready for it I'll try to raise priority on that a bit. -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] cmake -E capabilities [v3]
Hi Brad! Am 16.08.2016 20:09 schrieb "Brad King" : > > On 08/15/2016 09:56 AM, Tobias Hunger wrote: > > here is a new update of the cmake -E capabilities patch. > > Thanks. Applied with minor revisions and an additional test: > > cmake: Add `cmake -E capabilities` mode > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49ad7f9a Thanks for cleaning up after me! Did you make any progress with libuv? I would love to start pushing the server-mode patches. All the other pieces are in place already! Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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 [v3]
On 08/15/2016 09:56 AM, Tobias Hunger wrote: > here is a new update of the cmake -E capabilities patch. Thanks. Applied with minor revisions and an additional test: cmake: Add `cmake -E capabilities` mode https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49ad7f9a -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] cmake -E capabilities [attempt 2]
Hi Brad, I will add the requested changes ASAP, but I have hardly any internet connectivity at this time, so it might take a while to get the necessary patches in shape and sent. Sorry for that! Best Regards, Tobias On Thu, Aug 4, 2016 at 4:25 PM, Brad King wrote: > On 08/03/2016 09:52 AM, Brad King wrote: >> I've revised Tobias's commits to rename NewFactory to GetFactory and >> explain some rationale in the commit message: >> >> Refactor extra generator registration to use factories >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a354f60c >> >> Report more information about extra generators in generator factories >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd52a225 > [snip] > On 08/02/2016 02:30 PM, Brad King wrote: >> >> Once that tests cleanly I'll merge it to `master` and then we can >> rebase the remaining changes on it. > > The above commits are now in `master`. Please rebase the rest of > the topic. > > Please update Help/manual/cmake.1.rst to document the > `-E capabilities` option. Also please add a case to > Tests/RunCMake/CommandLine/RunCMakeTest.cmake to at least > run `cmake -E capabilities` as a smoke test. > > Is there a JSON convention for documenting schema? We will need > to be able to document the capabilities output format as well as > the protocol formats of cmake server mode. > > 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
Re: [cmake-developers] cmake -E capabilities [attempt 2]
On 08/03/2016 09:52 AM, Brad King wrote: > I've revised Tobias's commits to rename NewFactory to GetFactory and > explain some rationale in the commit message: > > Refactor extra generator registration to use factories > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a354f60c > > Report more information about extra generators in generator factories > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd52a225 [snip] On 08/02/2016 02:30 PM, Brad King wrote: > > Once that tests cleanly I'll merge it to `master` and then we can > rebase the remaining changes on it. The above commits are now in `master`. Please rebase the rest of the topic. Please update Help/manual/cmake.1.rst to document the `-E capabilities` option. Also please add a case to Tests/RunCMake/CommandLine/RunCMakeTest.cmake to at least run `cmake -E capabilities` as a smoke test. Is there a JSON convention for documenting schema? We will need to be able to document the capabilities output format as well as the protocol formats of cmake server mode. 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
Re: [cmake-developers] cmake -E capabilities [attempt 2]
On 08/02/2016 04:48 PM, Stephen Kelly wrote: > 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. I've revised Tobias's commits to rename NewFactory to GetFactory and explain some rationale in the commit message: Refactor extra generator registration to use factories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a354f60c Report more information about extra generators in generator factories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd52a225 I don't think the granularity is too low for these particular changes. The commit only looks large because it essentially updates the syntax used to express a table of information. Perhaps this syntax update and the main logic updates could be separated but IMO it's good enough. -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] cmake -E capabilities [attempt 2]
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]
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 the branch
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]
On 07/29/2016 06:01 AM, Tobias Hunger wrote: > I pushed an update that takes most of the feedback into account. Thanks. I've applied the extra generator refactoring parts first: Refactor extra generator registration to use factories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc44627b Report more information about extra generators in generator factories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=034caa27 Once that tests cleanly I'll merge it to `master` and then we can rebase the remaining changes on it. 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
Re: [cmake-developers] cmake -E capabilities [attempt 2]
Hi Stephen,
thanks for taking the time to do such a thorough review!
I pushed an update that takes most of the feedback into account. Still at:
https://github.com/hunger/CMake/commits/cmake-capabilities
On Wed, Jul 27, 2016 at 1:11 AM, Stephen Kelly wrote:
> 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.
Gone.
> * There are also some methods that should be const
Added const to some of them:-) Hope I caught all.
> * 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.
> * The pretty-print flag should be removed. Aside from being a boolean trap,
> it creates a interface segregation principle violation. See eg
Removed, even though I find it really useful when testing cmake on
mac/windows. I do have all the small helper tools on Linux, but
usually not on windows/Mac.
> * 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?
> That define should not be used in ReportCapabilities.
That define seems necessary to keep the bootstrap test running.
> * Splitting the 'CMake: Refactor ExtraGenerator registration' commit into
> multiple commits would make it more reviewable, and more bisectable in the
> future.
Sorry, this is what you will get from me: I have to start at some
place and meddle through till things work again. I have to back-track
often.
Basically I need to get some functionality implemented completely and
then test that. Only afterwards can I spend time on making the patches
pretty.
If that is not acceptable, then please feel free to do necessary
changes yourself.
> 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.
> 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. At least not in the
cmake codebase.
Best Regards,
Tobias
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-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]
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] cmake -E capabilities [attempt 2]
Did anyone find some time for a review yet? Best regards, Tobias Am 22.07.2016 01:37 schrieb "Tobias Hunger" : > Hello fellow developers, > > https://github.com/hunger/CMake/commits/cmake-capabilities > > has my attempt to get "cmake -E capabilities" merged -- in preparation of > the > server mode. > > Brad already merged a big chunk of the changes, but he wanted to see the > extra > generator registration cleaned up before continuing. That has happened in > the > new push: The first patch adds a cmExternalMakefileProjectGeneratorFactory, > which has all the necessary information so that cmake no longer needs to > create > instances of all extra generators during startup. > > Extra generators can now alias others -- which is used for the KDevelop3 > generator. Maybe we can just remove that? The comments claim the generator > is > for compatibility with cmake 2.2. That would shave a couple of lines of > that > patch... > > The capabilities work on top of that branch is mostly unchanged, but > exposes an > "isAlias" flag. I now suppress all aliases in the output of -E > capabilities as > I think it makes no sense to have new code announce compatibility bridges > (and > the last version already hardcoded KDevelop3 to be suppressed). > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
On 07/11/2016 10:13 AM, Tobias Hunger wrote: > https://github.com/hunger/CMake/commits/cmake-capabilities > > is in a state now that could use another review. Thanks. I've applied the infrastructure update commits after making a few minor fixes and merged to `next` for testing: Make CMake version suffix available to code https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a077b5d Make CMake version dirty state available to code https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af0e1cd4 cmGlobalGeneratorFactory: Use CM_OVERRIDE for all derived classes https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43a68a6d CMake: Report whether generators support platforms https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4db08807 Please rebase the rest on those, at least once they are in `master`. > This now creates extra generators (all of them), which does not seem to effect > run time of cmake -E capabilities by much on Linux. I have not tested this on > Windows/Mac though as I do not have those platforms handy. > > If that is not acceptable, then some string-parsing is going to be necessary. > I'd move that into cmake::GetRegisteredGenerators, where it is more of an > implementation detail than in the code that actually handles the capability > reporting. The extra generator registration currently adds only the name and a pointer to the `New` function as meta-data. One could expand that to provide a whole "extra generator factory" object that has method that calls `New` as well as other meta-data that we need for the capabilities query. 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
Re: [cmake-developers] cmake -E capabilities
On 07/13/2016 04:47 AM, Tobias Hunger wrote: > Ping? This is on my todo list. Sorry I haven't been able to get to it sooner. -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] cmake -E capabilities
Ping? On Mo, 2016-07-11 at 14:13 +, Tobias Hunger wrote: > https://github.com/hunger/CMake/commits/cmake-capabilities > > is in a state now that could use another review. -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
Hello Developers, https://github.com/hunger/CMake/commits/cmake-capabilities is in a state now that could use another review. It addresses all the issues that Stephen brought up, with small patches extending the information reported via GeneratorInfo bit by bit. Only when all that is in place, the new cmake -E capabilities is added. This now creates extra generators (all of them), which does not seem to effect run time of cmake -E capabilities by much on Linux. I have not tested this on Windows/Mac though as I do not have those platforms handy. If that is not acceptable, then some string-parsing is going to be necessary. I'd move that into cmake::GetRegisteredGenerators, where it is more of an implementation detail than in the code that actually handles the capability reporting. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
Hi fellow Developers, I just uploaded a new version of the cmake-capabilities. I would appreciate some input:-) This version still does parsing of the generator names. Stephen rightfully said that is not nice, which I fully agree with. But to avoid doing that I will need to create instances of generators and interact with those. Is that both safe and fast to do? I am a bit afraid that one generator or the other might end up doing some expensive checks on startup or maybe write files somewhere or do similar things I do not expect. Implemented changes include: Version reporting: * Rename "appendix" to "suffix" * Report "dirty" in the version section separately (information available via macro in cmVersionConfig.h) Code: * Do not use auto and range based for loops * Do not use std::unordered_map directly * Sprinkle this-> over the code Generators: * Hide KDevelop3 generator Best Regads, Tobias From: cmake-developers on behalf of Tobias Hunger Sent: Thursday, July 7, 2016 3:51:52 PM To: Stephen Kelly Cc: CMake Developers Subject: Re: [cmake-developers] cmake -E capabilities Hello, On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly , me, Stephen Kelly wrote: >>> 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. I still do not get why this feature exists at all. What is the benefit of having it? Is it just because xcode supports it, so cmake should to? >> 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. Oh, that sounds interesting. I'll need to investigate this:-) Best Regards, Tobias -- Powered by www.kitware.com<http://www.kitware.com> Kitware Inc. - leading edge, high-quality software<http://www.kitware.com/> www.kitware.com Kitware's mission is to create state-of-the-art software products and services in visualization and data processing using advanced quality software methods and ... Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
Hello, On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly , me, Stephen Kelly wrote: >>> 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. I still do not get why this feature exists at all. What is the benefit of having it? Is it just because xcode supports it, so cmake should to? >> 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. Oh, that sounds interesting. I'll need to investigate this:-) Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
Sorry for the late reply... we had a beta release and a new patch level release out this week and I had to fix some bugs in both:-) On Sun, Jul 3, 2016 at 1:30 PM, Stephen Kelly wrote: >> "KDevelop3", > > This generator should probably be removed/hidden by now. It has > confused users of more-recent KDevelop versions. Yes, that should be hidden. I'll add that in the next update. >> 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. Obviously, or I would not propose it:-) The hope is to get feedback from other potential users. But so far no luck on that front:-/ >> 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 think that information would be useful at some point. But it is not needed before a project is opened. >> 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. Oh, sorry. I still find that horrible to read, so I only sprinkle this-> over the code shortly before sending it in to review. > 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). Oh, too bad. > 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. I'll fix that. > 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. Yes, that is ugly. > 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? Doesn't this require me to instanciate the generators? Won't that be potentially expensive? > 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. I'll change that. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
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
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. > 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. > However, I don't think that is an immediate goal, and that information can > be added later easily if a client does need it. I still think the information "this generator can handle multiple configurations in one build directory" is useless to all clients I can think of. Either the clients do not care or they need to know which configurations those are going to be. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
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
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
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] cmake -E capabilities
On Do, 2016-06-30 at 15:00 -0400, Brad King wrote:
> On 06/30/2016 09:51 AM, Tobias Hunger wrote:
> > Compared to the bug report mentioned above the fields "multiconfig" and
> > "recursive" are missing. I could not figure out how to get that
> > information:-/
>
> There is no "recursive" generator, so that does not belong in the example
> anyway. The Makefile generator does not produce recursive makefiles:
>
> https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.
> 3F
Great, one thing less to worry about:-)
> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
> Something similar will have to be added to the generator factory APIs
> so that we can ask for this information without creating a generator.
Sorry for not knowing any better... But does it make sense to provide that
information?
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?
Once I get the project structure I have the information on the generated
configurations -- incl. their names.
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 could also not yet figure out a way to retrieve information on supported
> > platforms and toolsets. At least I did get whether a generator supports
> > toolsets, but nothing similar seems to exist for the platform part.
>
> We don't have any information on supported platforms or toolsets.
> The CMAKE_GENERATOR_PLATFORM and CMAKE_GENERATOR_TOOLSET settings
> take user-specified values and we pass them through to native tools.
> It is up to the user to provide valid values.
Looking at the code I am a bit confused:
All the generators that take a platform seem to get that set via the generator
name. E.g. there are
* "Visual Studio 10 2010",
* "Visual Studio 10 2010 Win64" and
* "Visual Studio 10 2010 IA64"
generators registered.
All these different names trigger a new generator to be created with different
DefaultPlatformName set up (even though the documentation string for the
generators reports the Win64/IA64 part as "[arch]", not platform).
Note that "Win64" gets mapped to a platform name of "x64" and "IA64" gets mapped
to "Itanium".
So far so good...
The cmake command line lets me apparently use "-A platform" to set
cmake::GeneratorPlatform. That will end up in the cache as
"CMAKE_GENERATOR_PLATFORM" (after some validation).
Generators will get that value from the cmMakefiles (where they move into via
the CMakeCache AFAICT). That information will be passed to the generator via the
SetGeneratorPlatform method, which will then override the default platform set
via the generator name.
Why can I specify the platform names in two different ways? Why do the two ways
disagree on the platform name ("Win64" vs. "x64")? Did you rename the concept
from architecture to platform at some point (or why does the documentation use
[arch] and the command line client "-A")? I guess there are interesting
compatibility considerations behind all this:-)
What is the preferred way to set up a Visual studio project nowadays? Should I
filter out the architecture specific generators in favor or using -A on the
command line or the other way around? Or do both cover completely separate use
cases?
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?
So far I only looked into the visual studio generators, so I might have missed
something that blocks such a method in other generators.
Best Regards,
Tobias
--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-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
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.
> * "Visual Studio 10 2010",
> * "Visual Studio 10 2010 Win64" and
> * "Visual Studio 10 2010 IA64"
[snip]
> The cmake command line lets me apparently use "-A platform"
[snip]
> Why can I specify the platform names in two different ways? Why do
> the two ways disagree on the platform name ("Win64" vs. "x64")?
See here:
https://cmake.org/cmake/help/v3.6/generator/Visual%20Studio%2014%202015.html
At one time the generator name was the only way. The names were not
originally chosen to match VS's platform names and were then kept for
compatibility. The -A/CMAKE_GENERATOR_PLATFORM approach was added
more recently to decouple the generator name from the target architecture.
> What is the preferred way to set up a Visual studio project nowadays?
The preferred way is now:
-G "Visual Studio 10 2010" -A x64
Its usage is not widespread because it doesn't make that much difference
for x64 and the feature has only been around for a couple years.
> 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.
> So far I only looked into the visual studio generators, so I might
> have missed something that blocks such a method in other generators.
The Xcode generator supports CMAKE_GENERATOR_TOOLSET but not
CMAKE_GENERATOR_PLATFORM. The Makefile and Ninja generators support
neither because they are expected to be run from an environment that
is already configured for a given toolchain/architecture.
-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] cmake -E capabilities
On Fri, Jul 1, 2016 at 4:21 AM, Tobias Hunger wrote: > On Do, 2016-06-30 at 14:16 -0400, Robert Maynard wrote: >> It might be worthwhile to have the version section to have an explicit >> dirty key instead of having to parse the string key to find that >> information out. > > I'll make that information available in a separate patch and add it. Thanks! > >> Also wouldn't you want server-mode to be an empty dictionary, as in >> the future that would contain information like the wire format >> version, etc. > > Getting the information here would be expensive (I would need to instanciate a > cmServer to get the information) and I do not really see too big a need to add > that information in the first place. Long-term I will just require a cmake > with > server-mode and "serverMode": "false" is enough to tell the user that she > needs > to update her cmake:-) > > The decision of which protocol to choose to talk to the server will be made > later, in a different part of the code. > That is a very reasonable. > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 > B -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
On Do, 2016-06-30 at 14:16 -0400, Robert Maynard wrote: > It might be worthwhile to have the version section to have an explicit > dirty key instead of having to parse the string key to find that > information out. I'll make that information available in a separate patch and add it. > Also wouldn't you want server-mode to be an empty dictionary, as in > the future that would contain information like the wire format > version, etc. Getting the information here would be expensive (I would need to instanciate a cmServer to get the information) and I do not really see too big a need to add that information in the first place. Long-term I will just require a cmake with server-mode and "serverMode": "false" is enough to tell the user that she needs to update her cmake:-) The decision of which protocol to choose to talk to the server will be made later, in a different part of the code. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-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
On 06/30/2016 09:51 AM, Tobias Hunger wrote: > Compared to the bug report mentioned above the fields "multiconfig" and > "recursive" are missing. I could not figure out how to get that information:-/ There is no "recursive" generator, so that does not belong in the example anyway. The Makefile generator does not produce recursive makefiles: https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method. Something similar will have to be added to the generator factory APIs so that we can ask for this information without creating a generator. > I could also not yet figure out a way to retrieve information on supported > platforms and toolsets. At least I did get whether a generator supports > toolsets, but nothing similar seems to exist for the platform part. We don't have any information on supported platforms or toolsets. The CMAKE_GENERATOR_PLATFORM and CMAKE_GENERATOR_TOOLSET settings take user-specified values and we pass them through to native tools. It is up to the user to provide valid values. However, we can at least report whether the platform/toolset options are supported by a given generator. For this one could add APIs to generator factories as mentioned above for multiconfig. -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] cmake -E capabilities
It might be worthwhile to have the version section to have an explicit
dirty key instead of having to parse the string key to find that
information out.
Also wouldn't you want server-mode to be an empty dictionary, as in
the future that would contain information like the wire format
version, etc.
On Thu, Jun 30, 2016 at 9:51 AM, 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.
>
> 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
>
> The output looks like this:
>> cmake -E capabilities --pretty-print
> {
>"generators" : [
> {
> "extraGenerators" : [],
> "name" : "Watcom WMake",
> "toolSetSupport" : false
> },
> {
> "extraGenerators" : [ "CodeBlocks", "CodeLite", "Eclipse CDT4",
> "Kate",
> "Sublime Text 2" ],
> "name" : "Ninja",
> "toolSetSupport" : false
> },
> {
> "extraGenerators" : [
> "CodeBlocks",
> "CodeLite",
> "Eclipse CDT4",
> "KDevelop3",
> "Kate",
> "Sublime Text 2"
> ],
> "name" : "Unix Makefiles",
> "toolSetSupport" : false
> }
>],
>"server-mode" : false,
>"version" : {
> "major" : 3,
> "minor" : 6,
> "patch" : 20160630,
> "string" : "3.6.20160630-g2c759-dirty"
>}
> }
>
> This is running on my Linux machine.
>
> What do you think? What else should we report here?
>
> Compared to the bug report mentioned above the fields "multiconfig" and
> "recursive" are missing. I could not figure out how to get that information:-/
>
> I could also not yet figure out a way to retrieve information on supported
> platforms and toolsets. At least I did get whether a generator supports
> toolsets, but nothing similar seems to exist for the platform part.
>
> Does anyone have an idea how I could retrieve this information?
>
> I would also welcome some code review on the patch. The remaining items on my
> server-mode todo list are all about removing similar information from the
> server-mode commands:-)
>
> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331
> B
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
