Why is TIMESTAMP misleading?
Per default it currently outputs year, month, day, hour, minute and second.
This includes both a date (a day on a calendar) as well as time (time of
day).
Timestamp I'd define as both date and time bound to an event (here the
call or the (sub-)command).
Date
On Fri, Sep 28, 2012 at 2:28 AM, Nils Gladitz glad...@sci-vis.de wrote:
Why is TIMESTAMP misleading?
Per default it currently outputs year, month, day, hour, minute and second.
This includes both a date (a day on a calendar) as well as time (time of
day).
Timestamp I'd define as both date
Am 2012-09-28 08:44, schrieb Nils Gladitz:
Sorry about the indentation ... I've still got a bit of trouble
switching between coding conventions.
Yeah, kernel style is the only sane one ;)
On that note, are there documented coding conventions, coding
guidelines or similar somewhere?
My
On 09/24/2012 08:19 AM, Brad King wrote:
On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
This is now in the export-sets-2 branch on stage, including a basic test.
Comments ? Ok to merge into next ?
Yes, thanks.
This commit is a problem:
On Friday 28 September 2012, Brad King wrote:
On 09/24/2012 08:19 AM, Brad King wrote:
On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
This is now in the export-sets-2 branch on stage, including a basic
test.
Comments ? Ok to merge into next ?
Yes, thanks.
This commit is a
On 09/28/2012 01:21 PM, Alexander Neundorf wrote:
The imported target bld_testExe2lib in ExportBuildTree.cmake links against
the
imported target exp_testExe2libImp created in exp.cmake.
So if exp.cmake is included after ExportBuildTree.cmake this imported library
does not exist yet.
On Friday 28 September 2012, Brad King wrote:
On 09/28/2012 01:21 PM, Alexander Neundorf wrote:
The imported target bld_testExe2lib in ExportBuildTree.cmake links
against the imported target exp_testExe2libImp created in exp.cmake.
So if exp.cmake is included after ExportBuildTree.cmake
The following topic branches were merged to master and deleted from the
stage today:
$ git fetch --all --prune
Fetching origin
Fetching stage
From git://cmake.org/stage/cmake
64d64b4..908f46a master - stage/master
x [deleted] (none) - stage/ctest-svn-non-interactive
x
By the way, the KWStyle fixes are already done. If you are going to extend
any of the existing stage topics, please fetch them and sync with the stage
first.
Thanks,
D
On Fri, Sep 28, 2012 at 4:08 PM, David Cole david.c...@kitware.com wrote:
The following topic branches were merged to master
On Friday 28 September 2012, David Cole wrote:
...
The following branches still need some more work. If they're ready by
Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to
have to push these features into the next release instead.
# generator-expression-target-properties
On Friday 28 September 2012, Alexander Neundorf wrote:
On Friday 28 September 2012, Brad King wrote:
On 09/28/2012 01:21 PM, Alexander Neundorf wrote:
The imported target bld_testExe2lib in ExportBuildTree.cmake links
against the imported target exp_testExe2libImp created in exp.cmake.
David Cole wrote:
The following branches still need some more work. If they're ready by
Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to
have to push these features into the next release instead.
# generator-expression-target-properties | master=0 next=1
You'll have
On 09/28/2012 04:22 PM, Stephen Kelly wrote:
David Cole wrote:
The following branches still need some more work. If they're ready by
Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to
have to push these features into the next release instead.
#
Brad King wrote:
On 09/28/2012 04:22 PM, Stephen Kelly wrote:
David Cole wrote:
The following branches still need some more work. If they're ready by
Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to
have to push these features into the next release instead.
#
On 09/28/2012 04:21 PM, Alexander Neundorf wrote:
There is an updated version now on stage.
The behaviour of cmExportBuildFileGenerator now basically is the same as it
was before.
The collected target exports are not considered at all anymore, error
handling
and APPEND mode should work
On 09/28/2012 04:56 PM, Brad King wrote:
On 09/28/2012 04:21 PM, Alexander Neundorf wrote:
There is an updated version now on stage.
The behaviour of cmExportBuildFileGenerator now basically is the same as it
was before.
The collected target exports are not considered at all anymore, error
On 09/28/2012 04:35 PM, Stephen Kelly wrote:
The generator-expression-target-properties branch merges to master cleanly.
The export-sets-2 branch was never merged into it.
I don't understand what blocked merging it to master, but I'll leave it up
to you to handle.
I rewrote/squashed
Hello CMake developers,
Is the DO_NOT_ADD_TO_PATH_ with the ending underscore in
share/cmake-2.8/Modules/NSIS.template.in on line 887 intended?
Everywhere else in that file the underscore is lacking. It looks wrong to me. I
am using CMake 2.8.9 which as I understood it is the latest version.
Hi
2012/7/24 Alexander Neundorf a.neundorf-w...@gmx.net:
Maybe you can use external_project() for that subdirectory ?
I have not been successful with that command. Probably, I have
misunderstood something. Please see this example:
my_project
|
+- CMakeLists.txt
|
+- external
On Fri, Sep 28, 2012 at 4:19 AM, Ingolf Steinbach
ingolf.steinb...@gmail.com wrote:
Hi
2012/7/24 Alexander Neundorf a.neundorf-w...@gmx.net:
Maybe you can use external_project() for that subdirectory ?
I have not been successful with that command. Probably, I have
misunderstood
CMake downloads our third party libraries from a central repository
and we have a manifest.cmake module where we define the following:
- Library alias (the library's base name, such as boost, bdb, openssl)
- Library version (e.g. 2.1.5)
- Library iteration (A counter that is incremented if a
On Fri, Sep 28, 2012 at 3:30 PM, Robert Dailey rcdailey.li...@gmail.comwrote:
CMake downloads our third party libraries from a central repository
and we have a manifest.cmake module where we define the following:
- Library alias (the library's base name, such as boost, bdb,
openssl)
-
On Fri, Sep 28, 2012 at 2:58 PM, David Cole david.c...@kitware.com wrote:
On Fri, Sep 28, 2012 at 3:30 PM, Robert Dailey rcdailey.li...@gmail.com
wrote:
CMake downloads our third party libraries from a central repository
and we have a manifest.cmake module where we define the following:
-
On Fri, Sep 28, 2012 at 4:42 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
On Fri, Sep 28, 2012 at 2:58 PM, David Cole david.c...@kitware.com wrote:
On Fri, Sep 28, 2012 at 3:30 PM, Robert Dailey rcdailey.li...@gmail.com
wrote:
CMake downloads our third party libraries from a central
On Fri, Sep 28, 2012 at 4:42 PM, Robert Dailey rcdailey.li...@gmail.comwrote:
On Fri, Sep 28, 2012 at 2:58 PM, David Cole david.c...@kitware.com
wrote:
On Fri, Sep 28, 2012 at 3:30 PM, Robert Dailey rcdailey.li...@gmail.com
wrote:
CMake downloads our third party libraries from a
On Fri, Sep 28, 2012 at 4:25 PM, David Cole david.c...@kitware.com wrote:
What version of CMake are you using? Server side redirects should be
followed properly since this commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef491f78218e255339278656bf6dc26073fef264
Which has been in
What I'm saying is that it _does_ work properly, which is the problem
Ha!!
Wish all our problems were that things worked properly!
:-)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic
)
+set(CMake_VERSION_TWEAK 20120928)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
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 61ec1b7a9069bee2a1f8f4785d653667cabda819 (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 0ce6f269cc717aec242253be45fcdf8bb784cb16 (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 bf78717374f6533b289c5e2930799d47933da75b (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 45befd67be8e595a110b07b37d99173a7742ef0a (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 af5fac8d171a41c526c9f0ebc732366ca2139296 (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 a5682374ac3605c34ba595ac9932d6426f699c63 (commit)
via
34 matches
Mail list logo
