On Wed, Apr 18, 2012 at 10:48 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 4/18/2012 1:12 PM, Richard Wackerbarth wrote:
Let me know if someone needs information from the run which has not been
posted to the dashboard.
I can bring the machine online and retrieve things.
OK, so
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13147
==
Reported By:asibilev
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13148
==
Reported By:Jim Hague
Assigned To:
Hi Folks,
FYI, I've added a new Utilities/SetupForDevelopment.sh script and some
associated helper scripts to CMake. This consolidates all the local
work tree setup steps that previously had to be done by hand:
- Prompts for Git author name/email
- Installs local commit hooks
- Adds topic
2012/4/5 Nicolas Desprès nicolas.desp...@gmail.com:
On Thu, Apr 5, 2012 at 9:44 PM, David Cole david.c...@kitware.com wrote:
[...]
It would be very simple to add a clean target that simply executes
ninja -t clean as a custom command, if the ninja generator guys
think that's a reasonable idea
On 4/18/2012 5:14 PM, Richard Wackerbarth wrote:
Bill,
I hope that your question was not directed at me. As far as Ninja is
concerned, I just set up the build-bot and check to see that it runs
each night.
In general, I have presumed that our interest is on the CMake side.
Therefore, except for
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13150
==
Reported By:Modestas Vainius
Assigned To:
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13155
==
Reported By:Mathieu Malaterre
Assigned To:
Ok, guys, catch... source base is 2.8.7.
add_subdirectory(source_dir [binary_dir]
[EXCLUDE_FROM_ALL] [NOINHERIT])
/.../
If the NOINHERIT argument is provided, the subdirectory build
configuration
will not inherit any preprocessor, compiler or linker specific
parameters.
So, wait. This intends to avoid inheritance of preprocessor, compiler
and linker stuff, but it still allows inheritance of all other
directory properties and CMake variable values...?
On Thu, Apr 19, 2012 at 5:04 AM, irukandji irukan...@voidptr.eu wrote:
Ok, guys, catch... source base is 2.8.7.
Hi,
I'm using cmake and cpack to build my project and build packages. I'm
creating a few executables in my project, let's call them EXE1 and
EXE2.
When creating different versions of these executables, I want to name
to reflect the version of the executable (let's say EXE1_1.0.0). I can
change
2012/4/19 lazyl...@gmail.com:
Hi,
I'm using cmake and cpack to build my project and build packages. I'm
creating a few executables in my project, let's call them EXE1 and
EXE2.
When creating different versions of these executables, I want to name
to reflect the version of the executable
What my thought was:
if you are adding the subdirectory, you want to keep what is stored
within
the cmake variables so you can fine grain what to use and not to use in
subdirectory or pass just some settings from caller, if this would be
also
removed there would be no way to pass anything to
If that's the case then NOINHERIT is not the correct name for this.
(Because that, to me, primarily implies CMake variable value
inheritance, and directory properties, and everything that inherits.)
On Thu, Apr 19, 2012 at 8:48 AM, irukandji irukan...@voidptr.eu wrote:
What my thought was:
Change it to whatever you want :) Search and replace is for me much
easyer
then to workaround the inheritance :)
regards,
irukandji
On 2012-04-19 14:56, David Cole wrote:
If that's the case then NOINHERIT is not the correct name for this.
(Because that, to me, primarily implies CMake variable
Hi,
My simple work model is as follows:
1) I have two projects A B, located in independant locations. Both
provide some libraries executable
2) B makes use of libraries headers provided in A
I want to launch the build of A together B thus I do:
#-
project(B)
We are trying to make cmake work with our projects, and all the targets
work fine.
The problem is that on some projects cpack -G NSIS fails because when it
tries to copy
files around it generates paths too long.
I found that CMake is able to handle these situations in theory with a
checksum
2012/4/19 Andrea Crotti andrea.crott...@gmail.com:
We are trying to make cmake work with our projects, and all the targets work
fine.
The problem is that on some projects cpack -G NSIS fails because when it
tries to copy
files around it generates paths too long.
I found that CMake is able
Depends on who knows the directories to be included. If you're in a
situation when B doesn't know which directories A will add, you can
use global properties for this purpose. Something like this:
#-
project(B)
define_property(GLOBAL PROPERTY my_include_files ...)
Hi Johannes,
Time to update again, this time for CMake 2.8.8.
Do you have time to do the update again in the next week or two?
Thanks,
David
On Thu, Jan 5, 2012 at 4:47 PM, Johannes Zarl johannes.z...@jku.at wrote:
Hi David,
This is great news! I have updated the matrix to use footnotes,
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 annotated tag, v2.8.8 has been created
at 648ff9b874eb739bde783d5e9203a883b6852edb (tag)
tagging
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 aec9c6ed79ea47a17d44ea4928e99b56df3b61a8 (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 730e964cb79902a3a1c39f12c2ddc52971da43a3 (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 7a6a6109b8a8047e4e137f963e62a2d215bd4315 (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 b5f02907649c3f075fcf44225bd259b27262a972 (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 5beb676f3159b436a03b9137eb3b5e6d1c09d62d (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 f31998df5aa0c8f30d26ece1d9a3863e5b3c1a64 (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 949724ae67778eff539a1f745ba7b8528a19 (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 3fb09c93100104797ff60f4cbc1ca10fe4754612 (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 7610e3cf0ef3b6abf1374bf0f56bad74e5091244 (commit)
from
30 matches
Mail list logo
