Am Thursday 22 July 2010 schrieb Freddie Witherden:
I wish to know how I can have CMake/CPack determine if it is possible to
build an RPM or DEB package on the system (so if all the required
utilities are installed) and if so to go ahead and package them.
FIND_PROGRAM(rpmbuild) or things like
This shouldn't work, because you could build deb packages on redhat systems
with cpack without any deb tools installed
Am 22.07.2010 um 08:02 schrieb Rolf Eike Beer e...@sf-mail.de:
Am Thursday 22 July 2010 schrieb Freddie Witherden:
I wish to know how I can have CMake/CPack determine if it
Am Thursday 22 July 2010 schrieb norulez:
This shouldn't work, because you could build deb packages on redhat systems
with cpack without any deb tools installed
Well, in that case you don't need to search for anything debian-like and can
always use that generator. Then you only need to check
On 22. Jul, 2010, at 3:09 , Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM, Alan W.
How can I find out which build type is used? Because if I didn't define
CMAKE_BUILD_TYPE, this variable is uninitialized.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
On 22. Jul, 2010, at 8:38 , norulez wrote:
How can I find out which build type is used? Because if I didn't define
CMAKE_BUILD_TYPE, this variable is uninitialized.
That depends. For single-configuration generators (i.e. Makefile based), the
user has to set CMAKE_BUILD_TYPE. If it is empty,
On 2010-07-22 03:09+0200 Michael Hertling wrote:
In summary, my point is: Even if the loops are swapped, we wouldn't get
a solution that works well in real-world scenarios so I doubt if it's
worth the effort [...].
Hi Michael:
I think find issues are a really important topic so I am glad you
2010/7/22 Freddie Witherden fred...@witherden.org:
Hi,
I use CPack in my project to build binary packages as an alternative to `make
install`. However, I am interested in getting my project to automatically
detect which packages to build.
Currently I have TGZ set and then require the user
Forgot the list
-- Forwarded message --
From: Eric Noulard eric.noul...@gmail.com
Date: 2010/7/22
Subject: Re: [CMake] CPack: Detecting if to build DEB/RPM packages
To: norulez noru...@me.com
2010/7/22 norulez noru...@me.com:
This shouldn't work, because you could build deb
On 22. Jul, 2010, at 9:18 , Alan W. Irwin wrote:
On 2010-07-22 03:09+0200 Michael Hertling wrote:
[...] one should
prefer to improve the find modules and get rid of those non-equivalent
alternatives after the NAMES option, in particular hardcoded version
lists, and freshly developed
I want to set the debug prefix on windows when I build in debug mode, so I
check if Debug is in CMAKE_BUILD_TYPE.
I use both, Visual Studio and the MinGW compiler
Am 22.07.2010 um 08:53 schrieb Michael Wild them...@gmail.com:
On 22. Jul, 2010, at 8:38 , norulez wrote:
How can I find out
On 22. Jul, 2010, at 9:55 , norulez wrote:
I want to set the debug prefix on windows when I build in debug mode, so I
check if Debug is in CMAKE_BUILD_TYPE.
I use both, Visual Studio and the MinGW compiler
Am 22.07.2010 um 08:53 schrieb Michael Wild them...@gmail.com:
On 22. Jul,
On Thu, 2010-07-22 at 03:09 +0200, Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM,
2010/7/21 Brian Davis bitmi...@gmail.com:
I agree with Olaf. CMake needs better error reporting for parameter
checking on macros and functions
Good idea but this seems difficult to do.
In Olaf case it may be doable to spit out a better error message explicitely
saying that T was considered as
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
Hi Michael and others,
I mostly agree with what your saying. However, IMHO, you refer to a
perfect world situation, where all Find modules properly use VERSION
to specify a version number and do not abuse NAMES for that.
I know
On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard eric.noul...@gmail.com wrote:
http://public.kitware.com/Bug/view.php?id=9900
What's stopping this bug from being fixed?
Olaf
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
2010/7/22 Olaf van der Spek olafvds...@gmail.com:
On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard eric.noul...@gmail.com wrote:
http://public.kitware.com/Bug/view.php?id=9900
What's stopping this bug from being fixed?
From my point of view: lack of time :-)
However for my next CMake developping
On Thu, Jul 22, 2010 at 10:56 AM, Eric Noulard eric.noul...@gmail.com wrote:
2010/7/22 Olaf van der Spek olafvds...@gmail.com:
On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard eric.noul...@gmail.com wrote:
http://public.kitware.com/Bug/view.php?id=9900
What's stopping this bug from being fixed?
2010/7/22 Olaf van der Spek olafvds...@gmail.com:
On Thu, Jul 22, 2010 at 10:56 AM, Eric Noulard eric.noul...@gmail.com wrote:
2010/7/22 Olaf van der Spek olafvds...@gmail.com:
On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard eric.noul...@gmail.com
wrote:
On Thu, Jul 22, 2010 at 11:33 AM, Eric Noulard eric.noul...@gmail.com wrote:
Note that you can search the bug tracker using filter for CPack or DEB etc...
I can set Category = CPack, but where can I set DEB?
Olaf
___
Powered by www.kitware.com
Visit
I'd just like to confirm that I've seen exactly the same bug since
upgrading from 2.8.0 to 2.8.1.
I've submitted a bug at:
http://public.kitware.com/Bug/view.php?id=11026
On 21/07/10 16:06, Bill Hoffman wrote:
On 7/21/2010 10:41 AM, Emmanuel Christophe wrote:
Hi Dave,
Thanks for the
2010/7/22 Olaf van der Spek olafvds...@gmail.com:
On Thu, Jul 22, 2010 at 11:33 AM, Eric Noulard eric.noul...@gmail.com wrote:
Note that you can search the bug tracker using filter for CPack or DEB etc...
I can set Category = CPack, but where can I set DEB?
There is no DEB (nor TGZ, NSIS
With respect to fixing 10718, *if* we fix it (and that's a big *if* because
it's a sweeping change in behavior with largely unpredictable real world
consequences), I suggest that we:
- have both loops in CMake,
- and that the default behavior remains the same as it is now,
- and that we activate
Thanks for reminding me of my old idea ;-)
http://www.cmake.org/pipermail/cmake/2010-May/036993.html
I think that would be the cleanest solution. Extract the loop body into a
function and then have two separate loops calling the same function.
Michael
On 22. Jul, 2010, at 13:19 , David Cole
Arjen, I saw your response about wrapping add_library on the list, but for
some reason it didn't get to my inbox.
I'm not sure what you mean by wrapping, are you talking about a code change,
or some sort of macro? So far, I haven't been able to come up with any way of
jamming -X64 into the
Hi Kelly,
I'm using cmake to migrate from a legacy build system. The source consists of C
C++ Fortran and Fortran90. I think -in all- there are 15 binaries.
One of the problems for us is linking. Cmake somehow decides to take compiler X
to link executable Y. But in some cases it didn't use the
Hi all,
That sounds like a good solution. It is probably the cleanest way to
solve this controversy. OTOH, it adds two extra keywords that, of
course, are not used in existing (now sometimes failing) Find macros.
IMHO, solving the issue by changing CMake's behaviour would be
preferable, using a
Dear all,
I'm stucked with the evaluation of an environment variable when running
parallel tests from ctest_test command. This environment variable is
the 'TMPDIR' containing the machine file needed for mpiexec.
After removing the uneeded lines, my submission sequence looks like the
following:
Brad,
I found another repository with jom binaries. It works fine with 0.9.4.
Apparently the original link I used to download JOM was ancient.
Thanks,
Arjen
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Verweij, Arjen
Sent: woensdag 21
Hi there,
I am trying to build ITK from a toplevel directory, my application
is setup simply like this:
$ cat CMakeLists.txt
project(MySuperApp)
find_package(VTK REQUIRED)
message(${VTK_VERSION})
add_subdirectory(ITK) # contains the ITK source
Since cmake 2.8 find_package now sets VTK_VERSION
Hello CMakers!
I am coding with some teammates that use Xcode as their IDE. Everything is
working fine thanks to CMake, except for the following situation:
1. Developer X checkouts a project from svn and uses CMake to generate their
Xcode project
2. Developer X succesfully compiles their
On 22 Jul 2010, at 07:02, Rolf Eike Beer wrote:
Am Thursday 22 July 2010 schrieb Freddie Witherden:
I wish to know how I can have CMake/CPack determine if it is possible to
build an RPM or DEB package on the system (so if all the required
utilities are installed) and if so to go ahead and
On 22. Jul, 2010, at 15:57 , David Ojeda wrote:
Hello CMakers!
I am coding with some teammates that use Xcode as their IDE. Everything is
working fine thanks to CMake, except for the following situation:
1. Developer X checkouts a project from svn and uses CMake to generate their
Xcode
On Thu, Jul 22, 2010 at 4:08 PM, Freddie Witherden
fred...@witherden.org wrote:
I'll try adding a check for `rpmbuild` to my CMakeLists before enabling RPM
packages. This seems quite a nice solution as users should always get TGZ
and DEB and RPM if possible. From what I gather producing
On 07/22/2010 09:43 AM, Mathieu Malaterre wrote:
Hi there,
I am trying to build ITK from a toplevel directory, my application
is setup simply like this:
$ cat CMakeLists.txt
project(MySuperApp)
find_package(VTK REQUIRED)
message(${VTK_VERSION})
add_subdirectory(ITK) # contains the
Hi,
install(DIRECTORY xbt DESTINATION include FILES_MATCHING PATTERN *.h)
install(TARGETS xbt DESTINATION lib)
How do I exclude empty dirs, like .svn from being created?
Why is it necessary to specify DESTINATION lib? Can't it use a default?
Olaf
___
Good idea but this seems difficult to do.
In Olaf case it may be doable to spit out a better error message
explicitely
saying that T was considered as the language argument of PROJECT,
because PROJECT is a builtin
I was just agreeing with Olaf and stating a issue I ran into on error
You could switch to git :-) so there are not all these .svn dirs splatted
all over the tree... One of the many things I hate about svn and love about
git. But in all seriousness try using the PATTERN svn EXCLUDE. I have
not used this, let me know if it works.
install(DIRECTORY icons scripts/
On Thu, Jul 22, 2010 at 4:56 PM, Brian Davis bitmi...@gmail.com wrote:
You could switch to git :-) so there are not all these .svn dirs splatted
all over the tree... One of the many things I hate about svn and love about
git. But in all seriousness try using the PATTERN svn EXCLUDE. I have
It does, but should not be necessary. Why aren't empty dirs excluded by
default?
svn directory is not empty.. it is hidden, but not empty... at least it
shouldn't be if the svn is working correctly. I am probably missing
something here and should give this a try myself as I currently am using
It's perfectly clear to me now, but I bet I'm not the first (or last!)
person to run into issues like this and get roadblocked.
Every software task seems to have its stumbling block.
In Medical Image Processing we spend a lot of our time debugging
issues related to how image volumes are
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir. Shouldn't all variants have a unique name?
Olaf
___
Powered by www.kitware.com
Visit other Kitware
On Thu, Jul 22, 2010 at 5:05 PM, Brian Davis bitmi...@gmail.com wrote:
It does, but should not be necessary. Why aren't empty dirs excluded by
default?
svn directory is not empty.. it is hidden, but not empty... at least it
True, but note the *.h filter. After the filter, the dir is empty,
so
Thank you Michael,
I was afraid about this but I had to ask to try anyways :s
On Thu, Jul 22, 2010 at 4:09 PM, Michael Wild them...@gmail.com wrote:
On 22. Jul, 2010, at 15:57 , David Ojeda wrote:
Hello CMakers!
I am coding with some teammates that use Xcode as their IDE. Everything
On 22. Jul, 2010, at 17:07 , kent williams wrote:
It's perfectly clear to me now, but I bet I'm not the first (or last!)
person to run into issues like this and get roadblocked.
Every software task seems to have its stumbling block.
In Medical Image Processing we spend a lot of our time
True, but note the *.h filter. After the filter, the dir is empty,
so it doesn't make any sense to create it at install time.
Yep I tried it and as you say .svn appears even though the filter should
grab .h files
So I echo Olafs's question why is .svn dir grabed when .h filter should be
enough?
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Verweij, Arjen
Sent: Thursday, July 22, 2010 6:59 AM
To: cmake@cmake.org
Subject: Re: [CMake] how to set ar/ranlib flags per target
Hi Kelly,
I'm using cmake to migrate from a legacy
Hello,
It seems the debug/release default configuration are only built for VStudio
suites.
Anyway I am trying to simulated such for the codeblocks IDE, this is how I
did my CMakeLists.txt :
project( myapp )
add_executable( Release WIN32 ${my_src_files} )
target_link_libraries( Release
On Thu, Jul 22, 2010 at 04:57:50PM +0200, Olaf van der Spek wrote:
Why aren't empty dirs excluded by default?
Because if they were excluded, we would have someone on the list next
month asking why she can't create empty directories with install()
commands.
tyler
On Thu, Jul 22, 2010 at 7:43 PM, Tyler Roscoe ty...@cryptio.net wrote:
On Thu, Jul 22, 2010 at 04:57:50PM +0200, Olaf van der Spek wrote:
Why aren't empty dirs excluded by default?
Because if they were excluded, we would have someone on the list next
month asking why she can't create empty
It turns out that you can do this (yay!), it's just tricky to discover how
(well, it was for ME!).
I got to wondering when CMake was injecting the STATIC_LIBRARY_FLAGS into the
ar command line. The answer to this is also the reason why my setting
LINK_FLAGS didn't have any effect on the ar
On 7/22/10 10:08 AM, Olaf van der Spek wrote:
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir. Shouldn't all variants have a unique name?
Olaf
set(CMAKE_DEBUG_POSTFIX _d)
See the documentation
I just wanted to post this solution. But why don't you set this in the
top-level CMakeLists.txt file? Also, you can use a loop over the languages and
string(REGEX REPLACE ...) to make things a bit safer:
foreach(lang C CXX)
foreach(type CREATE APPEND)
string(REGEX REPLACE
On Thu, Jul 22, 2010 at 9:23 PM, Ryan Pavlik rpav...@iastate.edu wrote:
On 7/22/10 10:08 AM, Olaf van der Spek wrote:
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir. Shouldn't all variants have
On 7/22/2010 3:23 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 9:23 PM, Ryan Pavlikrpav...@iastate.edu wrote:
On 7/22/10 10:08 AM, Olaf van der Spek wrote:
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only
Shouldn't this be done automatically?
No way. Not all users would want that on all platforms that CMake
supports. Also it is very easy to add a single line to your
CMakeLists.txt file..
What about shared vs static lib?
Shared vs static runtime?
x64 vs x86?
You can do all of that similarly
On Thu, Jul 22, 2010 at 10:32 PM, Ryan Pavlik rpav...@iastate.edu wrote:
Unfortunately there are as many ways to denote these differences as there
are projects. However, unless you're setting the ARCHIVE_OUTPUT_DIRECTORY,
LIBRARY_OUTPUT_DIRECTORY, or RUNTIME_OUTPUT_DIRECTORY (and if you are, I
And then what? Having two DLLs with the same name is not going to
work. Same for import or static libs.
It would work fine if the dlls for multiple configurations were not
all dumped in 1 folder. That is how I have used cmake for 2+ years.
John
___
On Thu, Jul 22, 2010 at 10:41 PM, John Drescher dresche...@gmail.com wrote:
And then what? Having two DLLs with the same name is not going to
work. Same for import or static libs.
It would work fine if the dlls for multiple configurations were not
all dumped in 1 folder. That is how I have
On Thu, Jul 22, 2010 at 4:43 PM, Olaf van der Spek olafvds...@gmail.com wrote:
On Thu, Jul 22, 2010 at 10:41 PM, John Drescher dresche...@gmail.com wrote:
And then what? Having two DLLs with the same name is not going to
work. Same for import or static libs.
It would work fine if the dlls for
On Jul 22, 2010, at 4:38 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 10:32 PM, Ryan Pavlik rpav...@iastate.edu
wrote:
Unfortunately there are as many ways to denote these differences as
there
are projects. However, unless you're setting the
ARCHIVE_OUTPUT_DIRECTORY,
On Thu, Jul 22, 2010 at 10:46 PM, John Drescher dresche...@gmail.com wrote:
On Thu, Jul 22, 2010 at 4:43 PM, Olaf van der Spek olafvds...@gmail.com
wrote:
On Thu, Jul 22, 2010 at 10:41 PM, John Drescher dresche...@gmail.com wrote:
And then what? Having two DLLs with the same name is not going
On Thu, Jul 22, 2010 at 10:46 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Ya know , I go back and forth on this. In my own projects I will give my
libs a _debug suffix because I end up installing both debug and release into
a local directory and my FindXXX.cmake scripts know to look
2010/7/22 Olaf van der Spek olafvds...@gmail.com:
On Thu, Jul 22, 2010 at 4:08 PM, Freddie Witherden
fred...@witherden.org wrote:
I'll try adding a check for `rpmbuild` to my CMakeLists before enabling RPM
packages. This seems quite a nice solution as users should always get TGZ
and DEB
On Thu, Jul 22, 2010 at 11:08 PM, Eric Noulard eric.noul...@gmail.com wrote:
Yes it should, if ever the proposed patch
http://public.kitware.com/Bug/view.php?id=10292
is merged as-is.
What's the delay?
Olaf
___
Powered by www.kitware.com
Visit
On Jul 22, 2010, at 4:54 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 10:46 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Ya know , I go back and forth on this. In my own projects I will
give my
libs a _debug suffix because I end up installing both debug and
release into
a
2010/7/22 Olaf van der Spek olafvds...@gmail.com:
On Thu, Jul 22, 2010 at 11:08 PM, Eric Noulard eric.noul...@gmail.com wrote:
Yes it should, if ever the proposed patch
http://public.kitware.com/Bug/view.php?id=10292
is merged as-is.
What's the delay?
I do not have an authoritative answer,
On Thu, Jul 22, 2010 at 11:14 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
So here is what really happens with Visual Studio. When you invoke CMake
you select to build Shared libraries and a Win64 application. These are
the basics. Visual Studio will create a subdirectory for Debug
I'll add my two cents - I like that the names are the same, it allows
me to switch the release out with the debug and not have to recompile
the executable. Besides, I doubt your interface changes because of
debug or release mode - so the .lib should be exactly the same.
Though I suppose if you
You _can_ very easily do this if you want. The code is out there in the
wild in the form of macros that can be invoked from CMake that will set all
of this up for you. You just have to look for it (or ask the right person...
)
I do this for my shared libraries although I do not put them
On Jul 22, 2010, at 5:25 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:14 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
So here is what really happens with Visual Studio. When you
invoke CMake
you select to build Shared libraries and a Win64 application.
These are
On Thu, Jul 22, 2010 at 11:36 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
How does the loader find the DLL?
Because when Visual Studio launches an executable it will look in the same
directory that the executable resides in for libraries to load. Now, if you
have 2 completely
On Jul 22, 2010, at 5:42 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:36 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
How does the loader find the DLL?
Because when Visual Studio launches an executable it will look in
the same
directory that the executable resides in
On Thu, Jul 22, 2010 at 11:50 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Of course I have separate projects. I didn't write libz... Did you?
DLLs should be *shared*. There shouldn't be a need for me to copy them
to my app dir.
Well,
Actually I _did_ put a CMake wrapper on LibZ
On Jul 22, 2010, at 5:40 PM, J Decker wrote:
On Thu, Jul 22, 2010 at 2:37 PM, John Drescher
dresche...@gmail.com wrote:
On Thu, Jul 22, 2010 at 5:25 PM, J Decker d3c...@gmail.com wrote:
I'll add my two cents - I like that the names are the same, it
allows
me to switch the release out with
On Jul 22, 2010, at 5:53 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:50 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Of course I have separate projects. I didn't write libz... Did you?
DLLs should be *shared*. There shouldn't be a need for me to copy
them
to my app
I'm on the other side of that one. I don't know how many _days_ I have
wasted because I linked my debug version with a release version of something
else and had the strangest errors and app crashes. After pulling my hair out
trying to debug something that does not need to be debugged I finally
On Fri, Jul 23, 2010 at 12:00 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Yes, it was done already (For some of them) which is what I started with.
But what you find is that the CMake files that someone wrote are kinda
tweaked for their project and don't really work for yours so you
On Jul 22, 2010, at 6:17 PM, Olaf van der Spek wrote:
On Fri, Jul 23, 2010 at 12:00 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Yes, it was done already (For some of them) which is what I started
with.
But what you find is that the CMake files that someone wrote are
kinda
On Fri, Jul 23, 2010 at 12:23 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Tweaked in what way?
Usually they have special CMake variables for the specific project that the
original sources were being built as part of. These all have to be cleaned
up. Then sometimes you would like to
On 07/22/2010 10:17 AM, Marcel Loose wrote:
On Thu, 2010-07-22 at 03:09 +0200, Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael
On 07/22/2010 10:36 AM, Michael Wild wrote:
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
Hi Michael and others,
I mostly agree with what your saying. However, IMHO, you refer to a
perfect world situation, where all Find modules properly use VERSION
to specify a version number
On 07/22/2010 08:33 AM, Michael Wild wrote:
On 22. Jul, 2010, at 3:09 , Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling
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 0c084dd899c28c9ff65caacf3f917bcaf1a6726f (commit)
from
84 matches
Mail list logo
