Re: [cmake-developers] VS10-12 generators deserve much more love
Dan Cristiu wrote: > 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'm not interested in Visual Studio personally, but from reading the mailing list and bug updates, where there is design discussion about those generators, I think you have the wrong impression there. As you are new here, I guess you have not been aware of those design discussions. The suggestion to put everything in the generator name is the exact opposite direction to where the cmake design is going. You're not likely to have success turning that around just by suggesting it, and without being involved in (or even aware of) previous discussions. Being new, you need to build merit in order to participate in a meritocracy. I recommend reading/searching the mailing list archives or bug tracker before making suggestions or conclusions about the code or design. 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] VS10-12 generators deserve much more love
I am not here to build merit. When myself and others start using find & replace in the files generated by CMake, that should raise some concerns. For people who have sent me private e-mails, I don't understand why you don't express your frustrations on the mailing list. Apparently people here believe everything is nice and dandy. What I wrote in the previous e-mails weren't attempts to influence the community or your design plans. Reason why I wrote such a big e-mail was to make my intentions to contribute known and get some feedback and guidance. Currently CMake offers a generator selection plus a completely separate and hidden toolset setting. This is not natural for Visual Studio. If we want to be even more specific, a VS solution can have a mixture of platforms and toolsets, all defined per project, and they're very tightly coupled. A set of hard-coded platforms, copied from generator to generator, will not cut it for me I'm sorry. If the community and I have different minimum levels of acceptance when it comes to maintenance and flexibility, then I can live with a modified version of CMake in my own repository. Don't think anyone though would be happy with having a separate CMake that works better for Visual Studio. Dan On Mon, Feb 17, 2014 at 8:28 AM, Stephen Kelly wrote: > Dan Cristiu wrote: > > > 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'm not interested in Visual Studio personally, but from reading the > mailing > list and bug updates, where there is design discussion about those > generators, I think you have the wrong impression there. > > As you are new here, I guess you have not been aware of those design > discussions. > > The suggestion to put everything in the generator name is the exact > opposite > direction to where the cmake design is going. You're not likely to have > success turning that around just by suggesting it, and without being > involved in (or even aware of) previous discussions. > > Being new, you need to build merit in order to participate in a > meritocracy. > I recommend reading/searching the mailing list archives or bug tracker > before making suggestions or conclusions about the code or design. > > 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
Re: [cmake-developers] VS10-12 generators deserve much more love
Please note that I already expressed how ReactOS sees the current VS support in CMake: http://public.kitware.com/pipermail/cmake-developers/2013-July/007666.html I welcome and support any effort that allows CMake to generate VS solutions that work as VS users expect them to be. Cheers, Amine. -- 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] VS10-12 generators deserve much more love
Dan Cristiu wrote: > What I wrote in the previous e-mails weren't attempts to influence the > community or your design plans. Reason why I wrote such a big e-mail was > to make my intentions to contribute known and get some feedback and > guidance. Did you get feedback or guidance? I'm curious to know what you think. > > Currently CMake offers a generator selection plus a completely separate > and hidden toolset setting. It is documented in ``cmake --help`` output. If it doesn't have a place in cmake-gui, that is a separate issue of far smaller scope. "hidden" is not accurate. Accuracy helps in discussions like these. > Don't think anyone though would be happy with having a > separate CMake that works better for Visual Studio. Everyone on this list wants a better CMake. You need to catch up with other discussions on the bug tracker and mailing list in order to contribute. 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
[cmake-developers] [CMake 0014758]: Delayed de-duplication of include directories may cause huge memory usage
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14758 == Reported By:Marcel Loose Assigned To: == Project:CMake Issue ID: 14758 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-02-17 07:52 EST Last Modified: 2014-02-17 07:52 EST == Summary:Delayed de-duplication of include directories may cause huge memory usage Description: Since CMake 2.8.8 de-duplication of include directories is postponed to the generation phase. This can cause serious problems if the number of duplicate entries grows large. If I understand things correctly, this redesign was made in order to support generator expressions. Would it be possible to do immediate de-duplication of entries that don't contain a generator expression? Steps to Reproduce: I haven't been able to create an easy to reproduce setup (yet). Any version of CMake >= 2.8.8 will exhibit this behaviour. Additional Information: See the email thread http://cmake.3232098.n2.nabble.com/include-directories-versus-set-directory-properties-PROPERTIES-INCLUDE-DIRECTORIES-td7586636.html This issue is related to http://public.kitware.com/Bug/view.php?id=14094. == Issue History Date ModifiedUsername FieldChange == 2014-02-17 07:52 Marcel Loose New Issue == -- 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 0014759]: add_definitions and -std=c++11
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=14759 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 14759 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2014-02-17 07:55 EST Last Modified: 2014-02-17 07:55 EST == Summary:add_definitions and -std=c++11 Description: I recently discovered a new behavior for add_definitions as explained at: http://stackoverflow.com/questions/10851247/how-to-activate-c-11-in-cmake#16393486 For some reason, cmake seems to cope with something like this: ADD_DEFINITIONS( -std=c++11 # Or -std=c++0x # Other flags ) I doubt this is pure luck, so I would suggest that it either be documented as: 1. Undefined behavior 2. Properly defined behavior, in which case `cmake --help-command add_definitions` should be updated. thanks == Issue History Date ModifiedUsername FieldChange == 2014-02-17 07:55 Mathieu MalaterreNew Issue == -- 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] VS non-default platform support (was: GIT push access please)
On 02/15/2014 05:53 PM, 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. FYI, there is WinRT work going on here: http://www.cmake.org/Bug/view.php?id=13511 -Brad -- 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] VS10-12 generators deserve much more love
On 02/16/2014 08:25 PM, Dan Cristiu wrote: > I've decided to review the code in there and clean it to the point > where the duplication is minimal. I would welcome such an effort. Can you cite some examples of duplication that you have in mind to reduce? > In any case, was there a reason why the toolset is not part of the > generator name? i.e. "Visual Studio 11 Win64 V110". The platform never should have been part of the generator name either but that convention was established long ago. The version of VS and the target platform are orthogonal. So is the toolset, which is why -T is separate. Support to specify the PlatformToolset is pretty new so it has not fully matured yet. It can be set from cmake-gui by using the Add Entry button to add CMAKE_GENERATOR_TOOLSET prior to the first configuration. I would welcome an effort to add a dedicated field in the dialog for it, especially if it could be a drop-down selection of available toolsets. > additional settings which must be part of the project file We have some basic support for that: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#prop_tgt:VS_GLOBAL_variable but it doesn't cover everything. -Brad -- 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] Reduce output of install step
At Brad King's request, I am posting this here. I opened a feature request for reducing the output of the installation step. I don't think it is necessary (or even helpful) to output "Up to date" for targets that are up to date during the install step. There can only be three outcomes to the install step: a) the target is installed, b) the target failed to be installed or updated, or c) the target is up to date. I think it makes the most sense to just log a message for a) and b), not c). If we compare this to the build step, the build step does not notify of targets that are up to date. We recently switched to ninja which is extremely fast. I never noticed how much time I spent waiting for the install MESSAGES to finish scrolling by, until I patched cmake and noticed the difference. When building in emacs, or remotely, this can be a significant amount of data going over the wire (especially for a remote desktop session) for absolutely no benefit. Thanks for the consideration. http://www.cmake.org/Bug/view.php?id=14757 -- 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] Reduce output of install step
Hi Folks, Removing extra outputs is good. Would it make sense for Kevin to push a topic to next ? Should a policy be added to avoid breaking system that relied on the stdout ? Jc On Mon, Feb 17, 2014 at 9:51 AM, Kevin Burge wrote: > At Brad King's request, I am posting this here. > > I opened a feature request for reducing the output of the installation > step. I don't think it is necessary (or even helpful) to output "Up to > date" for targets that are up to date during the install step. There can > only be three outcomes to the install step: a) the target is installed, b) > the target failed to be installed or updated, or c) the target is up to > date. I think it makes the most sense to just log a message for a) and b), > not c). If we compare this to the build step, the build step does not > notify of targets that are up to date. > > We recently switched to ninja which is extremely fast. I never noticed > how much time I spent waiting for the install MESSAGES to finish scrolling > by, until I patched cmake and noticed the difference. When building in > emacs, or remotely, this can be a significant amount of data going over the > wire (especially for a remote desktop session) for absolutely no benefit. > > Thanks for the consideration. > > http://www.cmake.org/Bug/view.php?id=14757 > > > -- > > 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 > -- +1 919 869 8849 -- 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 6:57 PM, Stephen Kelly wrote: > Marcus D. Hanwell wrote: > >> On Sun, Feb 16, 2014 at 4:30 PM, Stephen Kelly >> 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 > I even read that, but didn't put it together in this context ;-) > >> 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. Fair enough, we are really aiming for the simplest way to reliably package on all three platforms and this has been working pretty well. > >>> * 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 missed that in my searches - thanks for pointing it out. > >> 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 would be happy to help here if I can, I want to ensure Qt 5 is at least as simple as Qt 4 was to create packages using CMake. > > 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. > Agreed, I will keep an eye out for this. In the short term is would seem an adaptation of DeployQt4 is reasonable, unless I hear from someone else that they have something way better working already. 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] Reduce output of install step
On 02/17/2014 09:56 AM, Jean-Christophe Fillion-Robin wrote: > Would it make sense for Kevin to push a topic to next? He doesn't need to learn the whole upstream workflow for this. Just a patch would be fine. See CONTRIBUTING.rst. > Should a policy be added to avoid breaking system that > relied on the stdout ? I don't think that is necessary. In the issue tracker entry I proposed making it dependent on the VERBOSE environment variable like some other output already does. -Brad -- 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] Target SOURCES and TARGET_OBJECTS
On 02/15/2014 03:34 AM, Stephen Kelly wrote: > I'd prefer to get it into 3.0 so it can be removed in 4.0 > The chosen string() subcommands would also need to be added > in 3.0 I announced a feature-freeze for 3.0 preparation a couple weeks ago. Things were delayed a bit by updating the release infrastructure and snow storms but we're still done with features for 3.0. The only reason policies CMP0049 and CMP0050 were accepted is because they are about removing old backward compatibility behaviors that have long been out of preferred use, not changes needed for new features. Please target this for post-3.0 development. Thanks, -Brad -- 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] Policy to require project()
On 02/15/2014 05:56 AM, Stephen Kelly wrote: > If a project() command is not written in used code, cmake will generate one. Historically this was meant to keep the hello-world example down to just a single line calling add_executable. With the modern complexities of project() and cmake_minimum_required() functionality perhaps it is time to drop that goal. > Does it make sense to add a policy to CMake 3.0 requiring that the project() > command be present and come after cmake_minimum_required(), and generating > the project() only in OLD behavior? I'd like to wait until after 3.0 for that. -Brad -- 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] visual-studio-preprocessor-undefine fix for /U problems
On 02/14/2014 04:24 PM, Steve Wilson wrote: > new method OutputDefinitionsByTag and adds an argument that lets you specify > the tag.I also fixed the test case. Thanks. I don't see in the new changes where it actually uses the parsed Undefines member. It looks like it just adds the main definitions with both UndefinePreprocessorDefintions and PreprocessorDefintions. Shouldn't OutputDefinitionsByTag take an argument telling it what list of definitions to use, and then used as an implementation detail of OutputPreprocessorDefinitions and OutputUndefinePreprocessorDefinitions? -Brad -- 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 0014760]: Specify output dir for QT4_WRAP_UI
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=14760
==
Reported By:Mathieu Malaterre
Assigned To:
==
Project:CMake
Issue ID: 14760
Category: (No Category)
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-02-17 10:54 EST
Last Modified: 2014-02-17 10:54 EST
==
Summary:Specify output dir for QT4_WRAP_UI
Description:
It would be nice to have an option to specify an output dir for QT4_WRAP_UI.
This way it would be easier to port QMake -> CMake application.
Eg. QMake input:
[...]
UI_DIR = UI/AutoGen
FORMS += UI/UI/BrowseData.ui
[...]
Here is a suggestion for enhancement:
Change current macro into:
macro (QT4_WRAP_UI outfiles )
QT4_EXTRACT_OPTIONS(ui_files ui_options ${ARGN})
foreach (it ${ui_files})
get_filename_component(outfile ${it} NAME_WE)
get_filename_component(infile ${it} ABSOLUTE)
set(outfile ${CMAKE_CURRENT_BINARY_DIR}/${QT4_WRAP_UI_DIR}/ui_${outfile}.h)
add_custom_command(OUTPUT ${outfile}
COMMAND ${QT_UIC_EXECUTABLE}
ARGS ${ui_options} -o ${outfile} ${infile}
MAIN_DEPENDENCY ${infile} VERBATIM)
set(${outfiles} ${${outfiles}} ${outfile})
endforeach ()
endmacro ()
Typical usage:
set(QT4_WRAP_UI_DIR UI/AutoGen )
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/${QT4_WRAP_UI_DIR})
QT4_WRAP_UI(myproject_FORMS_HEADERS ${myproject_FORMS})
==
Issue History
Date ModifiedUsername FieldChange
==
2014-02-17 10:54 Mathieu MalaterreNew Issue
==
--
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] Objective-C support
On 02/15/2014 04:29 PM, Steve Wilson wrote: > I just pushed the updated version of objective-c-support to stage. Nice, thanks. Here are some comments. The "CMakeCompiler.cmake" files cannot have logic like +if(CMAKE_OBJC_ENABLED AND NOT CMAKE_OBJCXX_ENABLED) because the languages can be enabled in any order and the final set is not known when these files are loaded. I think it will take special C++-implemented logic to magically use the best-matching language for .m and .mm sources. > such as CheckOBJCCompilerFlag I see new modules: CheckOBJCCompilerFlag.cmake CheckOBJCSourceCompiles.cmake CheckOBJCSourceRuns.cmake CheckOBJCXXCompilerFlag.cmake CheckOBJCXXSourceCompiles.cmake CheckOBJCXXSourceRuns.cmake Rather than an explosion of modules I'd prefer to correct this historical mistake and create a single API for each check that takes the language as a parameter. Modules CheckTypeSize and CheckStructHasMember recently learned this, for example. So, we would need new modules: CheckCompilerFlag CheckSourceCompiles CheckSourceRuns and then refactor the implementations of the existing modules for C and CXX to be in terms of the general ones. If you don't have time to work on that I think we can just leave out the check modules for now. Thanks, -Brad -- 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] VS10-12 generators deserve much more love
Good pointers thanks a lot. I can now also see the efforts for supporting WinRT which I applaud. I would like to digress a bit if that's permitted. The whole discussion has put me down a bit. The current approach seems pretty stiff and leaves little room for manoeuvre. When it comes to platforms for example, some are hard-coded and others are specifically detected. I don't understand why there is a mixture of them, and this mixture seems to be still promoted. Neither model supports new platforms or I have yet to find a way to include them without code changes. Are there any plans to move onto a more extensible approach in the future? Far away from project files which content gets created via code. Maybe a template style approach whereby generators simply point to templates which use the variables set up during the execution of the cmake scripts? People could then create their local ones if they need to extend/customize them and push them to an unofficial public repository where others could download them, comment on them or improve them. Funny enough, even if these templates were actually CMake script files it would make a huge difference. On Mon, Feb 17, 2014 at 2:14 PM, Brad King wrote: > On 02/16/2014 08:25 PM, Dan Cristiu wrote: > > I've decided to review the code in there and clean it to the point > > where the duplication is minimal. > > I would welcome such an effort. Can you cite some examples of > duplication that you have in mind to reduce? > > > In any case, was there a reason why the toolset is not part of the > > generator name? i.e. "Visual Studio 11 Win64 V110". > > The platform never should have been part of the generator name > either but that convention was established long ago. The version > of VS and the target platform are orthogonal. So is the toolset, > which is why -T is separate. > > Support to specify the PlatformToolset is pretty new so it has > not fully matured yet. It can be set from cmake-gui by using the > Add Entry button to add CMAKE_GENERATOR_TOOLSET prior to the first > configuration. I would welcome an effort to add a dedicated field > in the dialog for it, especially if it could be a drop-down selection > of available toolsets. > > > additional settings which must be part of the project file > > We have some basic support for that: > > > http://www.cmake.org/cmake/help/v2.8.12/cmake.html#prop_tgt:VS_GLOBAL_variable > > but it doesn't cover everything. > > -Brad > > -- > > 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
Re: [cmake-developers] visual-studio-preprocessor-undefine fix for /U problems
Interesting, I’ll revisit it. On Feb 17, 2014, at 8:43 AM, Brad King wrote: > On 02/14/2014 04:24 PM, Steve Wilson wrote: >> new method OutputDefinitionsByTag and adds an argument that lets you specify >> the tag.I also fixed the test case. > > Thanks. I don't see in the new changes where it actually uses the > parsed Undefines member. It looks like it just adds the main > definitions with both UndefinePreprocessorDefintions and > PreprocessorDefintions. Shouldn't OutputDefinitionsByTag take > an argument telling it what list of definitions to use, and then > used as an implementation detail of OutputPreprocessorDefinitions > and OutputUndefinePreprocessorDefinitions? > > -Brad > signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Objective-C support
On Feb 17, 2014, at 8:55 AM, Brad King wrote: > On 02/15/2014 04:29 PM, Steve Wilson wrote: >> I just pushed the updated version of objective-c-support to stage. > > Nice, thanks. Here are some comments. > > The "CMakeCompiler.cmake" files cannot have logic like > > +if(CMAKE_OBJC_ENABLED AND NOT CMAKE_OBJCXX_ENABLED) > > because the languages can be enabled in any order and the final > set is not known when these files are loaded. > > I think it will take special C++-implemented logic to magically > use the best-matching language for .m and .mm sources I wasn’t sure if this kind of solution would work, but thought it didn’t hurt to try. I’ll ask next time when I suspect there might be a problem. I’ll work on some tweaking deeper in the C++ code.Any suggestions where you might like this functionality to appear. >> such as CheckOBJCCompilerFlag > > I see new modules: > > CheckOBJCCompilerFlag.cmake > CheckOBJCSourceCompiles.cmake > CheckOBJCSourceRuns.cmake > CheckOBJCXXCompilerFlag.cmake > CheckOBJCXXSourceCompiles.cmake > CheckOBJCXXSourceRuns.cmake > > Rather than an explosion of modules I'd prefer to correct this > historical mistake and create a single API for each check that > takes the language as a parameter. Modules CheckTypeSize and > CheckStructHasMember recently learned this, for example. So, > we would need new modules: > > CheckCompilerFlag > CheckSourceCompiles > CheckSourceRuns > > and then refactor the implementations of the existing modules > for C and CXX to be in terms of the general ones. > > If you don't have time to work on that I think we can just leave > out the check modules for now. I will take a look and see if I can make the refactor happen. I’ll drop out the OBJC(XX) modules from the Objective-C(++) commits and resubmit those and then separately work on the refactor. It will take a couple of days to make these changes as my paying job ( :) ) requires my focused attention for a bit now. Question: In these cases where I have to drop my work on these changes and switch focus to other things, should the proposed topics be removed from stage, or should they be left for others to look at? signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] VS10-12 generators deserve much more love
On 02/17/2014 11:11 AM, Dan Cristiu wrote: > Are there any plans to move onto a more extensible approach in > the future? No, but there aren't plans to not do it either ;) This is open source. People write the features they need and leave the rest for future work by others that have different requirements and associated resources to support the work. > Far away from project files which content gets > created via code. Maybe a template style approach whereby > generators simply point to templates which use the variables > set up during the execution of the cmake scripts? The VS 6 generator used this approach (see the Templates/ source dir). It became problematic because adding features required updating the templates and supported placeholder replacement and then outside projects' templates would break. > People could > then create their local ones if they need to extend/customize > them and push them to an unofficial public repository where > others could download them, comment on them or improve > them. Funny enough, even if these templates were actually CMake > script files it would make a huge difference. That would require exposing an API to get to all the details encapsulated inside the generators. The API would then have to be supported and would limit our ability to internally refactor things in the future. It is similar to the problem we had with the VS 6 .dsp templates mentioned above. This problem will occur with any approach that allows project code to integrate with the generators at a low level. It helps projects do what they need in the short term but makes long-term maintenance much harder. I'm open to improving the capabilities of the VS genertors but do require that they remain implemented in C++ and that any hooks for customization by project code remain declarative (e.g. target properties). Thanks, -Brad -- 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] Objective-C support
On 02/17/2014 11:30 AM, Steve Wilson wrote: > Any suggestions where you might like this functionality to appear. cmGlobalGenerator::GetLanguageFromExtension is where the lookup is done. cmGlobalGenerator::FillExtensionToLanguageMap is where the map is constructed in the first place. Either the former needs to learn a hard-coded special case for the lookup, or the latter needs to learn how to update the CXX mapping based on OBJC and OBJCXX. The latter is probably cleaner but needs to be done carefully to support filling the maps in any order. > Question: In these cases where I have to drop my work on these changes and > switch focus to other things, should the proposed topics be removed from > stage, or should they be left for others to look at? The stage is meant for integration and testing and can be used for short-term review, but it should not be allowed to collect dust. Some developers keep their own forks on Github or similar sites and publish the topics there for review instead. Thanks, -Brad -- 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] Objective-C support
On Feb 17, 2014, at 9:33 AM, Brad King wrote: > On 02/17/2014 11:30 AM, Steve Wilson wrote: >> Any suggestions where you might like this functionality to appear. > > cmGlobalGenerator::GetLanguageFromExtension is where the lookup is > done. cmGlobalGenerator::FillExtensionToLanguageMap is where the map > is constructed in the first place. Either the former needs to learn > a hard-coded special case for the lookup, or the latter needs to learn > how to update the CXX mapping based on OBJC and OBJCXX. The latter > is probably cleaner but needs to be done carefully to support filling > the maps in any order Great, thanks! >> Question: In these cases where I have to drop my work on these changes and >> switch focus to other things, should the proposed topics be removed from >> stage, or should they be left for others to look at? > > The stage is meant for integration and testing and can be used for > short-term review, but it should not be allowed to collect dust. > Some developers keep their own forks on Github or similar sites > and publish the topics there for review instead. Ok, I've my topics. I still have one topic that I’ve had trouble re-integrating back into my repository that has changes from Stephen Kelly. As soon as I clear that issue up, I’ll remove it from stage. SteveW signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Objective-C support
On Feb 17, 2014, at 9:47 AM, Steve Wilson wrote: > Ok, I've my topics. That should read, “I’ve removed my topics." signature.asc Description: Message signed with OpenPGP using GPGMail -- 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, at least the documentation here: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules says so, unless there is another one I should be referring to. I've changed it to _VERSION. As I said in the last mail, how do we continue from here on? Are the modules ready for acceptance, and if so, who is the person to ask for commit access, or is there something left to fix? Cheers, Matthäus On 16.02.2014 22:11, Stephen Kelly wrote: > 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
[cmake-developers] [CMake 0014761]: FindFreetype.cmake doesn't find libraries as named by upstream build system.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14761
==
Reported By:Marcel Metz
Assigned To:
==
Project:CMake
Issue ID: 14761
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-02-17 20:55 CET
Last Modified: 2014-02-17 20:55 CET
==
Summary:FindFreetype.cmake doesn't find libraries as named
by upstream build system.
Description:
Hello,
the freetype2 project provides different build systems to build their project.
One of those are visual studio projects which create libraries named according
the schema "freetype{,_D,MT,MT_D,ST,ST_D}" This
naming schema isn't honoured by the current FindFreetype2 module.
The attached patch honors nows "freetype{,MT}". I'm
not sure how to properly select the _D(ebug) variants so I left this out for
now.
The patch is created against commit 6f03c86b7 of the cmake git repository.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-02-17 20:55 Marcel MetzNew Issue
2014-02-17 20:55 Marcel MetzFile Added: FindFreetype-vs-naming.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] Adding custom namespaces to FindBoost
On 02/12/2014 03:56 PM, Chuck Atkins wrote: > extract a small subset and build it with a custom namespace instead of boost:: Applied, thanks: FindBoost: Add suport for custom namespaces http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17485e37 -Brad -- 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 0014762]: Add support for customizing strings in Add/Remove Programs
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14762 == Reported By:David Golub Assigned To: == Project:CMake Issue ID: 14762 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-02-17 16:57 EST Last Modified: 2014-02-17 16:57 EST == Summary:Add support for customizing strings in Add/Remove Programs Description: I'm submitting a patch to add support for customizing the various strings that appear in the Add/Remove Programs applet when packaging with Windows Installer XML. == Issue History Date ModifiedUsername FieldChange == 2014-02-17 16:57 David GolubNew Issue 2014-02-17 16:57 David GolubFile Added: 0001-CPack-WIX-Add-support-for-more-customization-of-Add-.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
