On Monday 05 July 2010, David Cole wrote:
Hi all,
Now that we have released CMake 2.8.2 last Monday, and we have switched to
this new workflow using branches in the git repository, *now* would be a
great time to prioritize bug fixes for the next release of CMake.
We are leaning towards
On Friday 06 August 2010, Eric Noulard wrote:
2010/8/6 Alexander Neundorf neund...@kde.org:
On Friday 06 August 2010, Eric Noulard wrote:
...
I think I missed the fact that you did not used component GROUPS
at all in the first place :-)
Sorry I didn't follow closely...
What
On Saturday 14 August 2010, you wrote:
...
find_package command, it makes a lot of sense to use that same
exact-case name as a prefix for the variables set by that find module.
My hope is that with the conversion pain removed,
I'm afraid this wouldn't remove my personal (KDE's) conversion
On Tuesday 21 September 2010, Alan W. Irwin wrote:
On 2010-09-20 16:20-0400 Bill Hoffman wrote:
BTW, this type of code is not allowed in CMake:
if (fi!=files.begin()) os ;;
Needs to be:
if((fi!=files.begin())
{
os ;;
}
If you want a consistent coding style in CMake, I
On Thursday 23 September 2010, Alexander Neundorf wrote:
On Wednesday 15 September 2010, David Cole wrote:
I am happy to announce that CMake 2.8.3 has entered the release
candidate stage! You can find the source and binaries here:
http://www.cmake.org/files/v2.8/?C=M;O=D
Following
On Thursday 23 September 2010, Clinton Stimpson wrote:
On Thursday, September 23, 2010 01:40:02 pm Alexander Neundorf wrote:
...
This was committed here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b55da4c688bbf55b442908
46 4e0f7e2e41c937a3 which has as commit message Add cross
Hi,
there are currently 169 RESOLVED issues for cmake:
http://public.kitware.com/Bug/view_all_bug_page.php?filter=40216
Should they all just be changed to CLOSED ?
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
On Saturday 25 September 2010, Eric Noulard wrote:
2010/9/25 Alexander Neundorf neund...@kde.org:
[..]
The other option would be to make sure that
INCLUDE(FindPackageHandleStandardArgs)
when used in cmake's own module would always load
FindPackageHandleStandardArgs.cmake from cmake, i.e
On Sunday 26 September 2010, Alexander Neundorf wrote:
On Saturday 25 September 2010, Eric Noulard wrote:
2010/9/25 Alexander Neundorf neund...@kde.org:
[..]
The other option would be to make sure that
INCLUDE(FindPackageHandleStandardArgs)
when used in cmake's own module would
Hi,
I'd like to set up subprojects for KDE, but I think this is right now not
feasible because it needs too much manual work:
when setting up subprojects for cdash, somebody has to write a Project.xml:
Project name=”Tutorial”
SubProject name=”Libs”
/SubProject
SubProject name=”Exes”
On Tuesday 28 September 2010, David Cole wrote:
When I fix a bug, I mark it as resolved.
I expect that somebody else who cares about the bug will come along behind
me and double-check me on it. So... I leave it to the reporter or some
other interested party to close it.
If there is
On Tuesday 28 September 2010, David Cole wrote:
Ambitious. I like it.
I would prefer seeing this implemented as a CMake-language function. And
You mean to implement this as a cmake script, and not as a built-in function ?
adding anything necessary to CMake in order to support implementing it
On Tuesday 28 September 2010, Brad King wrote:
On 09/28/2010 03:24 PM, Alexander Neundorf wrote:
Currently there are CMAKE_CURRENT_LIST_FILE and CMAKE_CURRENT_LIST_LINE.
Should it be CMAKE_CURRENT_LIST_FILE_DIR or CMAKE_CURRENT_LIST_DIR ?
Let's use the latter, CMAKE_CURRENT_LIST_DIR
On Tuesday 28 September 2010, Alexander Neundorf wrote:
...
Another option would be that I check in KDE/FPHSA.cmake
CMAKE_PARENT_LIST_FILE to see whether KDE/FPHSA.cmake is included from a
module in cmake or in KDE, and if it's in CMake, forward that explicitely
to CMake/FPHSA.cmake
On Tuesday 28 September 2010, Brad King wrote:
On 09/28/2010 05:20 PM, Alexander Neundorf wrote:
On Tuesday 28 September 2010, Alexander Neundorf wrote:
Is this intended this way ?
The attached tiny patch seems to make CMAKE_PARENT_LIST_FILE work more
like I expected.
Yes, but who
On Wednesday 29 September 2010, Alexander Neundorf wrote:
...
I have some thoughts, but it's not completely clear yet.
Somehow I think if a file is include()d from CMAKE_MODULE_PATH,
CMAKE_MODULE_PATH should be considered when it does its own include()s.
If it's not included via
On Tuesday 05 October 2010, James Bigler wrote:
On Tue, Oct 5, 2010 at 2:08 PM, Alexander Neundorf neund...@kde.org wrote:
...
The current behaviour is really like running an executable with a shared
library LD_PRELOADED, and hoping that the LD_PRELOADED libs will always
be work
On Friday 08 October 2010, David Cole wrote:
On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf neund...@kde.orgwrote:
...
Better idea:
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
On Friday 08 October 2010, you wrote:
On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf neund...@kde.orgwrote:
...
Better idea:
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
will, as
all
On Friday 08 October 2010, David Cole wrote:
On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf neund...@kde.orgwrote:
...
Better idea:
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
On Monday 11 October 2010, Marcus D. Hanwell wrote:
On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
...
So is there no chance of fixing this in a backward compatible way? One of
Prefering module in CMAKE_ROOT when include() or find_package() is called from
CMAKE_ROOT (which does
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.orgwrote:
...
Personally, I would try a rc3 with CMP0017 set to NEW and see how it
goes. It works for kdelibs and for our project at work (which doesn't
have a lot
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
2010/10/12 Alexander Neundorf neund...@kde.org
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.org
wrote:
...
Personally, I would try a rc3 with CMP0017 set
On Tuesday 12 October 2010, Alan W. Irwin wrote:
...
cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR)
because you absolutely need CMP0017. I believe most projects
(including PLplot) will eventually need that policy as well because
there is a tendency to copy and modify CMake find modules to
On Tuesday 12 October 2010, Bill Hoffman wrote:
Remaining are as far as I see:
-set new policy CMP0017 to NEW by default
Projects with an exotic setup may break, but that's probably better than
breaking all KDE 4.5.0/1 builds. One could also argue that these projects
relied on internal
On Tuesday 12 October 2010, David Cole wrote:
On Tue, Oct 12, 2010 at 5:21 PM, Brad King brad.k...@kitware.com wrote:
...
releases and will get us through this CMake rc cycle safely. Future
enhancements to FPHSA2 may need yet another new module, but I think
that is in the nature of this
On Tuesday 12 October 2010, Brad King wrote:
On 10/12/2010 03:32 PM, Alexander Neundorf wrote:
On Tuesday 12 October 2010, Bill Hoffman wrote:
Anyway, in the short term, we are going to go with FPHSA2, Alex do you
have time to do that?
FPHSA2 would have been my last choice
On Wednesday 13 October 2010, Bill Hoffman wrote:
So, I think we have to use the new name approach. Do we want to call it
2? Or should we call it something else?
Alex, do you have time to do this?
I think it's not a good solution, and the one with CURRENT_LIST_DIR is
definitely better and
On Wednesday 13 October 2010, Alexander Neundorf wrote:
...
Adding FPHSA2.cmake now in 2.8.3 is safe now, but not as soon as new
features are added to it in 2.8.4 or later versions.
Projects will have copies of it and it can break just the same way then.
Example: assume projects will take
On Wednesday 13 October 2010, Alexander Neundorf wrote:
On Tuesday 12 October 2010, Brad King wrote:
...
Currently projects have the option to override it with CMAKE_MODULE_PATH
to providing a module with the same API but a tweaked implementation.
With the CURRENT_LIST_DIR approach
Hi,
basically since January this year I am busy with adding support for the IAR
compilers to cmake:
http://public.kitware.com/Bug/view.php?id=10176
Main problem is that they run only under Windows, I don't have Windows, and I
also already tried to get them installed on a ReactOS QEmu image,
Hi Trevor,
On Sunday 17 October 2010, Trevor Kellaway wrote:
Alex,
Is CMake accepting platform files for the official distro?
You mean files for supporting the TI compilers ?
I think so, yes.
You may remember me from my original CMake 2.4 work on embedded compiler
support, I'm currently
Hi,
how are the cmake RCs doing ?
I didn't see an announcement for a 2.8.3 RC3, did I miss it ?
(I'm waiting for it so I can announce it to the KDE developers to give it some
extra testing)
Alex
___
cmake-developers mailing list
On Wednesday 27 October 2010, David Cole wrote:
Yes, the rc3 was announced last week.
Are you sure ?
I can't find it in my emails, also neither here:
http://public.kitware.com/pipermail/cmake-developers/2010-October/date.html
nor here:
http://www.cmake.org/pipermail/cmake/2010-October/date.html
Hi,
attached you can find a dependency graph for the khtmlpart in kdelibs.
This graph was created using dot from a dot-file generated by cmake using
the --graphviz option.
This feature was a bit buggy, e.g. it ignored targets which didn't link to
anything. So I spent some time on it and now
On Thursday 04 November 2010, David Cole wrote:
Hi all,
Now that we have released CMake 2.8.3, *now* would be a great time to
prioritize bug fixes for the next release of CMake.
Replies requested. Read on. *Just a short reply with bug numbers* or links
to the bugs is all we need here.
Hi,
I'm currently playing around with ctest and git/gitweb.
For our KDE nightly scripts with cvs and svn I first downloaded just the
CTestConfig.cmake file and then continued.
Since downloading single files is not possible with git AFAIK, I thought I'd
try gitweb.
Looks good so far, I just
On Tuesday 09 November 2010, David Cole wrote:
On Mon, Nov 8, 2010 at 3:46 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 11/8/2010 3:30 PM, Rolf Eike Beer wrote:
Am Montag, 8. November 2010 schrieb Bill Hoffman:
On 11/8/2010 1:55 PM, Rolf Eike Beer wrote:
Am Montag, 8. November
Hi,
the AddASM_NASMSupport branch (#10069) in staging is now good enough to be
merged into next (or master ?).
How does that happen ?
Should I simply ignore staging and merge my local branch into next and push
this ?
Or should I ask you to merge that branch into master ?
Should I try to merge
On Thursday 18 November 2010, Marcel Loose wrote:
...
Hi all,
I've been following this discussion with interest for quite a while. I
was wondering if both worlds could be united (Alex's and David's) if it
were possible to set cmake_minimum_required on the command line? That
way Alex can be
On Thursday 18 November 2010, Brad King wrote:
On 11/18/2010 04:29 AM, Marcel Loose wrote:
...
This entire issue is about projects using CMAKE_MODULE_PATH to override
standard CMake modules (accidentally or intentionally). This policy
changes the *granularity* at which that has to happen.
Hi,
there can be the case that a package which has been built with cmake, should
be used in a project which doesn't use cmake.
There is a feature request that cmake should help with generating pkg-config
pc-files: http://public.kitware.com/Bug/view.php?id=11446
I don't like that idea, because
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 03:55 PM, Alexander Neundorf wrote:
I have a slightly different idea: instead of having cmake generate
pc-files, modify/extend cmake so that it can be used similar to
pkg-config by projects which don't use cmake as their buildsystem
On Monday 22 November 2010, Alan W. Irwin wrote:
On 2010-11-22 21:55+0100 Alexander Neundorf wrote:
Hi,
there can be the case that a package which has been built with cmake,
should be used in a project which doesn't use cmake.
There is a feature request that cmake should help
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
...
I think the path forward here is:
(1) Improve documentation of CMAKE_USER_MAKE_RULES_OVERRIDE[_C]
variables
(2) Add the Custom-* file
On Tuesday 23 November 2010, Brad King wrote:
On 11/23/2010 03:31 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
(1) Improve documentation
On Tuesday 23 November 2010, Alexander Neundorf wrote:
On Tuesday 23 November 2010, Brad King wrote:
On 11/23/2010 03:31 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King
On Wednesday 15 December 2010, Brad King wrote:
On 12/15/2010 05:31 PM, Brad King wrote:
+ e CMake builtin module\n
+ includer \n
+ is including a module from the CMAKE_MODULE_PATH\n
+ moduleInCMakeModulePath \n
+ which
On Friday 28 January 2011, ajay bansal wrote:
Hi All,
I want to do build on netware platform. Please let me know whether cmake is
supported netware platform ?
There is an old feasture request for it:
http://public.kitware.com/Bug/view.php?id=5028
Currently there is no support for netware in
Hi,
I'm working currently on improved assembler support, should be ready for 2.8.5
(http://public.kitware.com/Bug/view.php?id=8392).
This means I need to determine a compiler ID for the ASM compiler.
Since on each architecture the asm sources are different, I can't just use a
common file and
On Sunday 13 February 2011, Eric Noulard wrote:
2011/2/13 Alexander Neundorf neund...@kde.org:
On Monday 07 February 2011, Alexander Neundorf wrote:
On Sunday 06 February 2011, Eric Noulard wrote:
2011/2/5 Alexander Neundorf neund...@kde.org:
Hi,
in general we keep cmake
On Wednesday 18 August 2010, Brad King wrote:
On 08/18/2010 01:03 PM, Alexander Neundorf wrote:
If the files are written that way (and built without cmake before), the
developers want to have them processed with the actual compiler, because
that's what they are always doing.
IMO that's
On Wednesday 23 February 2011, Brad King wrote:
On 02/23/2011 03:36 PM, Alexander Neundorf wrote:
This is now on stage in the ReworkedAsmSupport branch.
I'd like to merge this into next, if there are no objections.
It implements what we discussed here, i.e. if there is already a C/CXX
On Tuesday 01 March 2011, Brad King wrote:
On 03/01/2011 03:44 PM, Alexander Neundorf wrote:
The SunPro tests both failed:
http://www.cdash.org/CDash/testDetails.php?test=85204365build=884706
http://www.cdash.org/CDash/testDetails.php?test=85247010build=884931
The assembler file
On Thursday 03 March 2011, Brad King wrote:
Hi Alex,
The Sun compiler still fails:
http://www.cdash.org/CDash/testDetails.php?test=85204365build=888421
It's because the execute_process in the CMakeLists.txt file of the test
does not use the C compiler flags. Therefore 32-bit assembly code
On Friday 04 March 2011, Brad King wrote:
On 03/03/2011 05:04 PM, Alexander Neundorf wrote:
On Thursday 03 March 2011, Brad King wrote:
Hi Alex,
The Sun compiler still fails:
http://www.cdash.org/CDash/testDetails.php?test=85204365build=888421
It's because the execute_process
On Tuesday 08 March 2011, Brad King wrote:
On 03/07/2011 03:44 PM, Alexander Neundorf wrote:
Testing the Intel compiler under Windows...
I just tried this but have no time to work further on it now. The compiler
does use -S to generate assembly, but there are at least 3 problems:
(1
On Wednesday 09 March 2011, Brad King wrote:
On 03/09/2011 02:27 PM, Alexander Neundorf wrote:
On Tuesday 08 March 2011, Brad King wrote:
$ icl -S main.c
$ icl main.asm
(errors)
I was able to fix the errors for (3) by replacing . with _ in a few
labels. Then the build
}/Armadillo/cmake/. It works well,
thanks for the tips.
Clement.
On 16/03/11 19:16, Alexander Neundorf wrote:
Hi Clement,
On Wednesday 16 March 2011, creusot wrote:
Hi everybody,
I would like to propose a new cmake module for the Armadillo C++
library. http://arma.sourceforge.net
Hi,
Enrique is volunteering to maintain a new FindDC1394.cmake module, as posted
on the cmake list.
Did you already get in contact with him (... so I can close the ticket for
me) ?
Alex
-- Forwarded Message --
Subject: [CMake] [New Module] FindDC1394.cmake
Date: Sunday 13
On Saturday 26 March 2011, Wolfgang Steiner wrote:
Hi CMake people,
first off I'd like to thank the devs for such a great tool, you've done an
awesome job with this project ;)
I'm currently trying to do a cmake mod based on the latest Git head.
Basically I'm trying to add an alternative
Hi,
On Sunday 17 April 2011, Oliver Buchtala wrote:
Hi,
I like to get involved offering work on the Eclipse CDT generator.
Currently, the generated project setting is not very Eclipse'ish.
There have been some changes in the 2.8.x versions. You have 2.8.4 ?
- one large project
- linear
Hi Oliver,
On Sunday 17 April 2011, Oliver Buchtala wrote:
Hi Alex,
Am 17.04.2011 20:46, schrieb Alexander Neundorf:
Hi,
On Sunday 17 April 2011, Oliver Buchtala wrote:
Hi,
I like to get involved offering work on the Eclipse CDT generator.
Currently, the generated project
On Wednesday 20 April 2011, Oliver Buchtala wrote:
Hi Alex,
...
What would you expect there ?
Some structure that gives me acces to the sources of the targets.
I suppose, you try to achieve this with sub-projects, but it does not
work properly in my case.
How does it work not properly ?
On Monday 25 April 2011, Oliver Buchtala wrote:
Am 20.04.2011 22:09, schrieb Alexander Neundorf:
...
What would you expect there ?
Some structure that gives me acces to the sources of the targets.
I suppose, you try to achieve this with sub-projects, but it does not
work properly
On Thursday 28 April 2011, Nicolas Desprès wrote:
2011/4/28 David Cole david.c...@kitware.com:
2011/4/28 Nicolas Desprès nicolas.desp...@gmail.com
2011/4/27 Alexander Neundorf neund...@kde.org:
On Wednesday 27 April 2011, Nicolas Desprès wrote:
Hi,
I'm experimenting
On Wednesday 27 April 2011, Oliver Buchtala wrote:
Forgot to feed the list...
Am 27.04.2011 22:01, schrieb Alexander Neundorf:
On Friday 22 April 2011, Oliver Buchtala wrote:
...
Here we go:
git://github.com/oliver/cmake_cdt7.git
I have intensively worked with this generator
On Thursday 28 April 2011, Oliver Buchtala wrote:
...
wst-file is allright and I see that all projects are generated :)
Unfortunately, this working set stuff is yet a bit inconvenient, as it
is not an Eclipse built-in.
What you need to do:
0. Switch to C/C++ perspective (maybe this is the
On Saturday 30 April 2011, Oliver Buchtala wrote:
Am 29.04.2011 21:45, schrieb Manuel Klimek:
On Fri, Apr 29, 2011 at 11:55 AM, Alexander Neundorf neund...@kde.org
wrote:
On Thursday 28 April 2011, Oliver Buchtala wrote:
...
wst-file is allright and I see that all projects
On Wednesday 27 April 2011, you wrote:
Am 27.04.2011 21:28, schrieb Alexander Neundorf:
On Monday 25 April 2011, Oliver Buchtala wrote:
Am 20.04.2011 22:09, schrieb Alexander Neundorf:
...
What would you expect there ?
Some structure that gives me acces to the sources
On Friday 06 May 2011, Oliver Buchtala wrote:
Am 06.05.2011 23:26, schrieb Alexander Neundorf:
...
When I look around my colleagues I find basically only positive remarks
about the svn support in Eclipse ;-)
This is also my impression from feedback from other users about the
Eclipse
Hi,
I'm currently at the KDE Platform Sprint, where we (a bunch of KDE developers)
are discussing how to move on with the KDE platform.
This includes some things regarding cmake.
When we introduced cmake in KDE, there were not that many other free projects
using cmake, so our cmake extensions
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled
Hi,
again from the KDE sprint...
1) We have a macro
macro_optional_find_package().
The purpose is to be able to build without a specific package even if that
package is installed and would actually be found by the find_package() call.
Basically this is a wrapper around find_package(), but
Hi,
again from the KDE sprint...
We have around 150 cmake modules in kdelibs...
Several libraries are not before kdelibs, so they don't have access to
those.
So, what we came up with is that create a new package which just contains our
cmake modules, so they can be used by non-KDE
Hi,
when installing an export-file cmake has the nice feature to calculate the
CMAKE_INSTALL_PREFIX from the current location:
-8--8--8
# Compute the installation prefix relative to this file.
GET_FILENAME_COMPONENT(_IMPORT_PREFIX
On Sunday, June 05, 2011 11:50:12 AM Michael Wild wrote:
On 06/04/2011 10:28 PM, Alexander Neundorf wrote:
Hi,
when installing an export-file cmake has the nice feature to calculate
the CMAKE_INSTALL_PREFIX from the current location:
...
If so, would it be ok if I move the code
On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
Hi,
again from the KDE sprint...
1) We have a macro
macro_optional_find_package().
The purpose is to be able to build without a specific package even if
that package
On Sunday, June 05, 2011 11:21:43 PM Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
Hi,
KDE is getting more modular, so instead of a few huge modules there
will be much more independent libraries.
We'll try to make all those libraries install proper FooConfig.cmake
On Sunday, June 05, 2011 11:34:55 PM Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
Hi,
again from the KDE sprint...
We have around 150 cmake modules in kdelibs...
Several libraries are not before kdelibs, so they don't have access to
those.
So, what we
On Saturday, June 04, 2011 10:24:52 AM Alexander Neundorf wrote:
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
On Monday, June 06, 2011 03:44:20 PM Brad King wrote:
On 06/05/2011 07:14 PM, Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
* if so, it will check that for FOO_INCLUDES and FOO_LIBRARIES
* create the command line arguments for the compiler from that
* print -I/opt/foo
On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
What do you think about adding this as a built-in feature to
find_package(), i.e. add a argument OPTIONAL to find_package(), then
probably also a COMMENT.
The interface to find_package
Hi,
I slept over it, I think here's a better idea.
For every find_package() which is not REQUIRED, some people or packagers may
want to explicitely disable each one of them.
So how about this:
if there is no REQUIRED keyword in the find_package() call, there is always an
option added which
On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
2011/6/7 Alexander Neundorf neund...@kde.org:
On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
[...]
What do you think about adding the keyword OPTIONAL
On Saturday, June 04, 2011 10:09:57 AM Alexander Neundorf wrote:
Hi,
I'm currently at the KDE Platform Sprint, where we (a bunch of KDE
developers) are discussing how to move on with the KDE platform.
This includes some things regarding cmake.
When we introduced cmake in KDE, there were
On Monday, June 06, 2011 03:37:16 PM Brad King wrote:
On 06/06/2011 03:56 AM, Alexander Neundorf wrote:
On Saturday, June 04, 2011 10:24:52 AM Alexander Neundorf wrote:
Hi,
one feature which all KDE developers are used to and which is also used
by qmake when building Qt is automoc
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, 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
Hi Dave,
I want to wrap the externalproject_add() function, so that in the normal case
only the git URL has to be specified, and all other arguments have been
already set.
But it should still be possible to override my default arguments.
So I had a look how the argument parsing is done in
On Thursday 09 June 2011, Brad King wrote:
On 6/9/2011 8:50 AM, Alexander Neundorf wrote:
...
I think this can be handled.
find_package() should error out in this case, because Bar was required
but it was disabled.
Maybe this option to disable a find_package() could even be provided
On Thursday 16 June 2011, Brad King wrote:
On 06/16/2011 04:15 PM, Alexander Neundorf wrote:
I'll push a branch to the stage once 2.8.5 is released. Or can I do that
earlier ?
You can push it any time but skip merging it.
There should be a branch DisableSwitchForFindPackage now in stage
On Friday 17 June 2011, Alexander Neundorf wrote:
On Tuesday 07 June 2011, Alexander Neundorf wrote:
On Monday, June 06, 2011 03:44:20 PM Brad King wrote:
On 06/05/2011 07:14 PM, Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
* if so, it will check
On Monday 20 June 2011, Alexander Neundorf wrote:
...
What is the recommended way how to do this with git ?
with how to do this I mean how to make the suggested fixes
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http
On Monday 20 June 2011, Brad King wrote:
...
As you guessed, interactive rebase is the correct approach. Since
you have not merged the topic you are free to overwrite it on the
topic stage. The old version of the history will be replaced with
the new version. It might feel funny the first
On Tuesday 21 June 2011, Brad King wrote:
On 06/20/2011 06:23 PM, Alexander Neundorf wrote:
I moved part of the documentation now to the variable section.
Better ?
Nice, thanks.
While looking at it, I'm not sure anymore the name
DISABLE_FIND_PACKAGE_Name is good.
Should
On Wednesday 22 June 2011, Brad King wrote:
On 06/21/2011 03:25 PM, Alexander Neundorf wrote:
Ok, I pushed the branch again.
The new name looks better. Perhaps I missed this last time, but the
documentation of the variable within the command is back up in the
simple section.
Yes, you
On Thursday 23 June 2011, Brad King wrote:
On 06/23/2011 05:12 AM, Alexander Neundorf wrote:
Please put it at the very bottom of the entire
documentation, just above the note about NO_POLICY_SCOPE.
Done.
Thanks. The topic looks good. Please merge it to 'next' when
you're ready
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++ headers can be checked.
I'd like to add that to cmake.
Any
1 - 100 of 596 matches
Mail list logo
