Hi all,
Using 2.8.2 I'm trying to make a rule to create a timestamp header, but only if
a certain file has changed, like so:
ADD_CUSTOM_COMMAND(
OUTPUT src/timestamp.h
COMMAND tools/win32/timestamper
ARGS src/timestamp.h
DEPENDS Version.cmake
WORKING_DIRECTORY
On 12/10/2010 09:23 AM, Robert Bielik wrote:
Hi all,
Using 2.8.2 I'm trying to make a rule to create a timestamp header, but
only if a certain file has changed, like so:
ADD_CUSTOM_COMMAND(
OUTPUT src/timestamp.h
COMMAND tools/win32/timestamper
ARGS src/timestamp.h
DEPENDS
Michael Wild skrev 2010-12-10 10:28:
1. Always use absolute paths (e.g. using CMAKE_CURRENT_SOURCE_DIR and
CMAKE_CURRENT_BINARY_DIR).
2. Never create output in the source tree.
Thanks, I'll try that.
/Rob
___
Powered by www.kitware.com
Visit
Hi all,
Is there a way to let FIND_LIBRARY prefer static over shared
libraries?
I know of one, but that's a bit hack-ish:
SET(CMAKE_FIND_LIBRARY_SUFFIXES .a)
Are there other options?
Ideally, I would like to be able to specify this per library search,
i.e. as an option to FIND_LIBRARY.
This are great news, thank you very much
-Ursprüngliche Nachricht-
Von: David Cole [mailto:david.c...@kitware.com]
Gesendet: Donnerstag, 09. Dezember 2010 22:10
An: Roman Wüger
Cc: CMake MailingList
Betreff: Re: [CMake] CMake 2.8.4 release scheduled for next month
That one is assigned
On 12/10/2010 06:36 AM, Marcel Loose wrote:
Is there a way to let FIND_LIBRARY prefer static over shared
libraries?
I know of one, but that's a bit hack-ish:
SET(CMAKE_FIND_LIBRARY_SUFFIXES .a)
Are there other options?
Ideally, I would like to be able to specify this per library
On 12/9/2010 5:42 PM, Marco Atzeri wrote:
any hope to solve
http://public.kitware.com/Bug/view.php?id=10122
with the discussed change of policy for cygwin ?
Yes, I have put that on the roadmap. I hope to have time to create the
policy before the release. Thanks for the reminder.
-Bill
There are a few things we have already started to do that should help
with the bug tracker issue.
1. We hare having 4 releases of CMake each year. After each release we
post to the list and ask people to vote for bugs they would like fixed
in the next release.
2. We are now sending all
You can do it all in one step with ctest, but you have to write a
ctest -S script, and call that... Inside it, you can do a configure
from scratch using the ctest_configure(...) command. Then you'll see
all the configure output submitted to the dashboard.
Poke around the wiki and the
On Fri, Dec 10, 2010 at 10:42 AM, Wojciech Migda wojtek.g...@interia.pl wrote:
You can do it all in one step with ctest, but you have to write a
ctest -S script, and call that... Inside it, you can do a configure
from scratch using the ctest_configure(...) command. Then you'll see
all the
On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
I have a third idea that we have not yet tried:
What do people think of automatically closing bugs if they are not modified
for some period of time (say 6 months). They can always be reopened if the
closed. By
Great news for everyone in Europe who would like to purchase the VTK User's
Guide or Mastering CMake - we now have these two titles available on
amazon.co.uk (thanks to our new
officehttp://www.kitware.com/news/home/browse/306in Lyon, France).
You can get the VTK User's Guide
On 12/10/2010 11:01 AM, Pau Garcia i Quiles wrote:
On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffmanbill.hoff...@kitware.com wrote:
I have a third idea that we have not yet tried:
What do people think of automatically closing bugs if they are not modified
for some period of time (say 6 months).
Mantis lets you customize bug resolution. Maybe a new category of
resolution could be created. Instead of Won't Fix it could be
Lack of Activity?
David
From: cmake-boun...@cmake.org [cmake-boun...@cmake.org] On Behalf Of Bill
Hoffman
On 12/10/2010 12:48 PM, Thompson, David C wrote:
Mantis lets you customize bug resolution. Maybe a new category of
resolution could be created. Instead of Won't Fix it could be
Lack of Activity?
It would have to be something that made it clear, that unless someone
cares enough to re-open it,
On Thu, Dec 9, 2010 at 3:57 PM, Tyler Roscoe ty...@cryptio.net wrote:
So are you ready to start collecting candidate bugs for 2.8.4? I
nominate this one!
http://www.vtk.org/Bug/view.php?id=11561
Thanks,
tyler
On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote:
We are still
On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote:
On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
I have a third idea that we have not yet tried:
What do people think of automatically closing bugs if they are not modified
for some period of time (say 6 months).
Hello everyone,
i currently try to setup a make configuration where the debug and the
release version of my programm should be built into different subfolders.
My problem is that the installation does not find the created executable.
The directory stucture looks like this:
/massmailer
On Fri, Dec 10, 2010 at 7:56 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
On the other hand, on KDE, when we moved to KDE4, we closed almost all
KDE3-related bugs without checking if they had been fixed. It did not
made too much sense to keep bug reports around unless they were
feature
2010/12/10 Bill Hoffman bill.hoff...@kitware.com:
There are a few things we have already started to do that should help with
the bug tracker issue.
1. We hare having 4 releases of CMake each year. After each release we
post to the list and ask people to vote for bugs they would like fixed
On Fri, Dec 10, 2010 at 08:11:45PM +0100, Louis Hoefler wrote:
-- Build files have been written to: /root/massmailer/Debug
Probably not a good idea to be doing this kind of thing as root.
[100%] Built target massmailer
-- Configuring done
-- Generating done
-- Build files have been written
Greetings,
I have my cmake L-plates firmly on ( with a Qt4 project I am stumbling on )
I have these in CMakeLists.txt file:-
FIND_PACKAGE( Qt4 REQUIRED )
INCLUDE( ${QT_USE_FILE} )
set(QT_USE_OPENGL TRUE)
set(QT_USE_QTSVG TRUE )
SET( QT_USE_QTXML TRUE )
SET( QT_USE_QT3SUPPORT
On 10.12.10 22:09:29, luxInteg wrote:
Greetings,
I have my cmake L-plates firmly on ( with a Qt4 project I am stumbling on )
I have these in CMakeLists.txt file:-
FIND_PACKAGE( Qt4 REQUIRED )
INCLUDE( ${QT_USE_FILE} )
set(QT_USE_OPENGL TRUE)
set(QT_USE_QTSVG TRUE )
SET(
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 b25d5af1a5edf5b2bd39381bccf7dfef2fbefc59 (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 3a8428979e93b052c50dcbeda4c9e88f7c6ac6be (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 b7ea1c5879ce1025828f7b4ecc153a4aed67604d (commit)
via
26 matches
Mail list logo
