Hi,
I've been working on my GenerateExportHeader macro described here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/36664
The result is here:
https://gitorious.org/~steveire/cmake/steveires-
cmake/commit/a80318ae6a299f44de8597d4ee705278554b7a4a
The problem is that the unit
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 as a filename for some reason. Can
anything be done about that? Should
David Cole wrote:
Hi Stephen,
So... this topic is in 'next', and today, it only fails on 4
dashboards in total. I will try to get output for you on the wcl
(Watcom) compiler dashboard -- since it timed out, there is no test
output reported on CDash...
Stephen Kelly wrote:
Yep, I've just had a look and possibily fixed the Intel and HPUX cases.
I did indeed fix the Intel and HPUX cases.
The AIX one fails because the visibility test passes, because
check_cxx_compiler_flag does not have a FAIL_REGEX for its warning:
http://www.cdash.org
David Cole wrote:
The test itself passes on AIX, as seen here:
http://www.cdash.org/CDash/testDetails.php?test=109727151build=1460504
It's only the particular machine that you pointed to that has
problems. There are *several* tests that fail on that machine with the
space in the path.
Hi,
I was wondering if stage/next is ever to be considered frozen around RC
time, or is it always 'summer' in next?
I have pushed a patch adding features from the KDE version of
Qt4Macros.cmake to a branch in stage (qt_dbus_interface_args). As I don't
maintain that file, should I contact the
.
Thanks,
Steve.
Thanks,
David
On Mon, Sep 5, 2011 at 4:02 PM, Stephen Kelly
steve...@gmail.com wrote:
Hi,
I was wondering if stage/next is ever to be considered frozen around RC
time, or is it always 'summer' in next?
I have pushed a patch adding features from the KDE version
Hi,
In KDE we set the LINK_INTERFACE_LIBRARIES to empty in a wrapper around
add_library. The reason is to reduce the number of libraries which are
linked to by default - developers have to be explicit about what is in the
LINK_INTERFACE.
I was considering patching CMake to do that by setting
Brad King wrote:
On 9/26/2011 7:28 AM, Stephen Kelly wrote:
In KDE we set the LINK_INTERFACE_LIBRARIES to empty in a wrapper around
add_library.
[snip]
set(CMAKE_SET_LINK_INTERFACE_EMPTY ON)
cause the LINK_INTERFACE to be empty for all shared library targets be
accepted into CMake
Rolf Eike Beer wrote:
The tricky part of this is to tell CMake to not enforce the implicit
dependencies to be exported when creating an export file for targets
created with this property enabled. Or better: to not enforce _any_
dependencies of a shared library to be exported then.
I
Rolf Eike Beer wrote:
Am Samstag 01 Oktober 2011, 13:57:09 schrieb Stephen Kelly:
Rolf Eike Beer wrote:
The tricky part of this is to tell CMake to not enforce the
implicit
dependencies to be exported when creating an export file for
targets
created with this property enabled
Hi David,
This is related to my patch to set the link_interface_libraries to empty and
to:
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030
Quoting:
Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
By default, all libraries a target is linked
Stephen Kelly wrote:
Hi David,
This is related to my patch to set the link_interface_libraries to empty
and to:
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030
Quoting:
Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
By default, all
Brad King wrote:
On 10/5/2011 9:47 AM, Stephen Kelly wrote:
Thanks for all of your explanations. It seems that introducing a way to
do this with one command has some support.
So if SOME_FEATURE is true,
target_link_libraries(foo bar SOME_KEYWORD baz)
if (SOME_FEATURE
Stephen Kelly wrote:
Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE?
Perhaps LINK AND LINK_ONLY?
I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which
are most clear to me. We can change it once we have an implementation to
talk about.
Well that didn't
Stephen Kelly wrote:
target_link_libraries(foo
LINK_PUBLIC
qtcore
qtnetwork
)
is equivalent to
target_link_libraries(foo
qtcore
qtnetwork
)
* foo will link against qtcore and qtnetwork
I should have also noted that both qtcore and qtnetwork will also
Brad King wrote:
On 10/7/2011 7:21 AM, Stephen Kelly wrote:
I have a check for the Wl,--no-undefined flag in the test, and on some
platforms the check passes (it seems), but the test fails later.
Many linkers simply warn about an unused flag and ignore it.
It's hard to test for them
Brad King wrote:
On 10/6/2011 8:54 PM, Stephen Kelly wrote:
Well that didn't take long. I pushed a target-link-libraries-interfaces
branch to stage.
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
Bill Hoffman wrote:
On 10/7/2011 11:30 AM, Brad King wrote:
On 10/7/2011 11:23 AM, Stephen Kelly wrote:
Brad King wrote:
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
in a consistent state.
Done.
Also
Eric Noulard wrote:
2011/10/7 Stephen Kelly
steve...@gmail.com:
Bill Hoffman wrote:
Please keep working on fixing the dashboard, there are a few style
errors here:
http://www.cdash.org/CDash/viewBuildError.php?buildid=1601031
-Bill
Hmm, hadn't noticed those.
The link doesn't show
Stephen Kelly wrote:
such that kwtyle is run as a pre-commit hook.
The instructions don't seem to work:
Oops, they do work. I had missed the part about creating a new repo in my
hooks dir.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http
Stephen Kelly wrote:
Stephen Kelly wrote:
such that kwtyle is run as a pre-commit hook.
The instructions don't seem to work:
Oops, they do work. I had missed the part about creating a new repo in my
hooks dir.
:/
Not finding some conf file:
stephen@hal:~/dev/src/cmake{cmake
Stephen Kelly wrote:
Stephen Kelly wrote:
Stephen Kelly wrote:
such that kwtyle is run as a pre-commit hook.
The instructions don't seem to work:
Oops, they do work. I had missed the part about creating a new repo in my
hooks dir.
:/
Not finding some conf file:
I might
Brad King wrote:
On 10/7/2011 7:21 AM, Stephen Kelly wrote:
I have a check for the Wl,--no-undefined flag in the test, and on some
platforms the check passes (it seems), but the test fails later.
Many linkers simply warn about an unused flag and ignore it.
It's hard to test for them
Bill Hoffman wrote:
On 10/7/2011 11:30 AM, Brad King wrote:
On 10/7/2011 11:23 AM, Stephen Kelly wrote:
Brad King wrote:
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
in a consistent state.
Done.
Also
Brad King wrote:
On 10/8/2011 7:40 AM, Stephen Kelly wrote:
Would it break anything if we changed check_cxx_compiler_flag to build a
shared library instead of an executable? Maybe that will make the
try_compile fail as expected. (I'll try add a test for that now)
We cannot make a change
Hi,
I'm trying to find out why the target_link_libraries unit tests are failing
on some platforms (but not mine...). I'm enabling one platform at a time. I
enabled the failing tests for APPLE, so if you want to try it out, you need
to comment out the if(APPLE).
Bill Hoffman wrote:
On 10/11/2011 2:33 AM, Stephen Kelly wrote:
Hi,
I'm trying to find out why the target_link_libraries unit tests are
failing on some platforms (but not mine...). I'm enabling one platform at
a time. I enabled the failing tests for APPLE, so if you want to try it
out
Bill Hoffman wrote:
So, basically we this:
set(CMAKE_LINK_INTERFACE_LIBRARIES )
add_library(libA SHARED classA.cpp)
add_library(libB SHARED classB.cpp)
add_library(libC SHARED classC.cpp)
generate_export_header(libA)
generate_export_header(libB)
generate_export_header(libC)
Stephen Kelly wrote:
The tests can be enabled on APPLE again later, I've flipped the if
condition so we can see why it fails on some non-APPLE platforms too.
This is even more interesting now.
http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094
On gentoo, the build
Rolf Eike Beer wrote:
Stephen Kelly wrote:
The tests can be enabled on APPLE again later, I've flipped the if
condition so we can see why it fails on some non-APPLE platforms too.
This is even more interesting now.
http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094
cmake_progress_start
/home/rkw/test19-build/CMakeFiles 0
[rkw@Chameleon-12 ~/test19-build]$
On Oct 13, 2011, at 1:43 AM, Stephen Kelly wrote:
On 10/12/2011 08:18 PM, Richard Wackerbarth wrote:
Stephen,
I'm not sure what you were expecting.
The testing starts was with the version of test19
Stephen Kelly wrote:
Ok, knowing why it fails on APPLE is good enough for me for now.
The tests can be enabled on APPLE again later, I've flipped the if
condition so we can see why it fails on some non-APPLE platforms too.
I was given access to a freebsd box to see why the build
Stephen Kelly wrote:
Ok, knowing why it fails on APPLE is good enough for me for now.
The tests can be enabled on APPLE again later, I've flipped the if
condition so we can see why it fails on some non-APPLE platforms too.
I was given access to a freebsd box to see why the build
Hi,
I've been pushing some changes to the unit tests on
the cmake-link-interface-libraries branch which is merged into next.
Where the unit tests that I wrote were failing before in some cases, my
changes make the dashboard go green again, but they don't actually make
CMake any better.
That
Rolf Eike Beer wrote:
Stephen Kelly wrote:
What I'd like to see is a distinction of feature support from platform
support. In my case, I care about writing some features in cmake, but I
don't care about watcom, GCC 3.3.1 etc. What I'd like to do is make sure
my feature works on some
Brad King wrote:
On 10/19/2011 6:04 AM, Stephen Kelly wrote:
I saw that the weekly merge of branches into master happened yesterday,
but the cmake-link-interface-libraries branch didn't make the cut.
Thanks for your work on this.
So I'd like to know:
1) What made it not get merged?
2
Brad King wrote:
On 10/19/2011 11:14 AM, Stephen Kelly wrote:
On 10/19/2011 6:04 AM, Stephen Kelly wrote:
I saw that the weekly merge of branches into master happened yesterday,
but the cmake-link-interface-libraries branch didn't make the cut.
[snip]
Not a major rush anyway. I'm still
Brad King wrote:
What does CMake think about rebasing? I much prefer to squash a branch
like test-target_link_libraries into fewer commits so that eg adding
newlines and changing tests to examine dashboard changes are not separate
commits. I don't think those commits add value, but only
On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote:
On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote:
* If you want to be easily found for others to depend on, you write a
PackageConfig.cmake file and install it to a location CMake
will use
to find
templates using a bit of Perl (or whatever you want). For someone
building a project which depends on Qt they would of course need CMake
to find these files.
Yep, I have nothing more to add to this.
Thanks,
--
Stephen Kelly step...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB
On Friday, October 28, 2011 07:58:25 Clinton Stimpson wrote:
On Friday, October 28, 2011 06:21:23 am Stephen Kelly wrote:
On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote:
On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote:
* If you want to be easily found for others
On Friday, October 28, 2011 13:13:20 Stephen Kelly wrote:
== Summary ==
I'm considering adding some cmake files to Qt, which would be installed by
Qt, and which would make it easier for CMake based projects to depend on
Qt.
I'm CC'ing the cmake developers too see what they think
On 11/02/2011 06:32 PM, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
No, it's the other way around, in KDE. $ grep Q_OBJECT kautosavefile.*
kautosavefile.h: Q_OBJECT $ grep moc kautosavefile.cpp #include
kautosavefile.moc
If it did additionally other things,
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 you have Q_OBJECT in the .cpp
file too:-)
I'm sure I've
] master - master (hook declined)
error: failed to push some refs to 'g...@cmake.org:cmake.git'
Does the wiki page need to have that section removed?
Thanks,
--
Stephen Kelly step...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30
of the page confused me when I first started
working with CMake git a few months ago, and I was looking at it again.
Could it be an idea to split that page so that there is a page for people like
me or new people which doesn't say anything about pushing to master?
Thanks,
--
Stephen Kelly step
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://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39114
I've pushed the target-include-directories branch
Hi,
Should successive calls to find_package succeed in general?
Eg
find_package(Grantlee COMPONENTS Templates)
find_package(Grantlee COMPONENTS TextDocument)
?
Currently if the target package uses Config files and
install(TARGETS ... EXPORT)
the convention is to use
Brad King wrote:
On 11/6/2011 7:00 PM, Stephen Kelly wrote:
include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake)
It is up to the author of the config file to block this correctly
against multiple inclusion, e.g.
if(NOT Grantlee_TARGETS_INCLUDED)
set(Grantlee_TARGETS_INCLUDED 1
Brad King wrote:
On 11/22/2011 9:31 AM, Stephen Kelly wrote:
CMake Error: INSTALL(EXPORT twoDeps ...) includes target libtwo
which requires target libone that is not in the export set.
How can we resolve this?
http://public.kitware.com/Bug/view.php?id=12588
Brad asked to bring this up
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, which would be a
moc_foo.cpp include.
Yes.
* Some places
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. A before B). That way
when the command installing ExportB
On 11/22/2011 07:10 PM, Alexander Neundorf wrote:
find #include (.*).moc - generate moc for \\1.cpp
Was there a reason for preventing this?
We can do that, but how can that work ?
I mean, this will generate code for a class which is declated in a different
source file, so it is unknown in
On 11/22/2011 07:37 PM, David Faure wrote:
On Tuesday 22 November 2011 14:33:25 Stephen Kelly wrote:
I think in many cases,
fixing KDE will just be removing the explicit include foo.moc which is
intended to run moc on foo.h, and let the automatic moc'ing do the work.
No, to include
Alexander Neundorf wrote:
Test added, works.
What is not working right now is including someotherfile.moc. I could add
special handling for including thisfile_p.moc (as opposed to
moc_thisfile_p.cpp, which works).
Yes, this is the issue that makes the build break in the frameworks branch.
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. It should work again, but print a warning if a file includes
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 the moc file kdirwatch_p.moc, which seems to be the moc
file
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 and mac.
The clone is at
https://qt.gitorious.org
On 11/28/2011 05:51 PM, Brad King wrote:
On 11/25/2011 10:02 AM, Stephen Kelly wrote:
https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-qtbase/
the branch is cmake_files. The testing steps are:
1) build and install Qt
It doesn't appear to build at all on Windows with VS 9
Hi,
Is Qt supposed to be buildable with VS 10 on Windows?
Context here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2338/focus=2347
Thanks,
Steve.---BeginMessage---
On 11/28/2011 11:57 AM, Stephen Kelly wrote:
On 11/28/2011 05:51 PM, Brad King wrote:
On 11/25/2011 10
Brad King brad.king@... writes:
On 11/6/2011 5:45 PM, Stephen Kelly wrote:I'd prefer it to be though if
we can sort out the issues with what should be the target feature set.
Good. We can work on this and revise/rewrite the topic there first and then
merge to next for testing when
Brad King wrote:
On 11/29/2011 8:00 AM, 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
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 should I rename them or should I
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 those
setups.
Just the ones for Linux would already
Alexander Neundorf wrote:
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
Brad King wrote:
On 11/29/2011 8:40 PM, Stephen Kelly wrote:
Alexander Neundorf wrote:
Nevertheless, personally I would also provide the Qt5Core_LIBRARY
variable, so if somebody wants to have a look what that variable
currently actually is (would by the name if the imported target), he can
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/audiointerface.cpp
@@ -67,4 +67,4 @@
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
need to let the user help out
Alexander Neundorf wrote:
Static builds of Qt are no longer tested by Nokia at least as far as I
know. I don't know if it is even possible to build Qt statically on all
(or any) platforms anymore.
Ah, ok.
So if we (at work) would like to have static builds, we maybe should take
action ?
Alexander Neundorf wrote:
but this still means that even if we start to
require cmake 2.8.7 for kdelibs4, we still need the standalone automoc
(which I don't feel like maintaining).
Well, kdelibs4 is not really going to get any more releases. I'm not sure
it makes sense to change the
Brad King wrote:
On 11/29/2011 7:34 AM, Stephen Kelly wrote:
I've been working on this topic again, but I forgot that I had not merged
it into next. I think I properly reverted it though.
I added another commit to the revert-... branch to fully revert it.
To avoid accidental merges of work
Brad King wrote:
On 12/1/2011 3:47 PM, Stephen Kelly wrote:
https://github.com/Kitware/CMake
and use the Fork button
Ok. I've pushed it to my gitorious repo for now. I'll remove the config
stuff there and let you know when that's done.
Should I push it to github too or is gitorious also
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 but there is no
Q_OBJECT in the header, then moc the basename.h and put
Brad King wrote:
On 11/29/2011 7:34 AM, Stephen Kelly wrote:
I worked on the functionality for per-config target includes, but the
syntax is not right yet.
Please remove per-config support for now.
Do you mean I should remove the UI feature of setting the
INCLUDE_DIRECTORIES_DEBUG
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 unlikely to happen. If RC1 is Wednesday, it would have
Alexander Neundorf wrote:
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
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 mode compatibility. ?
or for qmake compatibility ?
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
build. I'd like to have a better way to express
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 by automoc say Better do
Alexander Neundorf wrote:
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
Alexander Neundorf wrote:
On Sunday 18 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
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
Mantis Bug Tracker wrote:
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=12645
==
Reported By:Michael Wild
Hi,
I don't think I've ever seen a direct answer to this question. Is it
something to be decided on a case by case basis? If so, then why is there no
general case?
I can see a possible reason that it is not solvable in the general case
because sometimes the behaviour of find_package can be
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.
Is it something to be decided on a case by case basis
David Cole wrote:
How can this feature now be moved forward? Do I need to convince someone
to volunteer to port the other generators? Should I just file a bug for
porting the other generators and wait (possibly making the feature
bitrot)?
I volunteer to make sure this branch works with
David Cole wrote:
On Fri, Jan 20, 2012 at 3:20 PM, Stephen Kelly
steve...@gmail.com wrote:
Hi,
I've force pushed my branch:
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-
include-directories
Brad King wrote:
On 1/8/2012 11:47 AM, Stephen Kelly wrote:
On 12/05
David Cole wrote:
On Sun, Jan 29, 2012 at 11:44 AM, Stephen Kelly
steve...@gmail.com wrote:
David Cole wrote:
OK... nearly complete now. Please review, then reply and tell me if
you object to any of the 7 commits in this topic branch.
No objections. They all seem fine.
Great, thanks
Hi there,
One of the macros we have in KDE creates shell scripts to initialize
environment variables needed on various platforms so that tests can be run
before installation. If RPATH is enabled, the scripts are not needed, but
RPATH is sometimes disabled, so the scripts are the solution to
Hi there,
Also in this thread one of the discussion topics was making CMake default to
creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE or
MACOSX_BUNDLE property on the executable target.
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005
By
Eric Noulard wrote:
2012/2/17 Stephen Kelly
steve...@gmail.com:
Hi there,
Also in this thread one of the discussion topics was making CMake default
to creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE
or MACOSX_BUNDLE property on the executable target.
http
Marcel Loose wrote:
Hi,
On Fri, 2012-02-17 at 08:51 +0100, Alexander Neundorf wrote:
-- 8 8 8 8 8 8 8 8 8 --
So the suggestion is
a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but
not when
building (I don't know if that's
Marcel Loose wrote:
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8 8 8 8 8 8 8 8 8 --
diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
index d2e37d2..ad471c7 100644
--- a/templates/tests
Eric Noulard wrote:
2012/2/17 Stephen Kelly
steve...@gmail.com:
Marcel Loose wrote:
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8 8 8 8 8 8 8 8 8 --
diff --git a/templates/tests/CMakeLists.txt
b/templates/tests
Alexander Neundorf wrote:
On Friday 17 February 2012, Stephen Kelly wrote:
...
The other issue is regarding setting RPATH for the build step and not the
install step, and what syntax should be used for that.
The options are:
a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH
Brad King wrote:
On 2/17/2012 5:44 AM, Stephen Kelly wrote:
I meant 'default' in the sense of
cmTarget::SetPropertyDefault, in the same way that set(CMAKE_AUTOMOC ON)
sets the AUTOMOC property to true by default for all targets that follow.
[snip]
default value of the property *if* set
Hi,
I must have missed something here.
On Friday, February 17, 2012 13:16:42 Brad King wrote:
On 2/17/2012 12:09 PM, Alexander Neundorf wrote:
But another significant part of the reason is probably that beside
upstreaming a module to cmake, there is no other official way to
distribute
Brad King wrote:
If anyone is interested in working on something like this the C++ changes
you mention would need to make exports recorded by either export() or
install(EXPORT) into first-class objects. A major missing feature from
them right now is having multiple logical exports with
Hi,
In the last few days something changed to make the GenerateExportHeader GCC
version check fail:
http://open.cdash.org/buildSummary.php?buildid=2016288
Any idea what would cause that? It must be one of these:
http://open.cdash.org/viewUpdate.php?buildid=2016288
(as a side note, I find
On Sunday, February 19, 2012 16:18:00 Alexander Neundorf wrote:
On Sunday 19 February 2012, Stephen Kelly wrote:
The only reason to distribute FindBlub for a CMake-aware project is
to wrap up find_package NO_MODULE to produce a nicer message, but
that
is totally optional
1 - 100 of 1193 matches
Mail list logo
