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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
...@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
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
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
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
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
: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
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
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
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
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
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
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
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
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
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 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.
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
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
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
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
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
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
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
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
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
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:
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
44 matches
Mail list logo