Re: [cmake-developers] add_compile_options and link flags
I pushed a topic called link-options-command to https://github.com/swwilso1/CMake On Jun 10, 2014, at 9:18 AM, Brad King brad.k...@kitware.com wrote: On 06/10/2014 11:15 AM, Steve Wilson wrote: https://github.com/swwilso1/CMake the LinkOptionsCommand topic isn't there yet. I will try and get those uploaded today and post when they are available. Great, thanks! -Brad signature.asc Description: Message signed with OpenPGP using GPGMail -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] add_compile_options and link flags
Unfortunately, I didn’t have time to check to see if it works as before. It does compile, but I haven’t looked at it more closely than that. On Jun 11, 2014, at 11:53 AM, Brad King brad.k...@kitware.com wrote: On 06/11/2014 01:50 PM, Steve Wilson wrote: I pushed a topic called link-options-command to https://github.com/swwilso1/CMake I see it is rebased on 'master' too, thanks! -Brad signature.asc Description: Message signed with OpenPGP using GPGMail -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] add_compile_options and link flags
My apologies, I was out ill yesterday. I have a CMake repo on github that contains work in progress. I still haven’t had time to return to work on these issues, but hopefully will soon. https://github.com/swwilso1/CMake However, I need to sync the dev branches with the current master branch and the LinkOptionsCommand topic isn’t there yet. I will try and get those uploaded today and post when they are available. Steve On Jun 9, 2014, at 9:55 AM, Brad King brad.k...@kitware.com wrote: Steve W, On 06/09/2014 11:46 AM, Brad King wrote: See thread here: push of LinkOptionsCommand topic branch http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9203 IIRC there were a couple of minor unresolved issues but it is mostly just waiting for someone to have time to take it to completion. Do you have this branch published anywhere currently? Others may be interested in picking it up. If you don't want to publish it persistently anywhere you can always post a patch series here with the current work-in-progress. Thanks, -Brad signature.asc Description: Message signed with OpenPGP using GPGMail -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] treat .m files as c, not c++
Took me a bit longer than I expected, but you can find the 'objective-c-support' topic at: https://github.com/swwilso1/CMake.git On Mar 19, 2014, at 11:55 AM, Steve Wilson ste...@wolfram.com wrote: On Mar 19, 2014, at 11:09 AM, Brad King brad.k...@kitware.com wrote: On 03/19/2014 12:50 PM, Tim Blechmann wrote: obj-c is a superset of c, while obj-c++ is a superset of obj-c this patch corrects this behavior. The incorrect behavior is left from the earliest days of CMake. Fixing this outright will change existing build behavior. We would have to do this with a CMake Policy. However, Steve Wilson is working on first-class Objective C and Objective C++ support: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9371 That will resolve this in a compatible way by allowing projects to enable OBJC and/or OBJCXX languages to get .m and .mm sources compiled properly. Steve, do you have the work-in-progress topic published somewhere? Not at the moment, but I’ll work on making the topic available on github before the end of the day. -- 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/cgi-bin/mailman/listinfo/cmake-developers signature.asc Description: Message signed with OpenPGP using GPGMail -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] treat .m files as c, not c++
On Mar 19, 2014, at 11:09 AM, Brad King brad.k...@kitware.com wrote: On 03/19/2014 12:50 PM, Tim Blechmann wrote: obj-c is a superset of c, while obj-c++ is a superset of obj-c this patch corrects this behavior. The incorrect behavior is left from the earliest days of CMake. Fixing this outright will change existing build behavior. We would have to do this with a CMake Policy. However, Steve Wilson is working on first-class Objective C and Objective C++ support: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9371 That will resolve this in a compatible way by allowing projects to enable OBJC and/or OBJCXX languages to get .m and .mm sources compiled properly. Steve, do you have the work-in-progress topic published somewhere? Not at the moment, but I’ll work on making the topic available on github before the end of the day. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] push of LinkOptionsCommand topic branch
I’m happy to keep working on the topic as well. I just have to let it bubble
back up to the top of my queue.
SteveW
On Feb 19, 2014, at 9:27 AM, Stephen Kelly steve...@gmail.com wrote:
Brad King wrote:
On 02/19/2014 11:00 AM, Stephen Kelly wrote:
I've been waiting for master to re-open for features before working on
it.
It is now open for post-3.0 development :)
Yep, great. Much better than waiting for weeks during RC phase. :)
Consider splitting the use-cases and adding both
{INTERFACE_,}LINK_OPTIONS and {INTERFACE_,}ARCHIVE_OPTIONS instead.
Yes. That will be consistent with LINK_FLAGS/STATIC_LIBRARY_FLAGS
but with better naming.
My preference currently is the former, and have CMake do transformation
if passing options to the compiler driver, assuming cmake can tell the
difference between that and an actual linker.
Yes, that makes sense. It may take some work in the platform info
file rule variables so that the generators can tell when they are
invoking the linker directly v. through a compiler, and what the
wrapper option (-Wl,) for the compiler should be.
Those are the only two issues I know of. This topic isn't a high priority
for me though. I'll be working on other topics first.
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
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] visual-studio-preprocessor-undefine fix for /U problems
Interesting, I’ll revisit it. On Feb 17, 2014, at 8:43 AM, Brad King brad.k...@kitware.com 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 brad.k...@kitware.com 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 CMakeLANGCompiler.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] Objective-C support
On Feb 17, 2014, at 9:33 AM, Brad King brad.k...@kitware.com 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 ste...@wolfram.com 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
[cmake-developers] Tests and cmake_minimum_required question
When developing a new feature, we add tests to the test suite. Some of those tests require CMakeLists.txt with the cmake_minimum_required(VERSION …)/project() commands. If you are testing a brand new feature, what version number should be used with cmake_minimum_required? 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 14, 2014, at 12:06 PM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:35 PM, Steve Wilson wrote: The topic name is ‘objective-c-support.’ Currently if CXX is enabled then .m sources get compiled as CXX. See Modules/CMakeCXXCompiler.cmake.in: set(CMAKE_CXX_SOURCE_FILE_EXTENSIONS C;M;c++;cc;cpp;cxx;m;mm;CPP) In order to be compatible we need to make sure that is still the case. However, if OBJC is enabled then that should be preferred to CXX for .m sources. Is that the case with these changes? Please add test cases to cover these combinations. I just pushed the updated version of objective-c-support to stage. It contains these requested changes as well as other additional tests/modules (such as CheckOBJCCompilerFlag). It also includes a commit introducing support for Objective-C++. 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] AddCustomCommandWithConfig
On Feb 15, 2014, at 2:06 AM, Stephen Kelly steve...@gmail.com wrote: I still don't know if you got an error message without posting it when you tried to reset before, or whether you managed to reset your local branch to the right point: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9203/focus=9359 Yes, I’ve been looking at it briefly but still can’t explain the problem yet. I will answer when I have more to say. There is still the issue of the STATIC_LIBRARY handling. The small, single-purpose commits paint it brightly. It shouldn't be difficult to figure out. That's part of the reason that getting the commits and history right is important - it is easier for review to find issues like this. Yes, I will definitely be looking at this issue and addressing it for this topic. Like I mentioned earlier, my time window is shrinking so I’m trying to get the topics submitted as I can. I can continue to refine them as I go, but I want to be sure they all make it to visibility while I can. Either way, if you don't figure it out, then I will have to, but then you're on my schedule :). I’ll figure it out, just moving as fast as I can. There is still design work to do on the branch too, so if you still want to work on that branch, take it up on that thread. Yup, will do. 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
Yes, it does, less support for Objective-C++. I haven’t add support for Objective-C++.It shouldn’t be too hard to add support for Objective-C++ though. On Feb 14, 2014, at 8:42 AM, Sean McBride s...@rogue-research.com wrote: On Thu, 13 Feb 2014 17:35:42 -0700, Steve Wilson said: I just pushed a small topic branch to stage the introduces support for Objective-C as a ‘supported’ language with a separate identity from C/ CXX. The topic name is ‘objective-c-support.’ Does that solve this by any chance: http://public.kitware.com/Bug/view.php?id=4756 Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada 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] visual-studio-preprocessor-undefine fix for /U problems
Will do. On Feb 14, 2014, at 11:26 AM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:33 PM, Steve Wilson wrote: The topic is visual-studio-preprocessor-undefine. Thanks. The method cmVisualStudioGeneratorOptions ::OutputUndefinePreprocessorDefinitions appears to duplicate a lot of code from cmVisualStudioGeneratorOptions ::OutputPreprocessorDefinitions Please factor out and parameterize the common pieces to avoid the duplication. Also, the test case appears to undef a macro in a specific source file and test that it is undefined, but never defines the macro for the whole target so of course it will never be defined and the test will always pass. 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 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 14, 2014, at 12:06 PM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:35 PM, Steve Wilson wrote: The topic name is ‘objective-c-support.’ Currently if CXX is enabled then .m sources get compiled as CXX. See Modules/CMakeCXXCompiler.cmake.in: set(CMAKE_CXX_SOURCE_FILE_EXTENSIONS C;M;c++;cc;cpp;cxx;m;mm;CPP) In order to be compatible we need to make sure that is still the case. However, if OBJC is enabled then that should be preferred to CXX for .m sources. There isn’t anything specific in the code to make an accounting for this type of requirement. I’ll see what I can do and update the tests. Is that the case with these changes? Please add test cases to cover these combinations. IMO the capitalization ObjC looks nicer than OBJC and will extend better to ObjCXX than OBJCXX. I have no strong preference if others disagree though. I don’t have a strong preference, but the preference I do have is for the OBJC (OBJCXX) form simply because it matches the capital cases of C and CXX in the CMAKE_* variables, which is the most common language type that users encounter. 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] visual-studio-preprocessor-undefine fix for /U problems
On Feb 14, 2014, at 11:26 AM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:33 PM, Steve Wilson wrote: The topic is visual-studio-preprocessor-undefine. Thanks. The method cmVisualStudioGeneratorOptions ::OutputUndefinePreprocessorDefinitions appears to duplicate a lot of code from cmVisualStudioGeneratorOptions ::OutputPreprocessorDefinitions In the refactor of these functions, would you like to see that refactor as a separate commit or merged in with the commit for the other changes? 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] visual-studio-preprocessor-undefine fix for /U problems
I pushed a updated version of the topic branch to stage. It refactors the OutputPreprocessorDefinitions method into a a new method OutputDefinitionsByTag and adds an argument that lets you specify the tag.I also fixed the test case. SteveW On Feb 14, 2014, at 11:26 AM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:33 PM, Steve Wilson wrote: The topic is visual-studio-preprocessor-undefine. Thanks. The method cmVisualStudioGeneratorOptions ::OutputUndefinePreprocessorDefinitions appears to duplicate a lot of code from cmVisualStudioGeneratorOptions ::OutputPreprocessorDefinitions Please factor out and parameterize the common pieces to avoid the duplication. Also, the test case appears to undef a macro in a specific source file and test that it is undefined, but never defines the macro for the whole target so of course it will never be defined and the test will always pass. 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 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 Mavericks (OS X 10.9) there are two STL implementations: libstdc++ and libc++. I’m adding support for Objective-C++ and on Mavericks it matters which C++ library is used for linking. Is there a standard mechanism already in place for handling the difference in CMake. I checked for the -stdlib command line flag in the sources, but didn’t find it anywhere.Or put it another way, do we require users to decide themselves with STL implementation to use? 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
I was really looking for a way to add the the STL library as a library on the command line and then I realized that I had forgotten that on the Mac, the Objective-C++ compiler driver is clang++/g++. I was only thinking about clang/gcc. Sorry for the noise. On Feb 14, 2014, at 4:02 PM, Sean McBride s...@rogue-research.com wrote: On Fri, 14 Feb 2014 17:47:00 -0500, Ben Boeckel said: Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super stable. Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking std::string ABI with C++11 support enabled (4.7.2 fixed it to be compatible with 4.7.0 and I'd, personally, blacklist those two versions if you use C++11). What I mean is that with C++, and STL especially, it's hard to build a library with a given compiler/standard library combination and link that library into an executable built with a different compiler/standard library combination. (Harder than with say C.) That's the case on any platform. I was only trying to point out that 10.9 Mavericks is not special in this regard. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada 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
[cmake-developers] visual-studio-preprocessor-undefine fix for /U problems
I just pushed a tiny topic branch that fixes problems in the Visual Studio generators where the generators will squash the use of /U in compile flags. The change allows /U to go through correctly to the compiler command line. The topic is visual-studio-preprocessor-undefine. 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
[cmake-developers] Objective-C support
I just pushed a small topic branch to stage the introduces support for Objective-C as a ‘supported’ language with a separate identity from C/CXX. The topic name is ‘objective-c-support.’ 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] push of LinkOptionsCommand topic branch
I saved a copy of the branch in another of the repository. The commit numbers didn’t change and as far as I can tell they are still in the same order that I had them in when I initially pushed the branch.There are no rebases removing the downstream updates, etc... On Feb 12, 2014, at 2:08 AM, Stephen Kelly steve...@gmail.com wrote: Steve Wilson wrote: when I do the checkout followed by the reset —hard, all I get is the same set of commits that I had before. What makes you conclude they are the same? 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 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] AddCustomCommandWithConfig
On Feb 12, 2014, at 2:15 AM, Stephen Kelly steve...@gmail.com wrote: I haven't looked thoroughly, but how much does dependency specification/handling need to change? The dependency of a command on a set of targets should now be config-specific, right? Does that mean making changes to cmTargetTraceDependencies::CheckCustomCommand? What other impact is there on dependency handling here? I am not familiar with that code and can’t answer that question off the top of my head. Does the first patch in your topic pass the unit tests it adds? Is the second patch needed for that? If so, they belong in one patch, so squash them together. The documentation should be added in the patch that adds the feature, not in a separate patch. The first patch does pass the unit test. The second patch is not needed to pass the test, so I will not be squashing them together. I squashed the documentation into the first patch. On a side note, I am running out of time for contributing these patches back to the project. I am spending more time responding to requests to re-order and change commit messages etc.. than I am changing the code (I am learning and will get it correct one day). I understand that you want your repository history to be as correct as possible and am grateful that you care enough to try and help someone get up to speed.I need to come to some kind of compromise here. If you want these changes I am happy to contribute them, but I don’t have time to spend hours re-working things over and over. If that means it would be better to just contribute patches through email or some other format of code exchange I am happy to do that.If you would like me to just file bug/feature requests, I can do that as well. If you don’t want the changes (at least as I am able to provide them) then I can go back to maintaining my own fork of the sources. I’m not trying to complain or avoid meeting your standards, I’m just having to deal with time priorities that are not going to allow me to keep quibbling over these details. 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] push of LinkOptionsCommand topic branch
On Feb 8, 2014, at 4:10 AM, Stephen Kelly steve...@gmail.com wrote: Great, thanks for all of that. I have force-pushed your branch, which means you need to do this before proceeding with further work. 1) Get remote changes, including my change to your branch. You'll see output comparable to this, where your branch is listed as having a forced update: $ git fetch remote: Counting objects: 27, done. remote: Compressing objects: 100% (10/10), done. remote: Total 11 (delta 8), reused 2 (delta 1) Unpacking objects: 100% (11/11), done. From git://cmake.org/cmake + 74c3875...31b4965 gcc-ipo- origin/gcc-ipo (forced update) 53cffda..d582809 master - origin/master 3283439..930141d next - origin/next You can run gitk 74c3875...31b4965 on any of the ranges on the left to see the old and new branch in one view. 2) git checkout LinkOptionsCommand 3) Assuming you still have no local changes, git reset --hard origin/LinkOptionsCommand The command git diff 0a4b066..b8782eb My apologies for the delay. I have been side tracked in some other work. Perhaps I’m misunderstanding these directions but when I fetch the updates from stage, I don’t get any modified commits.I got the (forced update) message, but when I do the checkout followed by the reset —hard, all I get is the same set of commits that I had before. 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] add_custom_command differences in tests
Thank you, that fixed the problem I was seeing.
SteveW
On Feb 10, 2014, at 8:28 AM, Brad King brad.k...@kitware.com wrote:
On 02/07/2014 05:19 PM, Steve Wilson wrote:
On Feb 7, 2014, at 3:01 PM, Brad King wrote:
-DCMAKE_BUILD_TYPE=\${CTEST_CONFIGURATION_TYPE}
I have tried adding that to my test call (--build-options) but it doesn't
seem to make any difference.
Oops, I picked the wrong line for an example. We need to pass
the test configuration to the invocation of ctest --build-and-test.
In your example change:
add_test(CustomCommand.CONFIG ${CMAKE_CTEST_COMMAND}
--build-and-test
...
)
to:
add_test(CustomCommand.CONFIG
${CMAKE_CTEST_COMMAND} -C \${CTEST_CONFIGURATION_TYPE}
--build-and-test
...
)
That will ensure that the test project builds as the tested config.
-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
[cmake-developers] AddCustomCommandWithConfig
I just pushed the topic AddCustomCommandWithConfig to stage. This topic implements the CONFIG keyword for add_custom_command(). 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] push of LinkOptionsCommand topic branch
On Feb 7, 2014, at 1:45 AM, Stephen Kelly steve...@gmail.com wrote: You still have extra dashes in the titles in the target property documentation. Fixed. Please also rebase to master. The documentation has been updated to add more relevant links, markup etc. Please follow the same patterns in all the new docs on your branch. Updated Note also that your add_link_options doc copied some content from add_compile_commands without modifying it (re include directories). Fixed Here's some guidance Brad gave me a while ago regarding writing commit messages with an imperative mood: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6904 Thanks, these tips are quite helpful. The new tests look good to me. Please use spaces not tabs in foo.cpp in the add_link_options test. You also add a foo.cpp in the target_link_options test, but it has no content. Is that deliberate, or should it be the same as the other? In theory it doesn’t matter if foo.cpp is empty for the target_link_options test. I went ahead and added some content though to match the add_link_options test, just to be consistent. In the 'cmLocalGenerator: Add AddLinkOptions method for LINK_FLAGS.' commit message, you mention that the differences regarding static and object libraries from the xcode generator are included. You don't say what impact that has on other generators though. Were the other generators buggy by not doing the same thing before? Or was the xcode generator special for needing this? If the xcode generator has a special need, then that snippet should stay in the xcode generator, right? Good questions. The other generators did not specifically (that I noticed) have checks for static/object libraries. It seems to me though that they maybe should have which is why I put the checks in AddLinkOptions. If this decision should be changed though, I have no problem changing it. I’m no expert on the generators. I pushed the other changes back to stage. 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] add_custom_command differences in tests
On Feb 7, 2014, at 10:14 AM, Steve Wilson ste...@wolfram.com wrote: On Feb 6, 2014, at 10:12 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Thu, Feb 06, 2014 at 17:30:11 -0700, Steve Wilson wrote: I have my topic branch with the add_custom_command changes to include the CONFIG keyword working.The CMake binary produced from the build will correctly generated build systems that have custom commands with the CONFIG keyword. I’m having trouble writing tests for the changes though. When I run add_custom_command with the CONFIG keyword in the test suite the CONFIG keyword does not work. I need a little guidance with the test suite. I’m not super familiar with CTest so I’m not sure where to look next to find the problem. So my question: Why would add_custom_command behave differently in the tests than in regular build system generation? I have been able to determine that the code isn’t working because it seems that when running from ctest, cmake seems to be running in a configuration-less mode. Ie CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPE are not set regardless of the -C option passed to ctest.I would have thought that the build configuration of the test would match the configuration set with ‘ctest -C .' 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] add_custom_command differences in tests
On Feb 7, 2014, at 3:01 PM, Brad King brad.k...@kitware.com wrote:
On 02/07/2014 04:46 PM, Jean-Christophe Fillion-Robin wrote:
I have been able to determine that the code isn’t working because it
seems that when running from ctest, cmake seems to be running in a
configuration-less mode. Ie CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPE are
not set regardless of the -C option passed to ctest.I would have
thought that the
build configuration of the test would match the configuration set with
‘ctest -C .'
Agreed. Is there an issue in the tracker to document that problem ?
No, because it is not a bug, at least in so far as it is not intended
to work. Also it only influences CMake's own testing and not other
projects so it is not public-facing behavior.
A few calls in Tests/CMakeLists.txt add
-DCMAKE_BUILD_TYPE=\${CTEST_CONFIGURATION_TYPE}
I have tried adding that to my test call (—build-options) but it doesn’t seem
to make any difference.
to force building with the tested configuration but most tests do not
need this. Most tests work in any configuration and do not depend on
being built as the same configuration that the running CMake was.
This particular feature I am testing tests add_custom_command in different
configurations, so configurations do matter in this scenario.
Steve W, can you post your tests as a patch or point us to a repo
where they are published so we can see how you're trying to test the
new CONFIG option?
I pushed the add-custom-command-config-tmp branch to stage. This branch does
not represent the final topic branch I intend to submit. It is only my local
working branch. It contains a sample test in Tests/CustomCommand/ConfigTest.
I will remove it as soon as you have seen what you need.
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] push of LinkOptionsCommand topic branch
I have implemented all the suggestions from the list below (modulo number 5 which needs more input from others). I have pushed the new branch to stage. SteveW On Feb 4, 2014, at 3:41 AM, Stephen Kelly steve...@gmail.com wrote: 1) Your first commit should be split up into at least two commits. The first commit in your topic should probably refactor the generators to use a new cmLocalGenerator::AddLinkOptions method which uses the LINK_FLAGS. See eg commit 35496761 where I did similar for COMPILE_FLAGS. The AddLinkOptions will have the special handling of OBJECT_LIBRARY and STATIC_LIBRARY from the Xcode generator. If that is appropriate for all generators, the commit message should say why. The second commit should add the COMPILE_OPTIONS handling to that method. My request that you create commits which change the user interface along with all supporting code to do so may have been confusing. Really what is needed is to create commits which are complete, self-contained and doing one thing at a time. That's why it makes sense to split the first commit up into two parts. If it makes sense to split it into further self-contained and complete parts, feel free to do so. I just wanted to discourage commits which are divided up by 'changes to files' rather than 'conceptual changes'. For example, changing processCompileOptionsInternal to processOptionsInternal and changing the logName at call sites could be a standalone commit preceeding your first commit. 2) The change to cmNinjaNormalTargetGenerator seems incorrect. Should linkFlags should be used with AddLinkOptions? 3) Documentation title underlines should be as long as the title, not 3 dashes longer. 4) Tests should avoid bad practices like using target_link_options to add libraries. Instead try to choose suitable link flags for the tests. On GNU, you can do this: add_executable(foo foo.cpp) target_link_options(foo PRIVATE -Wl,--ignore-unresolved-symbol,main) and write a foo.cpp which does not define main. 5) Regarding what I said before about accepting -Wl,--no-undefined versus accepting --no-undefined, I think the case of flags with arguments as above shows that only the -Wl, prefixed case should be accepted (as your branch already does). The documentation should possibly be clear that the contents of LINK_OPTIONS should be suitable for passing to the driver, not directly to the linker. 6) For the ExportImport test, you should create some export target on the Export side, and use it on the Import side. For example, on the Export side, do something like add_library(no_main_is_ok INTERFACE) target_link_options(no_main_is_ok INTERFACE -Wl,--ignore-unresolved-symbol,main) # ... Export the target. and on the Import side, add_executable(exe_no_main exe_no_main.cpp) target_link_libraries(exe_no_main no_main_is_ok) That should be done for both the import from the build tree and the install tree, as much of the existing code in Import/ does. 7) I've added two commits to your branch. Please squash them into the appropriate commits in your topic. 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] push of LinkOptionsCommand topic branch
On Feb 6, 2014, at 3:56 PM, Stephen Kelly steve...@gmail.com wrote: There are a few things I'd like to touch up a bit. How comfortable are you with git? Would it cause problems for you if I force push your branch, or would you know how to handle that? Do you have further local changes? I’m a relative git newbie. I can get around ok and am learning a bunch as I go. The term ‘force push’ isn’t familiar though so I’m afraid you’ll have to explain (or I can look it up). I do not have any more local changes. I’ve switched to working on a different feature. 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
[cmake-developers] add_custom_command differences in tests
I have my topic branch with the add_custom_command changes to include the CONFIG keyword working.The CMake binary produced from the build will correctly generated build systems that have custom commands with the CONFIG keyword. I’m having trouble writing tests for the changes though. When I run add_custom_command with the CONFIG keyword in the test suite the CONFIG keyword does not work. I need a little guidance with the test suite. I’m not super familiar with CTest so I’m not sure where to look next to find the problem. So my question: Why would add_custom_command behave differently in the tests than in regular build system generation? Thank for any help. 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] push of LinkOptionsCommand topic branch
Let’s try all this again.I have a couple questions. On Feb 4, 2014, at 3:41 AM, Stephen Kelly steve...@gmail.com wrote: 2) The change to cmNinjaNormalTargetGenerator seems incorrect. Should linkFlags should be used with AddLinkOptions? Do you mean linkFlags vs vars[“LINK_FLAGS”]? I suppose it could use linkFlags. I could just revert the call to GetTargetFlags to use vars[“LINK_FLAGS”]. I was trying to avoid the case of getting the link flags for the target twice. Ie getting them once in vars[“LINK_FLAGS”] and then again in AddLinkOptions(). 3) Documentation title underlines should be as long as the title, not 3 dashes longer. Ok great. What specifically are you referring to with this comment? 4) Tests should avoid bad practices like using target_link_options to add libraries. Instead try to choose suitable link flags for the tests. I’m having a little trouble with your notion of ‘bad practices.’ I’m sure you have good reasons for making the determination that they are bad practices, but to me they seem somewhat arbitrary. Is there some design document that you are using to make these determinations? I’m not trying to cause problems, I’m just saying that adding a library as a linker flag is a perfectly normal/legitimate thing to do coming from a Makefile world (or other build environment world). I realize that CMake has different mechanisms for explicitly handling libraries, but the point isn’t to handle the library, the point was just to pass a reasonable linker option. On GNU, you can do this: add_executable(foo foo.cpp) target_link_options(foo PRIVATE -Wl,--ignore-unresolved-symbol,main) and write a foo.cpp which does not define main. I agree this would make a good test, but it doesn’t change my earlier comment. Adding a library via a linker option is a perfectly valid use of linker options. If it wasn’t, the linker (or the compiler driver) wouldn’t support it. Does that make sense? How should I determine what is bad practice in the face of what is reasonable? 5) Regarding what I said before about accepting -Wl,--no-undefined versus accepting --no-undefined, I think the case of flags with arguments as above shows that only the -Wl, prefixed case should be accepted (as your branch already does). However, what if someone changes the mechanism that picks the linker so that instead of using the compiler driver to drive the link stage, they use the actual linker? I don’t do such a thing with my build systems and in all probability the majority of users would never need to make such a change. However, if I, for some reason, *did* need to change CMake so that the link stage invoked the linker directly, I would absolutely expect the link options commands to pass whatever linker option I deemed necessary to the linker. I don’t think that this suggestion is the right way to go. I will of course defer to your judgement, but I don’t agree. Perhaps there is a detail I’m missing about how the code makes a distinction between —no-undefined and -Wl,—no-undefined. The documentation should possibly be clear that the contents of LINK_OPTIONS should be suitable for passing to the driver, not directly to the linker. 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
[cmake-developers] CMAKE_CONFIGURATION_TYPES
In the documentation for CMAKE_CONFIGURATION_TYPES it states: “… but can be extended to provide other build types. … “ How would one provide other build types? 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] push of LinkOptionsCommand topic branch
On Feb 5, 2014, at 3:06 PM, Stephen Kelly steve...@gmail.com wrote: Steve Wilson wrote: Now, everything you have said about not encouraging this kind of usage for target_link_options() and libraries, etc… is valid. However, does that standard apply to tests. Are tests just tests? Admittedly, the target_compile_options tests use defines as test input. I'd gladly swap that out for an alternative flag if there were a suitable flag which gave us the same test coverage on the dashboard. The add_compile_options command documents itself as not suitable for preprocessor defines and include directories, however. I guess target_compile_options documentation should get a similar note. I would also like to see the target_link_options documentation discourage use for specifying libraries. If you feel so strongly about using a -llibrary flag in the tests, then that's ok, but for me 'the file must exist' is a winning argument in favor of not doing that. I agree, ‘the file must exist’ is a winning argument. I’m not trying to push for this type of test of using libraries with target_link_options or add_link_options. (I’m already working on changes on the order that you suggested). My question has evolved more into the question of ‘what are first principles for tests?' 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] push of LinkOptionsCommand topic branch
On Feb 4, 2014, at 3:49 AM, Stephen Kelly steve...@gmail.com wrote: Stephen Kelly wrote: 7) I've added two commits to your branch. Please squash them into the appropriate commits in your topic. My bad, missed that one. Oh, forgot this one: 8) I get some unit test failures: The following tests FAILED: 85 - LinkFlags-dll_config (Failed) 87 - LinkFlags-exe_config (Failed) Working on this failure now. 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] push of LinkOptionsCommand topic branch
I have applied all the suggestions and re-pushed LinkOptionsCommand (after
rebasing) to stage.
Thanks,
SteveW
On Feb 2, 2014, at 2:44 AM, Stephen Kelly steve...@gmail.com wrote:
Steve Wilson wrote:
I have just pushed the LinkOptionsCommand topic branch to stage. This
topic branch contains commits that implement support for:
add_link_options()
target_link_options()
and the LINK_OPTIONS variable.
Please take a look as interested and send me feedback.
Thanks for that.
1) The first thing I notice is that I don't think you've broken the commits
up along the correct fault lines. It would make more sense to squash the
changes to cmTarget, cmLocalGenerator, the generators, the DAGChecker and
the cmTargetLinkOptionsCommand together along with the help for that command
and target properties and the tests for it. Actually, instead of squashing
it into one commit, you can consider creating multiple commits, eg one which
adds the {INTERFACE_,}LINK_OPTIONS props (and tests and documents them), and
another which adds the command (with tests and docs). Consider how you can
split your commits along 'interface changes' 'fault lines'.
In follow-up commits you can add the cmAddLinkOptionsCommand with the
changes to the cmMakefile (and tests and docs), and exporting (with test and
docs extensions).
That order of commits makes it clear what the dependent changes are. The
cmAddLinkOptionsCommand and changes to the cmMakefile are convenience only.
The relevant change to CMake is support for the target property, and the
high-level way to set that target property is cmTargetLinkOptionsCommand.
As it is, your first commit adds changes to the cmMakefile interface but no
users of the new AddLinkOption interface until the command is added. That's
why that change should be in the same commit as the new command.
The commit message would then describe changes relevant to the user
interface, instead of only specific changes to the class interfaces, which
probably don't belong in the commit message anyway.
If you don't know how to rebase with git, just leave all of this for now.
2) The processLinkOptionsInternal method is almost identical to
processCompileOptionsInternal. Consider renaming the latter (in a separate,
standalone commit), refactoring it and using it instead.
3) Your topic doesn't remove code from the generators which reads the
LINK_FLAGS target property. As the new cmLocalGenerator method will do that,
you can remove it from the concrete generators. See eg commit 35496761 where
I did similar for COMPILE_FLAGS.
4) The use of PROCESS_BEFORE in cmTargetCompileOptionsCommand seems to be a
bug, don't repeat it in cmTargetLinkOptionsCommand.
5) The commit which adds exporting of the new target property should extend
the ExportImport unit test.
6) New docs should link to target properties with rst code like
:prop_tgt:`LINK_OPTIONS`. Some of the COMPILE_OPTIONS related doc is too old
to link like this properly, so see Help/manual/cmake-buildsystem.7.rst for
example.
7) Consider extending Help/manual/cmake-buildsystem.7.rst with notes about
setting the LINK_OPTIONS and new commands.
8) One of the reasons I didn't add LINK_OPTIONS before was that I didn't
know whether it should accept --no-undefined or -Wl,--no-undefined, or
both. Is the latter compiler-driver-specific? Is that irrelevant because the
link option is tool specific anyway?
9) Use spaces, not tabs, even in tests.
I've listed a lot of feedback, but it's all minor stuff. Thanks for the
contribution.
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
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] add_custom_command changes, was [Introductions and questions]
Sounds good. I will get this work prepared and submitted as soon as I can. SteveW On Feb 3, 2014, at 12:43 PM, Brad King brad.k...@kitware.com wrote: On 01/29/2014 05:54 PM, Steve Wilson wrote: Is there a need for the add_custom_command() version with CONFIG? Yes. Petr's example of handling per-config OUTPUT is one justification. It is also easier to write and read code using the proposed CONFIG option rather than generator expressions, especially when the command is only to be executed in a subset of configurations. 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 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
[cmake-developers] push of LinkOptionsCommand topic branch
I have just pushed the LinkOptionsCommand topic branch to stage. This topic branch contains commits that implement support for: add_link_options() target_link_options() and the LINK_OPTIONS variable. Please take a look as interested and send me feedback. Thanks, 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] add_custom_command changes, was [Introductions and questions]
On Jan 24, 2014, at 3:25 PM, Steve Wilson ste...@wolfram.com wrote: The first item I would like to see merged back to the project is issue 9974 in the Mantis tracker (CMake should support custom commands that can vary by configuration). I am the author of the original set of patches submitted in that report. I did not have time to follow up on that Mantis issue as responses developed, but can follow up now. In looking back through my changes for this issue and updating the changes for the current sources, I’ve realized that generator expressions in custom commands might be sufficient for my needs (my build system was initially designed in 2009 and hasn’t been significantly updated for new features such as generator expressions). However there is one bug (14353) that prevents them from being fully useful. My proposed changes for add_custom_command would be the following: add_custom_command(OUTPUT output1 [output2 ...] COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [MAIN_DEPENDENCY depend] [DEPENDS [depends...]] [IMPLICIT_DEPENDS lang1 depend1 [lang2 depend2] ...] [WORKING_DIRECTORY dir] [COMMENT comment] [VERBATIM] [APPEND] [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo | ...]) add_custom_command(TARGET target PRE_BUILD | PRE_LINK | POST_BUILD COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [WORKING_DIRECTORY dir] [COMMENT comment] [VERBATIM] [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo | ...]) The addition of course here is the CONFIG keyword that takes a configuration argument. When add_custom_command() has a CONFIG argument, all of the commands in the custom command only get executed if the build is configured in the requisite configuration (or is selected in an IDE configuration). Currently generator expressions in custom commands cannot work for this kind of usage because of bug 14353. In 14353 generator expressions that have a space character (i.e. more content than just one word/command) don’t parse correctly and thus make complex custom commands that vary by configuration impossible to construct. Is there a need for the add_custom_command() version with CONFIG? While the generator expressions make short add_custom_command() usages work quite nicely I could see the case where the generator expression syntax might become unwieldy for larger custom commands that have many COMMAND statements. I personally would not want to write: add_custom_command(… COMMAND $$CONFIG:…:… COMMAND $$CONFIG:…:… COMMAND $$CONFIG:…:… ... ) repeatedly, while having to embed my command inside the generator $$CONFIG:…:… syntax. My build systems have custom commands for Unix/Windows/etc… that require careful attention to make sure the commands execute correctly in the platform specific command interpreters and the $$ syntax would just be an extra confusing layer to have to maintain. Even though most usage cases would be fine with the generator expressions, I would still find the add_custom_command() with the CONFIG keyword useful for use with long custom commands. However, if everyone else thinks there is really no need for this form of add_custom_command, then I would stop working on re-integrating my changes into the source tree and work on 14353 instead. Opinions? 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
[cmake-developers] Policy CMP0043
In working with my older build system with CMake from the master branch, I quickly ran into policy CMP0043: Ignore COMPILE_DEFINITIONS_Config properties. My build system makes heavy use of the COMPILE_DEFINITIONS_Config, COMPILE_FLAGS_Config, LINK_FLAGS_Config paradigm for setting compiler/linker options.While I didn’t see a specific policy for COMPILE_FLAGS moving to COMPILE_OPTIONS, the sources seem to indicate that COMPILE_FLAGS_Config (and indeed the use of COMPILE_FLAGS) will be deprecated in favor of COMPILE_OPTIONS and the newer methods of modifying COMPILE_OPTIONS such as target_compile_options().Of course I would assume that LINK_FLAGS and LINK_FLAGS_Config would go this route as well. I noticed however that target_link_options() does not exist.Two questions: 1. Is there a plan to move LINK_FLAGS to a LINK_OPTIONS replacement and provide a target_link_options() command? (BTW, where could I find the master feature plans and timetables?) 2. If so, is someone already working on this implementation? If not, I’ve started an implementation branch of my own, but realized I probably shouldn’t walk too far down that road without getting answers for these two questions. Thanks, Steve 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] Introductions and questions
Thanks for the help! I’ll get to these as soon as possible. Steve On Jan 27, 2014, at 7:27 AM, Brad King brad.k...@kitware.com wrote: On 01/25/2014 05:45 AM, Stephen Kelly wrote: Awesome, welcome! Seconded! These links should have all you need: http://www.cmake.org/Wiki/CMake/Git/Account#Git http://www.cmake.org/Wiki/CMake/Git/Develop Please follow the steps outlined here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer On the account request form please list either me or Steve K. as a reference. Thanks, -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
[cmake-developers] Introductions and questions
Hi all, I just wanted to offer a quick introduction. My name is Steve Wilson. I work at Wolfram Research and have been the primary developer of build systems that use CMake as a build system generator.In the course of using CMake to replace older systems I have had to make the occasional change to CMake to match older functionality or to work with requirements for our builds. I have reported some of these changes to the Mantis tracker, some have been incorporated into the mainstream CMake and some have not. As a result, I maintain a separate fork of CMake for our purposes.With the accelerated release schedule (with respect to the older CVS days when things moved a little slower) of CMake these days, I find it harder to keep my fork up-to-date. I would like to go ahead and merge/submit some of my changes back to the project in order to simplify maintenance, etc… Of course changes would have to be approved etc and I understand that approval may or may not happen on any given change, but this is the place to start so I’m starting. The first item I would like to see merged back to the project is issue 9974 in the Mantis tracker (CMake should support custom commands that can vary by configuration). I am the author of the original set of patches submitted in that report. I did not have time to follow up on that Mantis issue as responses developed, but can follow up now. I also have a second set of changes that add support for Objective-C as a supported development language. I understand that CMake does a pretty good job with Objective-C support as it is, but I have found my company’s needs for iOS related projects to require full support from CMake for Objective-C. I am happy to proceed according to any guidelines you have with regards to submitting patches or getting push access to the git CMake repository.If you could let me know how you would like me to proceed I would appreciate the guidance. Looking forward to hearing from and working with you all. Steve 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
