On Wednesday 06 July 2011, Alexander Neundorf wrote:
Hi,
cmake has a CHECK_SYMBOL_EXISTS() macro for testing whether a symbol exists
in a header /library.
In KDE we have a slightly modified version of this,
CHECK_CXX_SYMBOL_EXISTS(), which basically does the same, but using C++,
so C
Hi,
in KDE we have two macros macro_push_required_vars() and
macro_pop_required_vars().
They are intended to be used before setting one or more of the
CMAKE_REQUIRED_INCLUDES/DEFINITIONS/etc. variables for a specific test, so
that after the check the previous state can be easily restored. It
Hi,
in KDE we have a simple macro which helps with creating a
FooConfigVersion.cmake for installation along the FooConfig.cmake file.
Since that Version.cmake file in most cases looks basically the same, I
thought it is a good idea to provide such a basic file, and the only thing
which has to
On Wednesday 06 July 2011, Alexander Neundorf wrote:
On Monday 04 July 2011, Brad King wrote:
On 07/03/2011 12:23 PM, Alexander Neundorf wrote:
On Monday 20 June 2011, Brad King wrote:
On 06/17/2011 05:09 PM, Alexander Neundorf wrote:
I improved it somewhat, so IMO it is basically
Hi,
in KDE we have a copy of CHECK_CXX_SOURCE_COMPILES() which supports imported
targets in CMAKE_REQUIRED_LIBRARIES:
http://websvn.kde.org/branches/KDE/4.5/kdelibs/cmake/modules/CheckCXXSourceCompiles.cmake?revision=1143427view=markup
On Wednesday 27 July 2011, Eric Wing wrote:
On 7/26/11, Alexander Neundorf neund...@kde.org wrote:
Hi,
I just had a look at FindGIF.cmake and FindFreetype.cmake.
Both have similar code:
...
What about the two PATH_SUFFIXES lib64 and lib ? They shouldn't be
necessary.
Or, how
On Thursday 07 July 2011, Alexander Neundorf wrote:
On Thursday 07 July 2011, Brad King wrote:
On 7/6/2011 4:00 PM, Alexander Neundorf wrote:
Since that Version.cmake file in most cases looks basically the same
They're only the same within a specific community's versioning scheme
On Friday 29 July 2011, Brad King wrote:
On 07/18/2011 03:43 PM, Alexander Neundorf wrote:
...
Another question: the cmake.m4 is based on the m4-file for pkgconfig,
which has the GPL header at the top. So, the cmake.m4 still has that
header at the top.
Is this a problem ?
Yes. We
On Monday 01 August 2011, Alexander Neundorf wrote:
On Monday 01 August 2011, Brad King wrote:
On 07/31/2011 04:09 PM, Alexander Neundorf wrote:
I'm not sure which syntax I like better. The one with the macro feels
more high-level, but maybe hides too much what is actually going
On Monday 08 August 2011, Brad King wrote:
On 8/8/2011 4:24 AM, Johan Björk wrote:
This has been discussed a billion times, so I'll keep it short.
Problem: Some parts of the build requires a environment variable to be
set Solution: Several workarounds, use custom commands, wrapper
Hi Stephen :-)
On Thursday 11 August 2011, Stephen Kelly wrote:
Hi,
In this build log the test for -fvisibility=hidden results in success, but
when the flag is used it fails:
http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259
I'm guessing that compiler treats -ffoo
On Tuesday 16 August 2011, Alexander Neundorf wrote:
...
There is now a branch AutomocForQt on the cmake stage.
Docs and a test are still missing.
It has a test now. Docs are still missing.
Alex
___
cmake-developers mailing list
cmake-developers
On Tuesday 16 August 2011, Alexander Neundorf wrote:
On Tuesday 16 August 2011, Alexander Neundorf wrote:
...
There is now a branch AutomocForQt on the cmake stage.
Docs and a test are still missing.
It has a test now. Docs are still missing.
Now it also has docs.
I haven't merged
On Tuesday 16 August 2011, David Cole wrote:
2011/8/16 Alexander Neundorf neund...@kde.org:
On Tuesday 16 August 2011, Alexander Neundorf wrote:
On Tuesday 16 August 2011, Alexander Neundorf wrote:
...
There is now a branch AutomocForQt on the cmake stage.
Docs and a test
On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote:
Stephen Kelly steveire@... writes:
Alexander Neundorf wrote:
Would it be possible to make CMAKE_AUTOMOC imply
CMAKE_INCLUDE_CURRENT_DIR?
All the best,
Steve.
Is it still possible to consider this? It's
On Sunday, September 18, 2011 07:11:58 PM Marcus D. Hanwell wrote:
On Sun, Sep 18, 2011 at 6:39 AM, Alexander Neundorf neund...@kde.org
wrote:
On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote:
Stephen Kelly steveire@... writes:
Alexander Neundorf wrote:
Would
On Thursday, September 22, 2011 03:00:33 PM Rolf Eike Beer wrote:
On Thursday, September 22, 2011 01:52:51 PM Rolf Eike Beer wrote:
From 3f500a5c655cc4c12ecf6f774602b2a10cae0365 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer e...@sf-mail.de
Date: Thu, 22 Sep 2011 13:48:15 +0200
Tell
On Tuesday 27 September 2011, Rolf Eike Beer wrote:
On Thursday, September 22, 2011 03:00:33 PM Rolf Eike Beer wrote:
On Thursday, September 22, 2011 01:52:51 PM Rolf Eike Beer wrote:
From 3f500a5c655cc4c12ecf6f774602b2a10cae0365 Mon Sep 17 00:00:00
2001
From: Rolf Eike Beer
Hi,
I just merged the branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse into next, it
fixes http://public.kitware.com/Bug/view.php?id=12392 .
It's a small patch, and helps people using Eclipse + cmake + ccache.
Can this still make it into 2.8.6 please ?
Thanks
Alex
--
Powered by www.kitware.com
On Saturday 01 October 2011, David Cole wrote:
Brad and Bill and I will look at this Monday.
We are closing in on the final 2.8.6 release. If we take changes Monday,
we'll merge them, await the dashboard results on Tuesday morning, and then
build the final 2.8.6. If we take no changes, I'll
On Sunday 02 October 2011, Rolf Eike Beer wrote:
On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf neund...@kde.org
wrote:
If library bar internally uses symbols from foo,
it needs to link against foo.
Correct.
But if bar doesn't expose symbols from foo in its
interface
On Tuesday 04 October 2011, Peter Kümmel wrote:
On 03.10.2011 15:03, Brad King wrote:
On 10/2/2011 1:41 PM, Peter Collingbourne wrote:
I have modified the commit message to include more details, and pushed
a modified branch to github.
I've fetched the latest version of the branch.
On Friday 07 October 2011, Andrey Ponomarenko wrote:
Hello,
I have an idea to improve the CMake build system by integrating with the
abi-compliance-checker [1] tool. It's a tool for checking for API/ABI
backward compatibility of C/C++ libraries. In the Java world there is an
alternative
Hi,
I'm currently trying to add support for the source_group() command to the
Eclipse project generator.
It's not as straighforward as I expected.
I expected that if I do
source_group(Foo FILES main.cpp)
in the CMakeLists.txt, that then in the generate step, there would be a
cmSourceGroup
Hi,
I just used ProcessorCount.cmake the first time.
I noticed a small issue:
AFAIK module file names in cmake use CamelCase, while the macros/functions use
underscores: SomeCoolStuff.cmake - some_cool_stuff()
ProcessorCount.cmake doesn't do this, the function is named processorcount()
IMO we
On Tuesday 25 October 2011, Stephen Kelly wrote:
...
I think I read somewhere that next gets re-branched from master
periodically. How often does that happen?
Usually every Tuesday.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Monday 31 October 2011, David Faure wrote:
Hi Alex,
The latest changes in cmake-git (probably the merge of
AutomocFindQ_OBJECTAlwaysInHeader) break the compilation of kde-frameworks.
This is for fixing http://public.kitware.com/Bug/view.php?id=12533
Before:
Generating
Hi,
when using out-of-source builds and the Eclipse CDT project generator, a
linked resource is created in the Eclipse project file, which points to
CMAKE_SOURCE_DIR, so the user can browse the source directory.
Now, when CMAKE_BINARY_DIR is a subdirectory of CMAKE_SOURCE_DIR (e.g.
On Sunday 23 October 2011, Alexander Neundorf wrote:
Hi,
I just used ProcessorCount.cmake the first time.
I noticed a small issue:
AFAIK module file names in cmake use CamelCase, while the macros/functions
use underscores: SomeCoolStuff.cmake - some_cool_stuff()
ProcessorCount.cmake
On Tuesday 01 November 2011, Eric Noulard wrote:
2011/11/1 Alexander Neundorf neund...@kde.org:
...
and I'd be very happy if this could be solved.
Me too.
I'll dig a little bit on the Eclipse side again, but generating 2
files in the source does not look like a big deal.
The thing
On Tuesday 01 November 2011, Brad King wrote:
On 10/31/2011 5:20 PM, Alexander Neundorf wrote:
Not sure what the other cmake developers would think about supporting an
additional file format for the Config.cmake files, e.g. xml or json, so
they could be easily used and generated also
On Tuesday 01 November 2011, Brad King wrote:
On 11/1/2011 1:20 PM, Alexander Neundorf wrote:
Would you prefer XML, JSON or something else ?
I have no preference. If the format is simple enough to parse in CMake
code then it can't be too hard to parse with a C++ implementation later
On Tuesday 01 November 2011, craig.sc...@csiro.au wrote:
...
If you do that, you create a circular dependency, since CMake requires Qt
to build its GUI application. Yes, you could build CMake's command line
tools only, then Qt, then build CMake's GUI app, or alternatively you
could install
Hi,
in ccmake, cmake::GetCMakeCommand() returns a wrong path when ccmake was
invoked from the PATH.
CMakeCommand is in ccmake computed this way (in cmCursesMainForm.cxx):
std::string whereCMake=cmSystemTools::GetProgramPath(this-Args[0].c_str());
whereCMake += /cmake;
...
On Wednesday 02 November 2011, Stephen Kelly wrote:
On 11/02/2011 06:32 PM, David Faure wrote:
#include foo.moc
#include moc_foo.cpp
This would have generated twice the same moc file, I think. IMO this
is really confusing.
Well there is no reason to include both, unless
On Sunday 06 November 2011, Thiago Macieira wrote:
On Sunday, 6 de November de 2011 18:42:42 Alexander Neundorf wrote:
On Wednesday 02 November 2011, Stephen Kelly wrote:
On 11/02/2011 06:32 PM, David Faure wrote:
#include foo.moc
#include moc_foo.cpp
This would have
On Sunday 06 November 2011, Stephen Kelly wrote:
Stephen Kelly wrote:
Issues:
* I have only tried to implement this with the makefile generator and
have so far only tested it with Unix Makefiles. One of the bugs says
XCode can't do source-level includes. Can it do target-level includes?
On Monday 07 November 2011, Alexander Neundorf wrote:
On Sunday 06 November 2011, Stephen Kelly wrote:
Hi,
As discussed on the cmake user mailing list, I'm interesting in
implementing the feature of target specific and configuration specific
include
directories.
http
On Wednesday 09 November 2011, Peter Collingbourne wrote:
On Tue, Oct 04, 2011 at 11:21:00PM +0200, Peter Kümmel wrote:
On 04.10.2011 23:19, Peter Kümmel wrote:
On 03.10.2011 15:03, Brad King wrote:
On 10/2/2011 1:41 PM, Peter Collingbourne wrote:
I have modified the commit message to
On Saturday 12 November 2011, Alexander Neundorf wrote:
Hi,
I added a branch CheckImportedFileExistenceInConfigDotCMakeFiles cmake
stage.
This is the commit:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=1b12babe0cef55a0d5531a9d0d453a15598eb467
Alex
--
Powered by www.kitware.com
On Monday 14 November 2011, Brad King wrote:
On 11/12/2011 3:53 PM, David Cole wrote:
And, in my opinion, if there are multiple possible causes of the
problem then we should enumerate them in a message to the user,
just as you've done here in this email back to me. And we should try
On Monday 14 November 2011, you wrote:
On 11/14/2011 4:01 PM, Alexander Neundorf wrote:
Instead of adding the code to the bottom of GenerateImportPropertyCode
please create a separate method next to it for that part.
Done, in an updated version
On Tuesday 15 November 2011, Brad King wrote:
On 11/15/2011 1:24 PM, David Cole wrote:
On Tue, Nov 15, 2011 at 1:19 PM, Alexander Neundorfneund...@kde.org
wrote:
function(check_for_file _file _target)
if(NOT EXISTS _file)
message(FATAL_ERROR ... long error message...)
On Wednesday 16 November 2011, Alexandru Ciobanu wrote:
Hi Brad,
...
Advantages of TRE:
- API very similar to standard regex.h (i.e. easy to integrate with
CMake) - supports wide characters
- compiles on many platforms Windows, AIX, HP-UX, you name it.
What do you think about TRE?
On Thursday 17 November 2011, Alexandru Ciobanu wrote:
Hi everyone,
[ CMake + TRE ]
I was able to make CMake use TRE, by changing the
RegularExpression.{cxx,hxx.in} files.
I ran the CMake tests, and 100% pass. See the attached log file.
(NOTE: Bootstrap, complex, complexOne were
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
On Wednesday 02 November 2011, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
On Monday 31 October 2011, David Faure wrote:
This is a typical (kde) case
On Tuesday 22 November 2011, Brad King wrote:
On 11/22/2011 10:03 AM, Stephen Kelly wrote:
Brad King wrote:
We will have to require that the install(EXPORT)
commands be invoked in dependency order (ex. A before B). That way when
the command installing ExportB is writing library B's
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/22/2011 06:20 PM, Alexander Neundorf wrote:
Using Qt5 or Qt4 ?
Qt4.
There seems to be several problems:
* KDE does include foo.moc if it wants the header file to be moc'd.
This is 'incorrect' compared to what qmake expects
On Tuesday 22 November 2011, Alexander Neundorf wrote:
On Tuesday 22 November 2011, Stephen Kelly wrote:
...
This is not uncommon in both KDE and in Qt itself, or any other project
where it makes sense to put a QObject-inherited class in the _p.h as an
internally used class. See for example
On Tuesday 22 November 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Tuesday 22 November 2011, Brad King wrote:
On 11/22/2011 10:03 AM, Stephen Kelly wrote:
Brad King wrote:
We will have to require that the install(EXPORT)
commands be invoked in dependency order (ex
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
...
Please give the RestoreAutmocKDECompatibility branch on cmake stage a
try. It should work again, but print a warning if a file includes a
moc_foo.cpp, but no foo.moc, and contains
On Tuesday 22 November 2011, Peter Collingbourne wrote:
On Tue, Nov 15, 2011 at 06:54:01PM +0100, Nicolas Desprès wrote:
On Tue, Nov 15, 2011 at 5:29 PM, Bill Hoffman
bill.hoff...@kitware.comwrote:
On 11/11/2011 9:36 PM, Peter Collingbourne wrote:
Note that this generator is *nix only
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/22/2011 08:43 PM, Alexander Neundorf wrote:
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
...
Please give the RestoreAutmocKDECompatibility branch on cmake stage a
try
On Wednesday 23 November 2011, David Cole wrote:
On Wed, Nov 23, 2011 at 2:09 PM, David Cole david.c...@kitware.com wrote:
On Wed, Nov 23, 2011 at 2:03 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 11/23/2011 12:51 PM, Brad King wrote:
On 11/23/2011 12:48 PM, Brad King wrote:
On
On Thursday 24 November 2011, Stephen Kelly wrote:
Hi there,
I am working on installing CMake config files from the Qt repository so
that there is less need for a FindQt.cmake.
The motivation is that between releases of Qt and CMake, the features of Qt
get out of sync with the features
On Friday 25 November 2011, Stephen Kelly wrote:
Stephen Kelly wrote:
Hi there,
I am working on installing CMake config files from the Qt repository so
that there is less need for a FindQt.cmake.
By the way, it would be very helpful if anyone tried to build and test this
on windows
On Friday 25 November 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Friday 25 November 2011, Stephen Kelly wrote:
Stephen Kelly wrote:
Hi there,
I am working on installing CMake config files from the Qt repository
so that there is less need for a FindQt.cmake
...a somewhat related idea: if it will be possible to set include
directories per target, and since it is already possible to set compile flags
per target, it would be nice if I could also set a property on targets which
keeps them from using the global settings at all.
Something like
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/22/2011 10:03 PM, Alexander Neundorf wrote:
Now when I try to build the frameworks branch using the cmake next
branch, I get:
AUTOMOC: error:
/home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The
file includes
On Tuesday 29 November 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
I can't generate the files. I'm asking people with windows and mac
setups to generate them and post them for review. I don't have those
setups.
Just the ones for Linux would already help :-)
I managed to get
On Tuesday 29 November 2011, Brad King wrote:
On 11/29/2011 10:53 AM, Stephen Kelly wrote:
Qt5Core_LIBRARY is intended to be the thing that users would use in the
CMakeLists.txt.
I've had another read of the Modules/readme.txt and I guess I need to
change it to be consistent.
So
On Wednesday 30 November 2011, Stephen Kelly wrote:
Brad King wrote:
On 11/30/2011 9:09 AM, Stephen Kelly wrote:
Brad King wrote:
Alex was proposing simply to provide the singular name as a variable
but not
to cache it. The only reason to cache a variable is when we're
searching and
On Wednesday 30 November 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Tuesday 29 November 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
I can't generate the files. I'm asking people with windows and mac
setups to generate them and post them for review. I don't have
On Wednesday 30 November 2011, Brad King wrote:
On 11/29/2011 2:28 PM, Alexander Neundorf wrote:
...a somewhat related idea: if it will be possible to set include
directories per target, and since it is already possible to set compile
flags per target, it would be nice if I could also set
On Wednesday 30 November 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/22/2011 10:03 PM, Alexander Neundorf wrote:
Now when I try to build the frameworks branch using the cmake next
branch, I get:
AUTOMOC: error
On Thursday 01 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
Thanks.
diff --git a/tier1/solid/solid/audiointerface.cpp
b/tier1/solid/solid/audiointerface.cpp
index ddf6cbc..98e42b2 100644
--- a/tier1/solid/solid/audiointerface.cpp
+++ b/tier1/solid/solid
On Thursday 01 December 2011, David Cole wrote:
...
You have two topics on the stage with common parent commits:
AutomocIncludedDotMocFileHandling (not presently in next) and
RestoreAutmocKDECompatibility (which is presently in next)...
Are you planning to keep both of these, or are you
On Friday 02 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
You said that you can't detect this case, but why do you have to? Isn't
there already a check for the Q_OBJECT macro in the cpp file? Wouldn't
the logic be 'if the basename.moc file is included
On Sunday 04 December 2011, Stephen Kelly wrote:
David Cole wrote:
I, for one, would really like to see per-target include directories in
2.8.7, even without per-config support to start with. Then, add the
per-config support / new generator expressions in a later release.
That seems
On Tuesday 06 December 2011, Brad King wrote:
On 12/6/2011 1:13 PM, Alexander Neundorf wrote:
Does that look like it should cover all use cases, for peopling wanting
to selectively use some things from e-c-m, and fearing that something
would break if they simply would make everything
On Tuesday 06 December 2011, Alexander Neundorf wrote:
Hi,
On Monday 07 November 2011, Brad King wrote:
On 11/6/2011 6:12 AM, Stephen Kelly wrote:
ecm_copy_modules(${CMAKE_BINARY_DIR}/modules FindFoo.cmake
FindBlub.cmake
Hi,
I have a small macro/function which I need often during buildsystem debugging:
function(PRINT_VARIABLES)
set(msg )
foreach(var ${ARGN})
if(msg)
set(msg ${msg} ; )
endif()
set(msg ${msg}${var}=\${${var}}\)
endforeach()
message(STATUS ${msg})
Hi,
in current CMake HEAD automoc has two modes: strict and not strict.
In strict mode it is behaves exactly how the documentation says:
If an #include statement like #include moc_foo.cpp is found, the Q_OBJECT
class declaration is expected in the header, and moc is run on the header
file.
If
On Sunday 11 December 2011, Alexander Neundorf wrote:
Hi,
I have a small macro/function which I need often during buildsystem
debugging:
function(PRINT_VARIABLES)
set(msg )
foreach(var ${ARGN})
if(msg)
set(msg ${msg} ; )
endif()
set(msg ${msg}${var
On Thursday 15 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
And, again a question regarding wording, currently the warnings
generated by automoc say Better do this and that for a more robust
build. I'd like to have a better way to express it.
Use this and that for STRICT
On Friday 16 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Thursday 15 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
And, again a question regarding wording, currently the warnings
generated by automoc say Better do this and that for a more robust
On Sunday 18 December 2011, Alexander Neundorf wrote:
On Friday 16 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Thursday 15 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
And, again a question regarding wording, currently the warnings
generated
On Monday 19 December 2011, David Cole wrote:
Alex,
Can you take a look at this and see if you know why QtAutomoc is
failing on this one dashboard?
http://cdash.org/CDash/testDetails.php?test=126108609build=1833949
I had a look, the output looks good:
Automoc for target codeeditorLib
On Monday 19 December 2011, Clinton Stimpson wrote:
On Monday, December 19, 2011 01:59:37 pm Alexander Neundorf wrote:
On Monday 19 December 2011, David Cole wrote:
Alex,
Can you take a look at this and see if you know why QtAutomoc is
failing on this one dashboard?
http
Hi,
yesterday I pushed the GNUInstallDirs-DebianMultiarch branch to stage.
This has only one commit, it adds support for multiarch on Debian ti
CMAKE_INSTALL_LIBDIR.
I'd like to get that into 2.8.7, but I didn't want to merge it into next
without having it reviewed by you.
So, can you please
On Tuesday 20 December 2011, David Cole wrote:
rc2 is tomorrow. And we've already merged in what we're going to accept for
it.
Unless there's something drastically wrong with rc2, I'm hoping it's
the last rc before the final 2.8.7.
So this one may have to wait.
I merged it into next now.
On Tuesday 03 January 2012, Eric Noulard wrote:
Sorry sent too soon, finger slipped.
...
I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH
which seems to be reserved for cross-compiling whereas
CMAKE_PREFIX_PATH
CMAKE_INCLUDE_PATH
CMAKE_PROGRAM_PATH
On Sunday 08 January 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Sunday 08 January 2012, Stephen Kelly wrote:
Hi,
I don't think I've ever seen a direct answer to this question.
AFAIK, yes, they should.
FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib
Hi,
here comes a quite lengthy mail on issues I see in KDE but also in general
with install dirs and CMake.
in KDE we define a set of variables which hold the install destinations for
several different file types:
EXEC_INSTALL_PREFIX(${CMAKE_INSTALL_PREFIX})
On Wednesday 11 January 2012, Rolf Eike Beer wrote:
Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
with
On Wednesday 11 January 2012, Brad King wrote:
...
To support the fully flexible version, the developer must calculate the
relative path from the configured CONFIG_INSTALL_DIR (where the
Config.cmake file goes) to the configured INCLUDE_INSTALL_DIR.
It's not too hard. See ITK for
Hi,
the variable CMAKE_REQUIRED_LIBRARIES is used by several of the check-modules
for listing additional libraries which should be linked.
It is common to use variables set by Find-modules for this, e.g.
set(CMAKE_REQUIRED_LIBRARIES ${JPEG_LIBRARIES} )
Now, if the module did not simply set
On Friday 20 January 2012, Brad King wrote:
On 1/20/2012 8:57 AM, Yury G. Kudryashov wrote:
Brad King wrote:
I do not think that explanation is correct. The find_package command
in Config mode will set everything as needed.
Yes, so the old explanation is incorrect.
The role of
On Friday 20 January 2012, Brad King wrote:
On 1/19/2012 11:49 AM, Alexander Neundorf wrote:
On Thursday 19 January 2012, Brad King wrote:
I think a full solution to this will end up duplicating a lot of the
logic that CMake already has in its C++ code for link dependency
analysis. I
On Wednesday 25 January 2012, Eric Noulard wrote:
2012/1/25 Brad King brad.k...@kitware.com:
On 1/24/2012 5:50 PM, Eric Noulard wrote:
cmake --help-module CPackComponent
or any other (untouched module)
cmake --help-module FindQt4
you'll see that the extra space are there as well.
On Wednesday 08 February 2012, David Cole wrote:
The stage is intended only for topics that are imminently going to be
merged to 'next'...
The following CMake topic branches have been on the stage for quite some
time without being merged to 'next':
On Monday 30 January 2012, David Cole wrote:
...
From your original post:
So when ImageMagick is installed everything behaves as always. But if no
ImageMagick is installed behaviour was this:
find_package(ImageMagick) - ImageMagick_FOUND = TRUE
This is simply clearly incorrect,
On Monday 13 February 2012, Brad King wrote:
On 2/13/2012 4:52 PM, Alexander Neundorf wrote:
we are hoping that more and more libraries will install Config.cmake
files (and for kdelibs this is actually happening right now), so we
should make sure it is straighforward to create proper
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
Brad King wrote:
On 2/13/2012 4:52 PM, Alexander Neundorf wrote:
we are hoping that more and more libraries will install Config.cmake
files (and for kdelibs this is actually happening right now), so we
should make sure
On Tuesday 14 February 2012, Brad King wrote:
On 2/14/2012 1:26 PM, Alexander Neundorf wrote:
Well, CMakeConfigHelpers.cmake would be shipped with cmake, so as long as
the Config.cmake file says
cmake_minimum_required(VERSION 2.8.8)
it would be fine.
...and we have to maintain
On Tuesday 14 February 2012, Alexander Neundorf wrote:
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
will substitute @PACKAGE_INCLUDE_INSTALL_DIR@ by ../../../include
Hi,
when I use a Find-module to search for a package, I get a nice error message
if the package could not be found.
If I use
find_package(Foo)
and rely on Config-mode, cmake produces an error message which doesn't help
the user:
~/src/extra-cmake-modules/example/b$ make rebuild_cache
Running
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 6:32 AM, Alexander Neundorf wrote:
Done, and pushed to stage.
I added the prefix cmake_ to the function, and added a test for it.
Looks good, thanks.
However now that I look at the end result I realize that the functionality
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 8:19 AM, Alexander Neundorf wrote:
Comments, objections ?
The entire point of find_package's interface is that the caller
does not need to care how the package is found, and the actual
method used for the find can change under
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 10:15 AM, Alexander Neundorf wrote:
On Thursday 16 February 2012, Brad King wrote:
In hindsight that name was poorly chosen. I'd really like to see
package in the name because they are package configuration files.
Otherwise
101 - 200 of 596 matches
Mail list logo
