Re: [cmake-developers] GIT push access please
On Sat, Feb 15, 2014 at 22:53:42 +, Dan Cristiu wrote: I'd like to push a couple of changes to the VS11/12 generators. They are currently ignoring non-default CMake platforms, with the exception of WinCE. Found a bug related to this issue: http://public.kitware.com/Bug/view.php?id=14673 Sounds like a nice improvement. Would appreciate if anyone could give me a hand in obtaining developer access. Instructions are on the wiki: http://www.cmake.org/Wiki/CMake/Git/Develop http://www.cmake.org/Wiki/CMake/Git/Account#Git Thanks, --Ben -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi Eike, thanks for reviewing! I've just pushed a new version, which should fix all the issues you mentioned. I'm also setting now Hg_FOUND using FOUND_VAR (this is also recommended in the documentation.) Anything more left to do? The only thing which bothers me is the _VERSION_STRING in FindHg (which is similar to FindGit) and the same variable being called _VERSION in OpenCL, if there is a policy on that, I would like to use the same variable name in both. Right now I was aiming more for consistency with existing packages. Cheers, Matthäus On 15.02.2014 19:33, Rolf Eike Beer wrote: Am Samstag, 15. Februar 2014, 18:54:47 schrieb Stephen Kelly: Rolf Eike Beer wrote: Matthäus G. Chajdas wrote: Hi Eike, all right, then Hg, as it's FindHg, unless there is a naming policy I'm not aware of. I was just confused a bit due to FindGit, which uses GIT_ as the prefix. How do I proceed from here? What should I do next? I think you can reduce FindHg quite a bit. Here are some examples: -do not set Hg_FOUND to anything, FPHSA will do it for you You need to set it explicitly when using FPHSA actually, because it sets uppercase(Hg_FOUND) == HG_FOUND instead by default. I consider that a bug, but the 'fix decision' was to require explicitly specifying the _FOUND variable in order to get a sane value. Well, then the fix is simply to pass FOUND_VAR Hg_FOUND to it, no? Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] DeployQt5/generalizing DeployQt4 for Qt5
Hi, Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4? We use it in our packaging process, and it is one of the last things I need to switch to Qt 5. If not, I was going to take a look at this, and see what I can put together. Thanks, Marcus -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Am Sonntag, 16. Februar 2014, 18:43:01 schrieb Matthäus G. Chajdas: Hi Eike, thanks for reviewing! I've just pushed a new version, which should fix all the issues you mentioned. I'm also setting now Hg_FOUND using FOUND_VAR (this is also recommended in the documentation.) Anything more left to do? The only thing which bothers me is the _VERSION_STRING in FindHg (which is similar to FindGit) and the same variable being called _VERSION in OpenCL, if there is a policy on that, I would like to use the same variable name in both. Right now I was aiming more for consistency with existing packages. There has been a Modules/readme.txt, no idea where it is now in rst. But the preferred nameing ins Hg_VERSION_STRING and OpenCL_VERSION_STRING. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi, couldn't find it in the documentation either :( I've changed it to OPENCL_VERSION_STRING. Should I apply for commit access now? Cheers, Matthäus On 16.02.2014 20:10, Rolf Eike Beer wrote: Am Sonntag, 16. Februar 2014, 18:43:01 schrieb Matthäus G. Chajdas: Hi Eike, thanks for reviewing! I've just pushed a new version, which should fix all the issues you mentioned. I'm also setting now Hg_FOUND using FOUND_VAR (this is also recommended in the documentation.) Anything more left to do? The only thing which bothers me is the _VERSION_STRING in FindHg (which is similar to FindGit) and the same variable being called _VERSION in OpenCL, if there is a policy on that, I would like to use the same variable name in both. Right now I was aiming more for consistency with existing packages. There has been a Modules/readme.txt, no idea where it is now in rst. But the preferred nameing ins Hg_VERSION_STRING and OpenCL_VERSION_STRING. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Am Sonntag, 16. Februar 2014, 20:26:22 schrieb Matthäus G. Chajdas: Hi, couldn't find it in the documentation either :( Help/manual/cmake-developer.7.rst I've changed it to OPENCL_VERSION_STRING. Should be OpenCL_VERSION_STRING: the variables should follow the casing of the module name. Should I apply for commit access now? I will not stop you ;) Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014757]: Reduce output of install step
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14757 == Reported By:Kevin Burge Assigned To: == Project:CMake Issue ID: 14757 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2014-02-16 14:36 EST Last Modified: 2014-02-16 14:36 EST == Summary:Reduce output of install step Description: My install installs thousands of files. This means I see thousands of lines of up to date messages whenever I change a single file. After switching to Ninja on Linux and Windows (which really reduces the amount of output), this really stands out even more as completely unnecessary. I have patched my CMake to not display any Up to date messages. When you build, you don't receive thousands of .cpp.o files being up to date, so why would the install step be special? I've attached my patch for your review. At the very least, it would be nice if this could be made optional (to see all the up-to-date messages). == Issue History Date ModifiedUsername FieldChange == 2014-02-16 14:36 Kevin BurgeNew Issue 2014-02-16 14:36 Kevin BurgeFile Added: cmake-2.8.12.1.patch == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi Eike, thanks again! I've just read the Wiki regarding commit access, and it says I should wait for acceptance on the mailing list before applying for access. This is the first time ever I try to contribute something to CMake, so please bear with me if I'm missing something here. Should I ping someone regarding the modules or wait for another review/acceptance notification? The account setup page specifically says After you have been invited, and that didn't happen yet. Could you shed some light on the normal process? Cheers, Matthäus On 16.02.2014 20:29, Rolf Eike Beer wrote: Am Sonntag, 16. Februar 2014, 20:26:22 schrieb Matthäus G. Chajdas: Hi, couldn't find it in the documentation either :( Help/manual/cmake-developer.7.rst I've changed it to OPENCL_VERSION_STRING. Should be OpenCL_VERSION_STRING: the variables should follow the casing of the module name. Should I apply for commit access now? I will not stop you ;) Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Rolf Eike Beer wrote: Am Sonntag, 16. Februar 2014, 18:43:01 schrieb Matthäus G. Chajdas: Hi Eike, thanks for reviewing! I've just pushed a new version, which should fix all the issues you mentioned. I'm also setting now Hg_FOUND using FOUND_VAR (this is also recommended in the documentation.) Anything more left to do? The only thing which bothers me is the _VERSION_STRING in FindHg (which is similar to FindGit) and the same variable being called _VERSION in OpenCL, if there is a policy on that, I would like to use the same variable name in both. Right now I was aiming more for consistency with existing packages. There has been a Modules/readme.txt, no idea where it is now in rst. But the preferred nameing ins Hg_VERSION_STRING and OpenCL_VERSION_STRING. If the readme file says that, then the readme file is wrong. The canonical way to name it is *_VERSION, not *_VERSION_STRING, as that is how config- file packages work. If the readme file says that, then it should be changed, just like a recommendation was changed in commit 140692d84c. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GIT push access please
Dan Cristiu wrote: Would appreciate if anyone could give me a hand in obtaining developer access. Usually, in cases where there is still design discussion to be done, it is preferred to put a topic on a publically hosted git repo for review instead of pushing to the cmake repo (where it gets final review). Eg my clone is here and I regularly request review of the topics I push there: https://gitorious.org/~steveire/cmake/steveires-cmake Consider doing that before waiting for push access. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] DeployQt5/generalizing DeployQt4 for Qt5
Marcus D. Hanwell wrote: Hi, Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4? We use it in our packaging process, and it is one of the last things I need to switch to Qt 5. If not, I was going to take a look at this, and see what I can put together. I've never used DeployQt4 or BundleUtilities, and I don't know much about Mac (which BundleUtilities seems to strongly relate to somehow), so I don't know what is needed from a DeployQt5, which is why I haven't written such a thing yet. It seems like something that should be versioned with and shipped with Qt 5. The intersection of people who know a lot/enough about CMake, packages, and DeployQt4, and Qt 5 is a small set. Please help me with these questions: * What is so special about Qt deployment that it needs special handling in CMake? Why is there no (to pick some random examples) DeployLibLZMA, DeployMPEG, DeployVTK etc? Is it really mostly just the path adjustment stuff and the qt.conf? * How is it used in real-life? How does it intersect to cpack related code? * It was written in a different era of CMake design. How do things like guaranteed use of IMPORTED targets (as Qt 5 ensures), listing of the libraries in INTERFACE_LINK_LIBRARIES, or other modern features of CMake affect the design of DeployQt5? * It seems to have macros related to plugins. When using a statically built Qt, plugins are also relevant in the buildsystem because I need to compile them into my application. Should there be one generic interface in CMake for both this kind of thing and what DeployQt4 is doing? * How should the parameters of the functions be changed? They seem to not use MacroParseArguments. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] DeployQt5/generalizing DeployQt4 for Qt5
On Sun, Feb 16, 2014 at 4:30 PM, Stephen Kelly steve...@gmail.com wrote: Marcus D. Hanwell wrote: Hi, Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4? We use it in our packaging process, and it is one of the last things I need to switch to Qt 5. If not, I was going to take a look at this, and see what I can put together. I've never used DeployQt4 or BundleUtilities, and I don't know much about Mac (which BundleUtilities seems to strongly relate to somehow), so I don't know what is needed from a DeployQt5, which is why I haven't written such a thing yet. It seems like something that should be versioned with and shipped with Qt 5. It was contributed by Mike McQuaid (from KDAB too I think). How are you currently packaging Qt application binaries on Windows, Linux and Mac? The intersection of people who know a lot/enough about CMake, packages, and DeployQt4, and Qt 5 is a small set. Please help me with these questions: Sure, David Cole actually wrote a lot of the packaging code that uses DeployQt4, but I will do my best (he will hopefully correct me if I miss anything). * What is so special about Qt deployment that it needs special handling in CMake? Why is there no (to pick some random examples) DeployLibLZMA, DeployMPEG, DeployVTK etc? Is it really mostly just the path adjustment stuff and the qt.conf? Path adjustment, qt.conf, locations of binaries for release/debug on Windows, Qt is different enough that packaging it needs some simple helpers. Using it with bundle utilities helps to track down all of the necessary dependencies that should be put in a binary package, and avoids attempting to copy system files by going too far. * How is it used in real-life? How does it intersect to cpack related code? The MoleQueue application is perhaps one of the simpler ones where we use it with CPack to create Windows and Mac installers automatically. * It was written in a different era of CMake design. How do things like guaranteed use of IMPORTED targets (as Qt 5 ensures), listing of the libraries in INTERFACE_LINK_LIBRARIES, or other modern features of CMake affect the design of DeployQt5? I think it would still need the same kind of logic to bring in libs that Qt libraries link to, Qt plugins, etc. Knowing which libraries are linked to and their location was always the simpler piece, putting the qt.conf file in the correct location, bringing along the correct Qt plugins, etc, fixing up the paths of the binaries to only reference the bundled Qt are all taken care of for us with this helper. * It seems to have macros related to plugins. When using a statically built Qt, plugins are also relevant in the buildsystem because I need to compile them into my application. Should there be one generic interface in CMake for both this kind of thing and what DeployQt4 is doing? Perhaps, but I am most concerned at this point with the simplest way of porting the remaining part of the build system. I would prefer something like DeployQt4 for simplicity, and not requiring me to bump my Qt dependency to 5.3 for packaging, so in the short term at least I would like to offer similar functionality for Qt 5 in a CMake helper. * How should the parameters of the functions be changed? They seem to not use MacroParseArguments. I have no strong opinions, I am happy to show you how we currently use it. The new Qt 5 CMake support seems really strong, but I was left wondering what I should do for packaging. I would like something that would work with Qt 5.0+, I am not overly tied to DeployQt4 if there is a better way to do this, but hope to get something that is similarly robust once it is up and running in our projects. Thanks, Marcus -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] DeployQt5/generalizing DeployQt4 for Qt5
Marcus D. Hanwell wrote: On Sun, Feb 16, 2014 at 4:30 PM, Stephen Kelly steve...@gmail.com wrote: Marcus D. Hanwell wrote: Hi, Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4? We use it in our packaging process, and it is one of the last things I need to switch to Qt 5. If not, I was going to take a look at this, and see what I can put together. I've never used DeployQt4 or BundleUtilities, and I don't know much about Mac (which BundleUtilities seems to strongly relate to somehow), so I don't know what is needed from a DeployQt5, which is why I haven't written such a thing yet. It seems like something that should be versioned with and shipped with Qt 5. It was contributed by Mike McQuaid (from KDAB too I think). I think he first contributed it before joining KDAB, but now he's at Github: https://github.com/blog/1711-mike-mcquaid-is-a-githubber :) How are you currently packaging Qt application binaries on Windows, Linux and Mac? Generally it's not me personally doing that stuff, but colleagues. Those colleagues don't have 'make it pure' as a goal, are not interested in cmake generally, but just need to get that part done, and need to do something else instead. * It seems to have macros related to plugins. When using a statically built Qt, plugins are also relevant in the buildsystem because I need to compile them into my application. Should there be one generic interface in CMake for both this kind of thing and what DeployQt4 is doing? Perhaps, but I am most concerned at this point with the simplest way of porting the remaining part of the build system. Yes, I understand that. http://cmake.3232098.n2.nabble.com/DeployQt5-cmake-td7585218.html shows that it can be done in a straightforward way. I would prefer something like DeployQt4 for simplicity, and not requiring me to bump my Qt dependency to 5.3 for packaging, so in the short term at least I would like to offer similar functionality for Qt 5 in a CMake helper. It seems that you can do something simple for your current need and get something modern into Qt 5.3, if it makes sense to do something different from 'something simple'. The new Qt 5 CMake support seems really strong, but I was left wondering what I should do for packaging. Yes. The intersection of experience, knowledge, time etc hasn't appeared to add something that makes sense yet. I know that Digia are working on some deployment stuff with unification of concepts particularly with regard to embedded systems deployment in mind. I don't want to create too many diverging concepts there, and would prefer to see what comes out of that, or at least understand the thing fully, before committing to something in the cmake files shipped with Qt 5. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GIT push access please
Thanks Steve, that makes sense. I have my fork as well, was just waiting for someone to clear the waters with regards to reviewing and committing the changes. Anyhow, I realized I want to take it a step further anyway. On Sun, Feb 16, 2014 at 9:15 PM, Stephen Kelly steve...@gmail.com wrote: Dan Cristiu wrote: Would appreciate if anyone could give me a hand in obtaining developer access. Usually, in cases where there is still design discussion to be done, it is preferred to put a topic on a publically hosted git repo for review instead of pushing to the cmake repo (where it gets final review). Eg my clone is here and I regularly request review of the topics I push there: https://gitorious.org/~steveire/cmake/steveires-cmake Consider doing that before waiting for push access. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] VS10-12 generators deserve much more love
Wanted to add a simple change to the VS11 generator to support non-default
toolsets, but after taking another look through the code for the VS10
generator and above, I decided I wasn't happy with the result. It shows
those files have been the result of years of patches, with much of the code
just copied and pasted.
I've decided to review the code in there and clean it to the point where
the duplication is minimal. Is anyone currently involved in a similar task
in this area?
Little has changed in terms of the basic functionality between these
versions of VS. In essence we're talking about changing versions here and
there. So what I propose is to take VS10 as the base and build on top of
it, with small overrides when it comes to version numbers and features.
When MS moves in a completely different direction, we create a new base. So
far they've been consistent.
Another thing I want to do is to implement a proper detection of platforms
toolsets via the MSBuid/Microsoft.cpp folder for VS10-12, leaving the
defaults for cross-compilation. The detection will be done in a loose but
efficient way. We don't want to be too smart when it comes to these things.
The generator must only specify the supported toolset versions (VS12
supports V110, V100_xp plus whatever the base generator supports i.e. V100
and so on). The detection will start looking for these toolset versions
inside PlatformToolset and the rest of the folders inside
Microsoft.cpp/{ToolVersion} maching them and then fishes for platforms. I'm
pretty sure this covers WinCE SDKs as well but I'm planning on leaving the
detection mechanisms that were already implemented. NACL makes itself
available in the same fashion.
What bothers me is the toolset selection. Ideally the toolset the
platform selection should have come together, identifying these critical
parameters from the beginning, problem is the toolset gets set later into
the already initialized generator. I need to investigate why the -T
argument isn't making its way earlier in the whole equation. I don't even
see a field for it in the CMake GUI, in the same dialog where you select
the generator. What am I missing here?
In any case, was there a reason why the toolset is not part of the
generator name? i.e. Visual Studio 11 Win64 V110. Obviously with a
fallback to the VS preferred set. I know this could potentially create a
huge list of generator names in the GUI.
Also, it's not enough to set the toolset and platform. Less critical are
additional settings which must be part of the project file, otherwise you
end up with defaults or worse. A simple define-like variable can be made
available and set in the generator (e.g.
CMAKE_VS_PLATFORM_OPTIONS=key1=value1;key2=value2 = key1value1/key1
key2value2/key2 that gets set by the local generator)
With these additions I hope we can have these generators more future proof
and easier to maintain.
Please give me your thoughts.
Thanks,
Dan
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
