2010/8/3 Eric Noulard eric.noul...@gmail.com:
2010/8/3 David Cole david.c...@kitware.com:
On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard eric.noul...@gmail.com wrote:
2. may always be an option because it was the behavior we had before the
component support and ALL CPack generator may handle
Hi all,
first of all many thanks for considering to provide such a functionality.
I tried it on an small example yesterday and it worked as expected
(I patched against cmake 2.8.2), a larger test will follow as soon as I
find the time.
One minor thing (maybe a different issue?),
I am not quite
Thanks Alex,
I'm new to CMake, but have of course already searched for a solution on
the web. I often found the info that CMake doesn't strip the binaries,
but no solution to that.
So is there a way to get the Release (and not the debug) build to
produce a stripped binary (under Linux
Thanks D3ck0r,
Personally I'd add
set(CMAKE_BUILD_TYPE Debug CACHE STRING
Set build type)
set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
Debug Release MinSizeRel RelWithDebInfo)
to my root project, and select option release default... or as part of
the
How about ditching the whole idea of finding the latest version and just search
for un-versioned names? If the user wants something different, she should set
PYTHON_EXECUTABLE.
Michael
On 3. Aug, 2010, at 7:37 , Michael Hertling wrote:
On 07/22/2010 02:17 PM, Marcel Loose wrote:
Hi all,
On 3. Aug, 2010, at 9:26 , Martin Wodok wrote:
Thanks D3ck0r,
Personally I'd add
set(CMAKE_BUILD_TYPE Debug CACHE STRING
Set build type)
set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
Debug Release MinSizeRel RelWithDebInfo)
to my root project, and select
Hi Michael,
Do you want stripping during build time? That's unusual... Only way I see to
do it is to wrap add_executable and add_library in a custom function and add
a POST_BUILD custom command and invoke the CMAKE_STRIP tool manually. Only
problem I see is to find the output location of
On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard eric.noul...@gmail.com wrote:
2010/8/2 Clinton Stimpson clin...@elemtech.com:
Waiting for feedback before going on
So I wondered if we were basically getting 3 modes out of this:
1. put multiple components in one components aware package
Bingo.
With more than one of *anything* installed, the find modules can only guess.
They can never know which one is correct.
In the presence of exactly one installation of something, the find modules
are wonderful.
In the presense of two or more, the find modules suck eggs for half the
users
;-) Thanks David.
One thing remains which also sucks and I don't know enough about: Windows. I
know that many software packages create registry entries naming the
installation directory etc. Hopefully they do that for each installed version
individually, but do they also create a
On Tue, Aug 3, 2010 at 8:01 AM, Michael Wild them...@gmail.com wrote:
;-) Thanks David.
One thing remains which also sucks and I don't know enough about: Windows.
I know that many software packages create registry entries naming the
installation directory etc. Hopefully they do that for each
2010/8/3 Dr. Stefan Sablatnög stefan.sablatn...@svox.com:
Hi all,
first of all many thanks for considering to provide such a functionality.
I tried it on an small example yesterday and it worked as expected
(I patched against cmake 2.8.2), a larger test will follow as soon as I
find the
2010/8/3 David Cole david.c...@kitware.com:
On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard eric.noul...@gmail.com wrote:
2. may always be an option because it was the behavior we had before the
component support and ALL CPack generator may handle an all-in-one
package.
We could add an OPTION
I'm working on replacing an antiquated custom build system with cmake on
a project which uses a mix of several flavors of Fortran as well as some
C and C++. The problem I'm running into is that FIND_MPI (and I would
guess a variety of other modules) just assume that the compiler flags
should be
2010/8/3 Eric Noulard eric.noul...@gmail.com:
2010/8/3 Dr. Stefan Sablatnög stefan.sablatn...@svox.com:
Hi all,
first of all many thanks for considering to provide such a functionality.
I tried it on an small example yesterday and it worked as expected
(I patched against cmake 2.8.2), a
On Saturday 31 July 2010, Clinton Stimpson wrote:
If you put main.moc in add_executable() then you don't have to use the
set_source_files_properties() to manually specify dependencies.
Yes, but main.moc is already #included in main.cpp so it cannout be added to
add_executable.
In KDE we are
2010/8/3 Eric Noulard eric.noul...@gmail.com:
2010/8/3 David Cole david.c...@kitware.com:
On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard eric.noul...@gmail.com wrote:
2. may always be an option because it was the behavior we had before the
component support and ALL CPack generator may handle
On Tuesday, August 03, 2010 02:07:31 pm Alexander Neundorf wrote:
On Saturday 31 July 2010, Clinton Stimpson wrote:
If you put main.moc in add_executable() then you don't have to use the
set_source_files_properties() to manually specify dependencies.
Yes, but main.moc is already #included
On 2010-08-03 07:57-0400 David Cole wrote:
When there are multiple matching installations, the developer must specify
which one he wants. The way he does that varies from module to module, but
it is always do-able by simply setting some cache values to point to the
right stuff.
I agree about
Hey,
I'd like to hard-link Qt in my application, while at the same time
allowing some of my other libraries to build as DLLs. Last time I
looked cmake just had a single 'either or' option for building either
as shared libraries or without. Is there some way to do a mixed build
like this, and more
You just need to build Qt as static libraries with the configure -static
option.
There's nothing else you need to change in your CMake setup, so you can keep
your BUILD_SHARED_LIBS flag as you want and Qt is not affected by it.
Clint
On Tuesday, August 03, 2010 04:40:50 pm Glenn Hughes
2010/8/2 Eric Noulard eric.noul...@gmail.com:
Hi All,
I did add a patch for the multiple file problem
http://public.kitware.com/Bug/view.php?id=10736
May be interested people can have a try and comment
this patch.
It adds the possibility for any CPack generators to generate multiple
On Wednesday 04 Aug 2010 1:49:36 am Clinton Stimpson wrote:
On Tuesday, August 03, 2010 02:07:31 pm Alexander Neundorf wrote:
On Saturday 31 July 2010, Clinton Stimpson wrote:
If you put main.moc in add_executable() then you don't have to use the
set_source_files_properties() to manually
On Monday 02 Aug 2010 4:59:47 pm Eric Noulard wrote:
Hi All,
I did add a patch for the multiple file problem
http://public.kitware.com/Bug/view.php?id=10736
May be interested people can have a try and comment
this patch.
It adds the possibility for any CPack generators to generate
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 4de4af4bc910addcbdd97ef373b5a04bb5824d05 (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 784431236ef0b3b5a16205623fba5fffb23aa636 (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 e6067ca969edb2f20f4fc17735d74924f534b1a5 (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 eb6d6a3708a42e35d15408a395c4b274e193aa8d (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 dac2afec2597681cc39ddf574b8a33e5743877c5 (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 68efc3ef8687ee3a09e86a3d124a710668083246 (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 d00d71e6cf3ed5f2e24e4351e141b04212cca903 (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 8c8aa7e8f64865fec6fef297c3cc564f3b6e2541 (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 08c5e475abbf5a15f8457c41941a3b0cb16b1fb0 (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 16dcaced741cd2c1c05af3f18d99a4e973569e2a (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 cbfc37dc182e8f11231f1ab1ad72ad0060be0f39 (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 976aaf45ded17774fb1523a983be9cbaf31c72dc (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 a1b9388bc3b225594af55749b72f58e9c896df10 (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 7e578b8d73c52c96d9099e329dd1e1d6f7029b87 (commit)
via
38 matches
Mail list logo
