Nicolas Desprès wrote:
I have to confess that I never called find_package() without REQUIRED,
and I can't think about any use case right now.
The most simple one is probably the system-or-bundled one: check if the system
has a good version of some package, use the one bundled with the sources
On Thursday 09 June 2011, Nicolas Desprès wrote:
On Wed, Jun 8, 2011 at 8:08 PM, Alexander Neundorf neund...@kde.org wrote:
...
I can't think of any reason why somebody would want to use
find_package(...without REQUIRED) instead of optional_find_package().
Can somebody else see a reason
On Wednesday 08 June 2011, Brad King wrote:
On 6/8/2011 2:59 PM, Alexander Neundorf wrote:
The two things are
- BSD licensing, we did that 3 years ago:
http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc455125317
48ffb770cb1124798 -and porting to STL+cmsys, we did that now
On Thursday 09 June 2011, Alexander Neundorf wrote:
...
At build time, the logic is complex enough and it also has to be really
fast so that this should IMO be done in the C++.
It could either be a -E automoc infofile option, or a -P
CMakeAutomoc.cmake script, which then calls a new
On 6/9/2011 2:58 AM, Alexander Neundorf wrote:
This wish comes mainly from packagers, not from the developers themselves.
I am sure packagers would be happy if they had one consistent way to disable
every package any cmake checks for with a standardized option.
This is a nice goal, but I do
On 6/9/2011 4:12 AM, Alexander Neundorf wrote:
AFAIK depending on generated files via the #include does not work/is not
reliable (that's why generated files need to be added to the target).
For the Makefile generators, each target builds in three steps:
(1) Generate all custom command outputs
On Thursday 09 June 2011, Brad King wrote:
On 6/9/2011 2:58 AM, Alexander Neundorf wrote:
This wish comes mainly from packagers, not from the developers
themselves. I am sure packagers would be happy if they had one
consistent way to disable every package any cmake checks for with a
On 6/9/2011 8:47 AM, Alexander Neundorf wrote:
So, if I would create a dummy foo.automoc file from automoc, and added this
to
the target, this would make sure that any files created as side-effects of
this custom command would already exist when any source files are compiled ?
Yes. I
On Thu, Jun 9, 2011 at 9:19 AM, Brad King brad.k...@kitware.com wrote:
On 6/9/2011 8:50 AM, Alexander Neundorf wrote:
What if the FindFoo.cmake script calls find_package(Bar) and does
not require it but the project also does find_package(Bar) and does? I'm
sure there are more cases I haven't
On Thursday, June 09, 2011 01:23:09 am Alexander Neundorf wrote:
On Wednesday 08 June 2011, Brad King wrote:
On 6/8/2011 2:59 PM, Alexander Neundorf wrote:
The two things are
- BSD licensing, we did that 3 years ago:
Am 09.06.2011 07:35, schrieb Michael Hertling:
On 06/09/2011 07:13 AM, Andreas Naumann wrote:
Am 08.06.2011 20:43, schrieb Andreas Pakulat:
On 08.06.11 20:00:54, Andreas Naumann wrote:
Am 08.06.2011 15:02, schrieb Eric Noulard:
2011/6/8 Andreas
2011/6/8 Andreas Naumann andreas-naum...@gmx.net:
Am 08.06.2011 15:02, schrieb Eric Noulard:
2011/6/8 Andreas Naumannandreas-naum...@gmx.net:
Am 08.06.2011 11:56, schrieb Eric Noulard:
2011/6/8 Andreas Naumannandreas-naum...@gmx.net:
Hi @all,
I have some problem with the library
Hi,
I see strange rpath in binaries inside the build tree, linked in such
a way that these can run from the build tree. In some cases the rpath
list contains a fairly large amount of :-s, sometimes only one at
the end. Already one colon is unnecessary (at least in my case), but
the case when
Hi,
I just noticed that CTest 2.8.4 incorrectly parses valgrind's memcheck
output because it does not always take into account that numbers
reported by valgrind can be larger than 1,000 and then will contain a
comma as thousand-delimiter. Therefore, many errors/potential errors
are not correctly
Hi,
I see strange rpath in binaries inside the build tree, linked in such
a way that these can run from the build tree. In some cases the rpath
list contains a fairly large amount of :-s, sometimes only one at
the end. Already one colon is unnecessary (at least in my case), but
the case
Hi,
I just noticed that CTest 2.8.4 incorrectly parses valgrind's memcheck
output because it does not always take into account that numbers
reported by valgrind can be larger than 1,000 and then will contain a
comma as thousand-delimiter. Therefore, many errors/potential errors
are not
On 06/09/2011 01:11 PM, Rolf Eike Beer wrote:
Hi,
I just noticed that CTest 2.8.4 incorrectly parses valgrind's memcheck
output because it does not always take into account that numbers
reported by valgrind can be larger than 1,000 and then will contain a
comma as thousand-delimiter.
Hi,
Am 09.06.2011 13:20, schrieb Michael Wild:
On 06/09/2011 01:11 PM, Rolf Eike Beer wrote:
Hi,
I just notied that CTest 2.8.4 incorrectly parses valgrind's memcheck
output because it does not always take into account that numbers
reported by valgrind can be larger than 1,000 and then will
Hi,
Yes. And please use unified diff format. Preferred is if you could
do a checkout of CMake git and commit your patch (locally) and then
do git format-patch HEAD^ and attach the resulting 0001-* file to
the bug.
Just did so. Hope the patch format is correct. Please advise, if not.
Hi,
I have a big project with several subfolders. In one subfolder's cmake
file I have e.g.
INSTALL(TARGETS test DESTINATION ${CMAKE_INSTALL_PREFIX} CONFIGURATIONS RELEASE)
Now when I call make install on linux or build INSTALL project in
MSVC the whole project is built prior to installation of
LinkedIn
Santosh Mahto requested to add you as a connection on LinkedIn:
--
Robert,
I'd like to add you to my professional network on LinkedIn.
- Santosh
Accept invitation from Santosh Mahto
Hello,
I've managed to get an NSIS project up and running in VIsual Studio with
CPack, but I can't figure out how to determine which configuration type
is being built. Is it possible to write up a CMakeLists that will run
through different conditionals based off of the Build Configuration
I've managed to get an NSIS project up and running in VIsual Studio with
CPack, but I can't figure out how to determine which configuration type is
being built. Is it possible to write up a CMakeLists that will run through
different conditionals based off of the Build Configuration Type
I've managed to get an NSIS project up and running in VIsual Studio with
CPack, but I can't figure out how to determine which configuration type is
being built. Is it possible to write up a CMakeLists that will run through
different conditionals based off of the Build Configuration Type
On 06/09/2011 03:34 PM, Dominik Szczerba wrote:
Hi,
I have a big project with several subfolders. In one subfolder's cmake
file I have e.g.
INSTALL(TARGETS test DESTINATION ${CMAKE_INSTALL_PREFIX} CONFIGURATIONS
RELEASE)
Now when I call make install on linux or build INSTALL project
On 06/09/2011 01:08 PM, Rolf Eike Beer wrote:
Hi,
I see strange rpath in binaries inside the build tree, linked in such
a way that these can run from the build tree. In some cases the rpath
list contains a fairly large amount of :-s, sometimes only one at
the end. Already one colon is
On 06/09/2011 08:18 AM, Andreas Naumann wrote:
Am 09.06.2011 07:35, schrieb Michael Hertling:
On 06/09/2011 07:13 AM, Andreas Naumann wrote:
Am 08.06.2011 20:43, schrieb Andreas Pakulat:
On 08.06.11 20:00:54, Andreas Naumann wrote:
Am 08.06.2011 15:02, schrieb Eric
On 06/08/2011 07:26 AM, Campbell Barton wrote:
There were some system headers giving warnings compiling on linux,
since I like to have warnings as errors, and not edit system headers,
I used:
include_directories(SYSTEM dir1 dir2 ...)
... for system directories only.
However this does not
if(SUPPORTS_PARALLEL_BUILD_TYPE)
CMAKE_INSTALL_CONFIG_NAME is set to the current configuration name
(DEbug, release, minsizerel) as chosen in the visual studio
environment so to choose which you build - you choose which you
build.
It doesn't package multiple configurations at once into a
Aaron,
Thanks. Please see my comments in the ticket you reopened with the patch
you sent in yesterday.
BTW -- If you would like to volunteer to take ownership of this module I
would be happy to hand it over to someone else. Since I no longer use
Visual Studio I'm probably the wrong maintainer
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 86d987a02fc659a840fc4d01c641c301d99ea1c8 (commit)
via
31 matches
Mail list logo
