Matthew Woehlke wrote:
target_include_directories(foo PUBLIC
$BUILD_INTERFACE:${Foo_BINARY_DIR}
$INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include
)
...with Ninja, the include directive passed to the compiler is '-I.'
The '-I.' shouldn't be a problem. I've just tested on linux and it
On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
This is now pushed to stage/fix-java-jar-depends. If someone
knowledgeable could have a look, that would be much appreciated.
Andreas, Nicholas?
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Thursday 14 March 2013 10:57:10 Brad King wrote:
On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
This is now pushed to stage/fix-java-jar-depends. If someone
knowledgeable could have a look, that would be much appreciated.
Andreas, Nicholas?
Hi Brad,
thanks for the mail. I've reviewed
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14012
==
Reported By:Orion Poplawski
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14013
==
Reported By:szotsaki
Assigned To:
On Thursday 14 March 2013, Brad King wrote:
On 03/13/2013 05:36 PM, Alexander Neundorf wrote:
On Wednesday 13 March 2013, Stephen Kelly wrote:
I think Alex' objection is only related to thinking that the case of a
header-only-library-with-automoc-generated-cxx-file should be an error.
On 03/14/2013 01:43 PM, Alexander Neundorf wrote:
Would you object a check that if a target has at least one C or Fortran
source
file, but no C++ source file, it should skipped for automoc ?
I was thinking about that approach too. Basically if the target
has at least one C++ source or *no
On 03/13/2013 08:51 PM, Matthew Woehlke wrote:
I've discovered an odd an seemingly incorrect behavior of
get_filename_component(REALPATH)... apparently there are some conditions
when it can take a canonical path and turn it *back into a symlink*.
To reproduce:
$ ls -l
lrwxrwxrwx. 1
Brad King wrote:
On 03/14/2013 01:43 PM, Alexander Neundorf wrote:
Would you object a check that if a target has at least one C or Fortran
source file, but no C++ source file, it should skipped for automoc ?
I was thinking about that approach too. Basically if the target
has at least one
On Thursday 14 March 2013, Stephen Kelly wrote:
Brad King wrote:
On 03/14/2013 01:43 PM, Alexander Neundorf wrote:
Would you object a check that if a target has at least one C or Fortran
source file, but no C++ source file, it should skipped for automoc ?
I was thinking about that
Alexander Neundorf wrote:
yes, and I think it's a bug (caused by me).
If I was a cmake user and not a developer, I would file a bug report if I
would find out that my helloworld.c suddenly links again libstdc++.so
My point was that a policy is still needed anyway.
Thanks,
Steve.
--
Powered
Hi,
I pushed the AddEqualOperator to stage, it adds the == operator to if(), which
simply string-compares the both arguments, with no variable lookup (... which
can lead to unwanted effects when using STREQUAL)
Does that look like a good solution ?
If so, I'll add tests, docs, etc., so it can
If I have a target 'foo' and I do:
target_include_directories(foo INTERFACE
$BUILD_INTERFACE:hello
$INSTALL_INTERFACE:world
)
...then in the build export file, I see the interface include
directories 'hello', which seems reasonable.
However, if I do:
target_include_directories(foo
Matthew Woehlke wrote:
...then I get 'hello;$INSTALL_INTERFACE:world;left'.
Is this expected/correct?
Nope, this is a bug.
Thanks for testing/reporting. I've pushed a fix to the next branch. Please
try that out.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware
On 2013-03-14 16:46, Stephen Kelly wrote:
Matthew Woehlke wrote:
...then I get 'hello;$INSTALL_INTERFACE:world;left'.
Is this expected/correct?
Nope, this is a bug.
Thanks for testing/reporting. I've pushed a fix to the next branch. Please
try that out.
That seems to do the trick (no more
Matthew Woehlke wrote:
On 2013-03-14 16:46, Stephen Kelly wrote:
Matthew Woehlke wrote:
...then I get 'hello;$INSTALL_INTERFACE:world;left'.
Is this expected/correct?
Nope, this is a bug.
Thanks for testing/reporting. I've pushed a fix to the next branch.
Please try that out.
That
If ARM and DSP toolchain are commandline compatible, there could be an
option to specify the architecture, like C6000 (DSP core in OMAP
processors), C2000, C6400 which map to the correct
compiler/linker/archiver/strip names.
2013/3/14 Laszlo Papp lp...@kde.org:
On Wed, Mar 13, 2013 at 10:14 PM,
On Thu, Mar 14, 2013 at 8:59 AM, Florian Reinhard
florian.reinh...@googlemail.com wrote:
If ARM and DSP toolchain are commandline compatible, there could be an
option to specify the architecture, like C6000 (DSP core in OMAP
processors), C2000, C6400 which map to the correct
Dear All,
I finally succeeded in installing gromacs 4.6.1 with prefix.
Michael you were right, I need to set GMS_DEFAULT_SUFFIX to FALSE.
Following is the command line option used :
CMAKE_PREFIX_PATH=/soft/sudip/abc/apps/fftw-3.3.3 CC=icc cmake ..
Hi,
I am a maintainer of libchewing project [1] which try to integrate cmake
recently. However, we need
unicode/wide curses library to build our tool, but cmake cannot find the
unicode/wide curses library.
This issue was already reported before [2] but is not fix yet. Is there any
plan to
On 3/14/2013 7:13 AM, ChangZhuo Chen wrote:
Hi,
I am a maintainer of libchewing project [1] which try to integrate cmake
recently. However, we need
unicode/wide curses library to build our tool, but cmake cannot find the
unicode/wide curses library.
This issue was already reported before [2]
On 03/14/2013 12:43 AM, James Bigler wrote:
I'm not sure what the expected behavior is supposed to be
IMPORTED_LINK_DEPENDENT_LIBRARIES is not about transitive linking.
That is IMPORTED_LINK_INTERFACE_LIBRARIES.
The former is only for implementation dependencies of a shared
library that are not
On 2013-03-13 18:14, Matthew Woehlke wrote:
On 2013-03-13 17:09, Matthew Woehlke wrote:
I have a project that builds a bunch of jar's with add_jar from
UseJava.cmake. Let's say we have myjar1 and myjar2. How do I write the
build rules for myjar2 such that it depends on myjar1?
It looks like
On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
This is now pushed to stage/fix-java-jar-depends. If someone
knowledgeable could have a look, that would be much appreciated.
Andreas, Nicholas?
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Thursday 14 March 2013 10:57:10 Brad King wrote:
On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
This is now pushed to stage/fix-java-jar-depends. If someone
knowledgeable could have a look, that would be much appreciated.
Andreas, Nicholas?
Hi Brad,
thanks for the mail. I've reviewed
Now that 2.8.11 supports interface include_directories on targets, is
there a way to create a library target that can be exported that has no
actual library, but *does* define interface include_directories?
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Hi,
I am getting an error in CMAKE configuration after it was updated to 2.8.7.
The line to which error is pointed :
/find_package(PythonInterp)/
Well the error is as follows :
/CMake Warning (dev) at
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:86
(INCLUDE):
File
I'm still learning (or hacking) my way around using CMake and I've had some
success in attempting to integrate a C# csproj as part of our larger CMake
build with mostly C++ and some C++/CLI projects. This is to build a solution
file for Visual Studio 2008. I am doing some customization of the
Hi,
I'm tryng to build SOCI on iOS. I was able to enter my boost path in my
~/.profile to get that running, but I'm getting stuck on finding threads.
-- Could NOT find Threads (missing: Threads_FOUND)
CMake Error at core/CMakeLists.txt:22 (message):
No thread library found
Is there a way to
On Thursday 14 March 2013, newuserhere wrote:
Hi,
I am getting an error in CMAKE configuration after it was updated to 2.8.7.
The line to which error is pointed :
/find_package(PythonInterp)/
Well the error is as follows :
/CMake Warning (dev) at
You should install boost in /usr/local with ./b2 install, then more packages
will find it. Did you do this or not?
Anyway, I just did this:
git clone git://github.com/SOCI/soci.git
cd soci
cd src
mkdir build
cd build
cmake ..
And it worked for me. So what did you do exactly?
On 2013-14-03, at
Hello,
I use cmake 2.8.10 on windows.
I would like to build several targets with cmake --build dir so the
underlying build tool to do parallel jobs.
Currently it only seems to be possible to build one target at a time, using
--target .
I use cmake 2.8.10 on windows.
I would like to build several targets with cmake --build dir so the
underlying build tool to do parallel jobs.
Currently it only seems to be possible to build one target at a time, using
--target .
You can only 'cmake' a single-target. If you want to have more targets, create
more directories: for each target one.
On 2013-14-03, at 19:07:36 , John Drescher wrote:
I use cmake 2.8.10 on windows.
I would like to build several targets with cmake --build dir so the
underlying build
Hi,
I followed your instructions.
I also modified the make files a bit according to this -
http://ares.lids.mit.edu/redmine/projects/forest-game/wiki/Building_soci_for_iOS
Though I'm not using their scripts.
I compiled to 386:Arm7 fat target. Here are the errors I get. The thread
bits are
Hmm, well I think you're missing some variables. The buildscript up on the site
could use some updates, but that should be your ticket.
On 2013-14-03, at 19:10:08 , Casey Basichis wrote:
Hi,
I followed your instructions.
I also modified the make files a bit according to this -
2013/3/14 Casey Basichis caseybasic...@gmail.com
Hi,
I followed your instructions.
I also modified the make files a bit according to this -
http://ares.lids.mit.edu/redmine/projects/forest-game/wiki/Building_soci_for_iOS
Though I'm not using their scripts.
I compiled to 386:Arm7 fat
Hi,
I've looked at the toolchain but I will read the cross compiling one. I
tried compiling SOCI with the toolchain and with those scripts I posted in
my last post.
On the SOCI mailing list they directed me to this, that suggests the
Threading may have been a problem on iOS.
On Thursday 14 March 2013, Laszlo Papp wrote:
On Thu, Mar 14, 2013 at 8:59 AM, Florian Reinhard
florian.reinh...@googlemail.com wrote:
If ARM and DSP toolchain are commandline compatible, there could be an
option to specify the architecture, like C6000 (DSP core in OMAP
processors),
Sorry about that last post - in a one two punch half of the email got
selected, deleted and then sent
I've cross compiled several libraries using
-DCMAKE_OSX_ARCHITECTURES=i386;armv7 ../
I tried compiling with the toolchain and also with the SOCI scripts I
posted earlier. The command line flags
On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf a.neundorf-w...@gmx.net
wrote:
the TI_DSP_to_TI branch on cmake stage now tries to automatically detect
the
compiler prefix and suffix and searches ar and strip accordingly.
It seems to work for me (but I can't run the binaries).
Please
2013/3/14 Casey Basichis caseybasic...@gmail.com
Sorry about that last post - in a one two punch half of the email got
selected, deleted and then sent
I've cross compiled several libraries using
-DCMAKE_OSX_ARCHITECTURES=i386;armv7 ../
I tried compiling with the toolchain and also with the
These changes will be in 2.8.11 RC1 for you to test out.
On Thu, Mar 14, 2013 at 2:54 PM, Laszlo Papp lp...@kde.org wrote:
On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
the TI_DSP_to_TI branch on cmake stage now tries to automatically
detect the
Matthew Woehlke wrote:
Now that 2.8.11 supports interface include_directories on targets, is
there a way to create a library target that can be exported that has no
actual library, but *does* define interface include_directories?
That won't be possible in 2.8.11, but will be possible in the
On Thursday 14 March 2013, Robert Maynard wrote:
These changes will be in 2.8.11 RC1 for you to test out.
Cool :-)
Before I merge it into next, could you have a look at the TI_DSP_to_TI branch,
I had some git trouble and I'm not quite sure everything is in this branch as
it should...
Thanks
Alexander Neundorf wrote:
On Thursday 14 March 2013, Robert Maynard wrote:
These changes will be in 2.8.11 RC1 for you to test out.
Cool :-)
Before I merge it into next, could you have a look at the TI_DSP_to_TI
branch, I had some git trouble and I'm not quite sure everything is in
this
Hi,
Forgive me if this issue has been discussed or is documented elsewhere,
but after some thorough perusal of the archives I didn't find anything.
When using the Xcode generator, is there a way to get find_library() and related
commands to search within the SDK directory specified by
I am sorry I was incorrect. The changes made to close bug 12405 are going
to be in RC1. These new changes aren't going to make RC1 but should be in
RC2 if we need one.
On Thu, Mar 14, 2013 at 3:39 PM, Alexander Neundorf a.neundorf-w...@gmx.net
wrote:
On Thursday 14 March 2013, Robert Maynard
On 2013-03-14 15:33, Stephen Kelly wrote:
Matthew Woehlke wrote:
Now that 2.8.11 supports interface include_directories on targets, is
there a way to create a library target that can be exported that has no
actual library, but *does* define interface include_directories?
That won't be
On 14 March 2013 18:44, Casey Basichis caseybasic...@gmail.com wrote:
On the SOCI mailing list they directed me to this, that suggests the
Threading may have been a problem on iOS.
http://stackoverflow.com/a/14198386/151641
Casey,
Thanks for posting this issue here.
Just FYI, I'm watching
On Thursday 14 March 2013, Robert Maynard wrote:
I am sorry I was incorrect. The changes made to close bug 12405 are going
to be in RC1. These new changes aren't going to make RC1 but should be in
RC2 if we need one.
I merged TI_DSP_to_TI_2 into next.
It would be great if this could still make
Hi,
I tried the tool chain. This console output shows the error. I've tried
adding the SDK path up to the include and with the iPhoneOS6.1... part
stripped off as well.
CASEYs-MacBook-Pro:build caseybasichis$ export
On Thu, Mar 14, 2013 at 8:57 PM, Alexander Neundorf a.neundorf-w...@gmx.net
wrote:
On Thursday 14 March 2013, Robert Maynard wrote:
I am sorry I was incorrect. The changes made to close bug 12405 are going
to be in RC1. These new changes aren't going to make RC1 but should be in
RC2 if we
Only for the RC1 candidate would the toolset name be wrong. We can make
sure that the proper toolset name goes into the final 2.8.11 release.
On Thu, Mar 14, 2013 at 4:57 PM, Alexander Neundorf a.neundorf-w...@gmx.net
wrote:
On Thursday 14 March 2013, Robert Maynard wrote:
I am sorry I was
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 192ef7101e800450f4130921727e287443bf6002 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 55812ab0bcf8655473535c05865a63772fbf6dac (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 533bbb474f936f1326537ba0aaf9f9a2b2b97a1a (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 7f19de3c6b559bd3529de46d2017d0a5a2b5cf10 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0dba8ff010609a2b9943f202529fa0e582dc7e65 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c47d23927e5b22d19a555795c46d51d4e3ad0851 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 25d6f1b6f4ea563b97f0663705ecbad15e5b2a8d (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index d4ef879..fdcc01e 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
set(CMake_VERSION_MAJOR 2)
set(CMake_VERSION_MINOR 8)
set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20130314
62 matches
Mail list logo
