skelly added a comment.
My preference would be to use the ClangConfig.cmake instead of introducing
these new files.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5289
To: heikobecker, #frameworks, #build_system, skelly, kfunk
Cc: rdieter, shaheed,
skelly added a comment.
In https://phabricator.kde.org/D4509#85725, @shaheed wrote:
> The PEP-8 changes are some blank line changes.
There is exactly one blank line insertion, and it makes this TypedefRuleDb
documentation inconsistent with, say, the VariableRuleDb, which doesn't
skelly added inline comments.
INLINE COMMENTS
> sip_generator.py:172
> """
> +if member.kind == CursorKind.UNEXPOSED_ATTR and
> text.find("_DEPRECATED") != -1:
> +sip["annotations"].add("Deprecated")
It was possible to handle exports without looking for the text
skelly added inline comments.
INLINE COMMENTS
> rules_engine.py:58
> +# Keep PyCharm happy.
> +_ = _
> +
I don't think this should be here.
> rules_engine.py:494
> nameThe name of the
> typedef.
> +
skelly added a comment.
Is anything here actually a PEP 8 fix?
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D4509
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: shaheed, #build_system, #frameworks, skelly
Cc:
has always included QDebug, so this has always been
superfluous.
Diffs
-
modules/ECMQtDeclareLoggingCategory.cmake 3f7bb79
modules/ECMQtDeclareLoggingCategory.h.in b59bc7a
Diff: https://git.reviewboard.kde.org/r/127440/diff/
Testing
---
None.
Thanks,
Stephen Kelly
eviewboard.kde.org/r/129724/
> ---
>
> (Updated Jan. 16, 2017, 9:12 a.m.)
>
>
> Review request for Build System, KDE Frameworks and Stephen Kelly.
>
>
> Repository: extra-cmake-modules
>
>
> Description
> ---
>
> Gives a nice warning about something that sh
) this and pushed it to master.
- Stephen Kelly
On Jan. 5, 2017, 8:31 a.m., Shaheed Haque wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.
> On Jan. 4, 2017, 10:11 p.m., Stephen Kelly wrote:
> > Hi Shaheed,
> >
> > Can you also add something to the unit test python code which asserts the
> > (not zero) value of an enum with an attribute like this?
> >
> > Thanks,
> >
> &
python code which asserts the (not
zero) value of an enum with an attribute like this?
Thanks,
Steve.
- Stephen Kelly
On Jan. 3, 2017, 11:18 p.m., Shaheed Haque wrote:
>
> ---
> This is an automatically generated e-mail. To rep
David Faure wrote:
> Problem 1: "make test" now requires cmake 3.3, which the CI doesn't have
> (it has 3.2.2)
> https://build.kde.org/view/Frameworks%20kf5-qt5/job/extra-cmake-modules%20master%20kf5-qt5/36/PLATFORM=Linux,compiler=gcc/testReport/junit/(root)/TestSuite/GenerateSipBindings/
> What
Hi,
I would like to add the python bindings previously discussed to the next
release of KF5. This means adding the four most recent commits from
https://github.com/steveire/extra-cmake-modules/commits/python-bindings
to ECM and generating the bindings for KItemModels and KGuiAddons,
David Faure wrote:
> On dimanche 5 juin 2016 11:27:48 CEST Stephen Kelly wrote:
>> On 06/04/2016 11:03 AM, David Faure wrote:
>> > Symptom: zanshin doesn't compile with Qt 5.7 and cmake from "release"
>> > branch, error is "std::make_unique not found&quo
On 06/04/2016 11:03 AM, David Faure wrote:
> Symptom: zanshin doesn't compile with Qt 5.7 and cmake from "release" branch,
> error is "std::make_unique not found".
>
> Reason: zanshin wants -std=c++14, but gets a compile line like this:
> -std=c++0x [...] -std=c++14 [...] -std=gnu++11
> so in the
Ben Cooksley wrote:
>> Has this issue been resolved somehow?
>
> Yes, the fault in Digikam's code has been resolved.
> From what I understand it has something to do with some of the more
> unusual CMake constructs which Digikam was using (and is a fault the
> CMake developers have acknowledged
Ben Cooksley wrote:
> It would be appreciated if you jointly investigated why this isn't
> working.
Hi,
Sorry for not being active on this before.
I tried to build the akonadi parts of digikam master with akonadi-contacts
from kdepimlibs, and it worked. I also notice that the build on b.k.o
Shaheed Haque wrote:
> [ resend now I am subscribed, apologies for any dupes ]
>
> Hi all,
>
> I am working on trying to revive PyKDE4 as PyKF5 and more [1]. The
> procedure is:
>
> 1. create SIP file from the relevant KF5 .h file(s)
> 2. run the SIP compiler to produce the actual binding C++
Shaheed Haque wrote:
> [ resend now I am subscribed, apologies for any dupes ]
>
> Hi all,
>
> I am working on trying to revive PyKDE4 as PyKF5 and more [1]. The
> procedure is:
>
> 1. create SIP file from the relevant KF5 .h file(s)
> 2. run the SIP compiler to produce the actual binding C++
Shaheed Haque wrote:
> [ resend now I am subscribed, apologies for any dupes ]
>
> Hi all,
>
> I am working on trying to revive PyKDE4 as PyKF5 and more [1]. The
> procedure is:
>
> 1. create SIP file from the relevant KF5 .h file(s)
> 2. run the SIP compiler to produce the actual binding C++
be called
ImageMagick::convert instead of Convert::Convert. ImageMagick is a namespace,
and other executables like ImageMagick::compare etc should be in the same one
if they get added some day.
- Stephen Kelly
On April 7, 2016, 11:01 a.m., Andre Heinecke wrote
Ben Cooksley wrote:
> Hi Plasma Devs,
>
> It would appear Plasma Workspace is improperly exporting it's targets,
> leading to build failures. This particularly affects Apper, which is
> unable to build on the CI system as a result. Please ensure when
> exporting targets / finding libraries that
superfluous.
Diffs
-
modules/ECMQtDeclareLoggingCategory.cmake 3f7bb79
modules/ECMQtDeclareLoggingCategory.h.in b59bc7a
Diff: https://git.reviewboard.kde.org/r/127440/diff/
Testing
---
None.
Thanks,
Stephen Kelly
___
Kde-buildsystem
/view.php?id=16026
and I also reviewed the module as a whole. Then I submitted
https://git.reviewboard.kde.org/r/127440/
The
string(FIND "${ARG_HEADER}" "." pos REVERSE)
stuff in this module is odd. It should use get_filename_component(NAME_WE)
probably.
- Stephen Kelly
O
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127432/#review93800
---
Ship it!
Ship It!
- Stephen Kelly
On March 20, 2016
Ben Cooksley wrote:
> Hi,
>
> It seems some internal targets within kdepim-runtime are missing
> appropriate dependency target settings.
>
> Please see
> https://build-sandbox.kde.org/job/kdepim-runtime%20master%20kf5-qt5/lastFailedBuild/PLATFORM=Linux,compiler=gcc/console
>
> Could someone
Albert Astals Cid wrote:
> Works here, cc'ing the build-system and frameworks lists in case someone
> gets an idea of what may be wrong from the log.
>
> Cheers,
> Albert
>
> El Monday 29 February 2016, a les 22:26:49, Nilesh Kokane va escriure:
>> Hello,
>>
>> While building attica-5.19.0
> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> >
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would
> > expect the libs go in the same place, but maybe the plugins are affected by
> > this? Can you be more specific
> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> >
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would
> > expect the libs go in the same place, but maybe the plugins are affected by
> > this? Can you be more specific
> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> >
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would
> > expect the libs go in the same place, but maybe the plugins are affected by
> > this? Can you be more specific
> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> >
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would
> > expect the libs go in the same place, but maybe the plugins are affected by
> > this? Can you be more specific
say what it is? I would expect
the libs go in the same place, but maybe the plugins are affected by this? Can
you be more specific?
Thanks,
- Stephen Kelly
On Feb. 24, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote
Alex Merry wrote:
> Hi all,
>
> A combination of a serious illness in the family and some of the heated
> discussions taking place on other KDE mailing lists has led to me
> burning out on the KDE front. As a result, I'm taking a step back (some
> of you may have noticed this already). I expect
David Faure wrote:
Git commit 19252f57cb5576a39e1a43cd19670d97e0cd9a8d by David Faure.
Committed on 25/07/2015 at 22:12.
Pushed by dfaure into branch 'Applications/14.12'.
Add cmake_minimum_required(VERSION 2.8.9) at the top and fix build.
target_link_libraries( cantorlibs
+ PUBLIC
David Faure wrote:
[moving this discussion to the mailing-list]
What should I do if it says cmake_minimum_required(VERSION 2.8.12)?
Leave it untouched?
Perhaps someone specified that version because they used a command
introduced in that version, though that's not the correct thing to
(${tgts}
PRIVATE Qt5::Widgets Qt5::Test
)
- Stephen Kelly
On May 18, 2015, 6:15 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123841
On May 18, 2015, 6:59 p.m., Stephen Kelly wrote:
modules/ECMAddTests.cmake, line 106
https://git.reviewboard.kde.org/r/123841/diff/1/?file=369887#file369887line106
This bundling is also not ideal. Consider adding a
ecm_targets_link_libraries(tgt1 [tgt2
)
https://git.reviewboard.kde.org/r/123841/#comment55264
This seems like it would be verbose and needless?
- Stephen Kelly
On May 18, 2015, 7:05 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit
Alex Merry wrote:
Add PROPERTIES argument to ecm_add_test and ecm_add_tests.
I know you have merged this already, but I consider it a bad design. If the
user wants to set properties, then the user can use set_test_properties().
Using more commands is good and making command parameters
David Faure wrote:
But since both Stephen Kelly and Alex Merry (maintainers of ECM) are in
favour of switching, I'll make the switch.
Thanks for taking care of that!
Steve.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https
wrote:
On 28/03/15 03:48, Alex Merry wrote:
On Wednesday 25 March 2015 22:35:24 Stephen Kelly wrote:
Hello,
ECM release numbers are in sync with KF5 release numbers, except for the
major component.
This means that if you want to build the 5.x.y release you have to download
the 1.x.y
Michael Palimaka wrote:
On 02/04/15 21:29, Stephen Kelly wrote:
I have no particular objection,
So, what needs to be done to get this synced up? Bump the version in
the CMakeLists.txt and update some release-tarball-creating script?
David I guess the latter is for you?
Thanks,
Steve
Hello,
ECM release numbers are in sync with KF5 release numbers, except for the
major component.
This means that if you want to build the 5.x.y release you have to download
the 1.x.y release of ECM. That doubles the complexity of your script which
downloads the tarball to build it.
That is
Stephen Kelly wrote:
* The 'deprecated' variables are still used by kcoreaddons. I didn't check
other frameworks. Are other frameworks ported to the new variables? Why is
there no run-time message to port from old to new? Is there a migration
path or even a migration need?
So, I see you made
Alex Merry wrote:
On Monday 08 December 2014 23:58:25 Alex Merry wrote:
I think the right plan is to:
* port KF5 to use CMAKE_INSTALL_* variables
* warn about using the old variables on the command line
* when KF6 and/or e-c-m 2.0 happens (whether or not those happen in
sync), ** ditch the
Hello,
You might be interested in some discussion here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11869
In particular:
* The 'deprecated' variables are still used by kcoreaddons. I didn't check
other frameworks. Are other frameworks ported to the new variables? Why
Alex Merry wrote:
Does CMake even provide a way of marking variables as deprecated?
Nope. But you wrote below you don't want that anyway.
Simply
making the old name an alias for the new doesn't quite work, as we need to
maintain compatibility on the command line as well as in the CMakeLists
Ben Cooksley wrote:
On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote:
Is build.kde.org now using the release branch of cmake.git instead of the
next branch? When/why did that change?
This was changed around about
http://mail.kde.org/pipermail/kde-frameworks-devel
Ben Cooksley wrote:
Hi all,
It would appear that CMake 3.0 to 3.1 introduces a colossal change in
behaviour. This change totally breaks all KDE projects which use
Extra-CMake-Modules, as necessary headers are no longer installed.
This has become an issue following
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116025/#review52316
---
Looks like a good manual.
- Stephen Kelly
On March 6, 2014
On Feb. 25, 2014, 3:56 p.m., Stephen Kelly wrote:
docs/writing-find-modules.md, line 9
https://git.reviewboard.kde.org/r/116025/diff/2/?file=246011#file246011line9
You can link to
http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html
). CMake will resolve that itself.
- Stephen Kelly
On Feb. 25, 2014, 10:59 a.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116025
Alex Merry wrote:
On 07/01/14 15:36, Stephen Kelly wrote:
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114885/
I didn't follow this discussion closely enough. I'll see if I can catch
up with it later.
kde-modules
and CMAKE_VISIBILITY_INLINES_HIDDEN instead.
- Stephen Kelly
On Jan. 7, 2014, 3:22 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114885
?
- Stephen Kelly
On Jan. 7, 2014, 5:01 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114898
is not used when finding it.
- Stephen Kelly
On Jan. 7, 2014, 8:57 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114903
Alex Merry wrote:
maybe push for a
discussion in the Qt Project about whether it should be set to match how
Qt was built (in qmake and Qt5CoreConfig.cmake, or in an installed
header file).
This seems to me like a useful thing to do.
Thanks,
Steve.
David Faure wrote:
+QT.@PRI_TARGET_BASENAME@.defines = @PRI_TARGET_DEFINES@
stephen@hal:~/dev/build/qtbase/qtbase$ grep -i defines mkspecs/modules-
inst/qt_lib_network.pri
QT.network.DEFINES = QT_NETWORK_LIB
What's your point?
Looks like no one else on the list can see the point
David Faure wrote:
Personally I'd put more weight into documented uses than asking
someone.
http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#58bc93114d
2386b74e861888ac36a384
That
1) Is a wiki, not the (versioned) qmake manual
2) Does not relate to third party uses.
Harald Sitter wrote:
On Thu, Dec 19, 2013 at 2:20 PM, Stephen Kelly steve...@gmail.com wrote:
Harald Sitter wrote:
xnox was nice enough to look into this in detail and identified the
problem as having a much smaller scope than I had originally thought.
1) What is the problem
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote:
2) Why does the package creation result in broken cmake files generated
from the Qt tarball?
The package creation does not result in broken cmake files generated
from the Qt tarball.
Great.
It's just there is no clean way to override
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote:
I am also not sure yet, if
a cross-moc is required or whether a native moc binary can be re-used.
It's one of the open questions that I still have, and need to
investigate the actual code generator / code generated.
Even if the code generated
Daniele E. Domenichelli wrote:
Even weirder, it happens only for kde frameworks, I couldn't reproduce
anywhere else, and all the unit tests pass:
This discussion belongs on the cmake list.
I don't know what you tried in order to reproduce the failure outside KF5,
but it was quite easy to
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113863/#review43892
---
Ship it!
Ship It!
- Stephen Kelly
On Nov. 18, 2013, 2:34
.
- Stephen Kelly
On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406
On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
modules/ECMGenerateHeaders.cmake, line 11
http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line11
I really think the answers to my questions here need to be found first:
http://thread.gmane.org
on?
- Stephen Kelly
On Sept. 12, 2013, 5 p.m., Aleix Pol Gonzalez wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112697
Christophe Giboudeaux wrote:
On Monday 09 September 2013 21:37:37 Stephen Kelly wrote:
Stephen Kelly wrote:
Christophe Giboudeaux wrote:
find_library(SAMBA_LIBRARIES NAMES smbclient HINTS ${PC_SAMBA_LIBDIR})
This should be _LIBRARY, not _LIBRARIES. Followed by:
set(SAMBA_LIBRARIES
Stephen Kelly wrote:
Christophe Giboudeaux wrote:
find_library(SAMBA_LIBRARIES NAMES smbclient HINTS ${PC_SAMBA_LIBDIR})
This should be _LIBRARY, not _LIBRARIES. Followed by:
set(SAMBA_LIBRARIES ${SAMBA_LIBRARY})
The patch was committed, but this problem was not fixed.
Thanks
Christophe Giboudeaux wrote:
find_library(SAMBA_LIBRARIES NAMES smbclient HINTS ${PC_SAMBA_LIBDIR})
This should be _LIBRARY, not _LIBRARIES. Followed by:
set(SAMBA_LIBRARIES ${SAMBA_LIBRARY})
Thanks,
Steve.
___
Kde-buildsystem mailing list
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112451/#review39359
---
Ship it!
Ship It!
- Stephen Kelly
On Sept. 4, 2013, 2:46
Andreas Pakulat wrote:
I'd say an OR CMAKE_CXX_COMPILER_ID MATCHES 'clang' should be
sufficient,
Actually it would be:
CMAKE_CXX_COMPILER_ID MATCHES Clang
the CMAKE_CXX_COMPILER_ID is not necessarily the same case as the
executable.
Thanks,
Steve.
Andreas Pakulat wrote:
Actually it would be:
CMAKE_CXX_COMPILER_ID MATCHES Clang
the CMAKE_CXX_COMPILER_ID is not necessarily the same case as the
executable.
Ah, well, the cmake manual mentions it with lower c only and since I don't
have a clang at hand to test.
Where?
Ben Cooksley wrote:
I have pushed a fix to next. Please update and try again.
Much appreciated. The build of kde-workspace is now successful again.
Thanks for taking care of that.
Great, thanks for testing the next branch. There will soon be a 2.8.11.1
release which would have had this bug
Ben Cooksley wrote:
Hi Alex,
Can someone more familiar with the CMake community please inform them
of this regression?
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46742/focus=46776
___
Kde-buildsystem mailing list
Alexander Neundorf wrote:
On Monday 20 May 2013, Christophe Giboudeaux wrote:
On Monday 20 May 2013 11:18:57 Christophe Giboudeaux wrote:
On Friday 17 May 2013 11:09:11 Robert Maynard wrote:
On behalf of myself, Ken, Bill, Brad, David, Alex, Eike, Steve, Eric,
Zach, Ben and the rest of
Alexander Neundorf wrote:
There are two issues here:
This change potentially breaks some applications, and not an in obvious
way. This is bad in itself. We should only do that (should we actually
ever do that ?) if there is a really good reason for it.
I don't see any.
What problems does
On 04/21/2013 03:05 PM, Alexander Neundorf wrote:
On Sunday 21 April 2013, Alexander Neundorf wrote:
On Saturday 20 April 2013, Stephen Kelly wrote:
On 02/27/2013 03:59 PM, David Faure wrote:
On Monday 18 February 2013 12:10:31 Dirk Müller wrote:
2013/2/16 Alexander Neundorf neund...@kde.org
On 04/22/2013 08:46 PM, Alexander Neundorf wrote:
On Monday 22 April 2013, Stephen Kelly wrote:
Users of kdelibs will be using either Qt file APIs or something from
kde_file.h, which will still use the definition.
If we use our imagination, we could say that potentially someone could
be using
On 02/27/2013 03:59 PM, David Faure wrote:
On Monday 18 February 2013 12:10:31 Dirk Müller wrote:
2013/2/16 Alexander Neundorf neund...@kde.org:
Dirk Mueller added it in 2008:
http://websvn.kde.org/?view=revisionrevision=829068
If I remove every compiler flag where I'm not sure why it is
Stephen Kelly wrote:
Alexander Neundorf wrote:
Is there a plan what to do with Qt5Transitional.cmake from e-c-m ?
When qt5.git is updated, we can try to remove the use of it.
I've done that now.
In the process I used more imported target names for using Qt.
I you don't like that, so
David Faure wrote:
Later on, when we're about to release KF5, we want to turn this around,
i.e. make it easy to build things for Qt5, and if we still need qt4
support at that point, adding a -DQT4_BUILD=true (and dropping the
QT5_BUILD variable, obviously).
I'd say skip adding the QT5_BUILD
Alexander Neundorf wrote:
Is there a plan what to do with Qt5Transitional.cmake from e-c-m ?
When qt5.git is updated, we can try to remove the use of it.
Thanks,
Steve.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
Alexander Neundorf wrote:
On Sunday 24 March 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
kcodecs doesn't build for me because it doesn't get the QtCore include
dirs.
It has this code:
target_link_libraries(KCodecs LINK_PUBLIC ${QT_QTCORE_LIBRARY} )
This should get
Alexander Neundorf wrote:
This is done e.g. in kwidgets:
target_include_directories(kwidgets PUBLIC
$BUILD_INTERFACE:${kwidgets_INCLUDES}
$TARGET_PROPERTY:kdeui,INTERFACE_INCLUDE_DIRECTORIES
)
I got a question here, why is not simply kdeui used, but why
Alexander Neundorf wrote:
Also, does this apply to the BUILD and INSTALL interface
Yes, it applies to both, because it is not wrapped in either
specifier. I can't think of any reason it would be appropriate for KDE
to have something like that wrapped in BUILD_INTERFACE or
Alexander Neundorf wrote:
On Monday 25 March 2013, Alexander Neundorf wrote:
On Monday 25 March 2013, Stephen Kelly wrote:
...
The interface include directories of kdeui are not copied into
kwidgets.
It's more like a pointer, in c++ terms. If 'kdeui' is in the same
Alexander Neundorf wrote:
Hi,
we now are using the new cmake command target_include_directories() in kde
frameworks.
This makes it possible to specifiy per-target include directories.
When using the keyword PRIVATE, it's the include directories when building
the targets, INTERFACE is the
Alexander Neundorf wrote:
That superbuild directory doesn't seem to work for me. Although I run
cmake on it with cmake master, it seems to try to use cmake 2.8.9 from my
distro when building the subprojects.
Hmm, for me it works as expected.
What exactly did you do ?
The problem was that
Alexander Neundorf wrote:
kcodecs doesn't build for me because it doesn't get the QtCore include
dirs.
It has this code:
target_link_libraries(KCodecs LINK_PUBLIC ${QT_QTCORE_LIBRARY} )
This should get it the include dirs, right ?
No idea, what's in the QT_QTCORE_LIBRARY variable? Can
David Faure wrote:
This is beacuse -I/usr/include is now part of the command line for moc,
before the -I for Qt includes, so it picks up system qt4 headers.
-I/usr/include should never ever be present, since that's a default system
include dir.
For the compiler, that's true, but not for moc.
On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote:
I was quite clear: qmake must point by default to Qt 4 if Qt 4 present.
While qtchooser sounds like a great solution to handle this, it only adds
more confusion from a packager view: we cannot have N differents
configurations for qt
think that
binaries with specific version takes precedence, don't they?
Stephen Kelly wrote:
No, you also need to account for self-built Qt, which will also result in
a binary called 'qmake'.
http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623
Andrea
Alexander Neundorf wrote:
Hi,
in kdelibs4 and, when using FindKF5.cmake, we set the RPATH automatically
by using the cmake target property INSTALL_RPATH_USE_LINK_PATH, and
additionally we add ${LIB_INSTALL_DIR} if it is not a system library
directory.
This means we set a bunch of
Alexander Neundorf wrote:
Assuming you mean the first option, why would it make us require new
versions of cmake often?
With the kde4_add_executable() etc. macros we were able to add things
there, while keeping the required minimum cmake version. Without those
macros, either the developer
Alexander Neundorf wrote:
I don't want to risk having people use a known non-working (in some
regard) version of cmake, and then come to the mailing list and ask,
Yes, I'm sure we'll have some solution between minimum_required and other
version checks.
or worse complain in public how cmake
Alexander Neundorf wrote:
On Saturday 23 February 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
...
or worse complain in public how cmake sucks.
This is not KDEs problem.
...
So, I think we can safely not take responsibility for complaints about
CMake upstream issues.
CMake
Kevin Ottens wrote:
On Friday 08 February 2013 22:36:22 Alexander Neundorf wrote:
Is it only me who would prefer CamelCase to alllowercase names ?
find_package(KConfig NO_MODULE)
Probably makes sense yes, AFAIK the Qt5 modules are camel cased too,
right?
Also I'm wondering if that'd
On 02/18/2013 12:10 PM, Dirk Müller wrote:
2013/2/16 Alexander Neundorf neund...@kde.org:
Dirk Mueller added it in 2008:
http://websvn.kde.org/?view=revisionrevision=829068
If I remove every compiler flag where I'm not sure why it is needed, we'll be
left with not much.
This flag is needed
Hi Alex,
-some compiler flags tweaking
-reenable the test for visibility in Qt
-reenable the test for FILE_OFFSET_BITS=64 (... there may be maybe some
embedded systems where this is not the case ?)
Do you have any reason to think this is needed? The maybe is pretty strong
in
Alexander Neundorf wrote:
On Saturday 16 February 2013, Stephen Kelly wrote:
Hi Alex,
-some compiler flags tweaking
-reenable the test for visibility in Qt
-reenable the test for FILE_OFFSET_BITS=64 (... there may be maybe
some
embedded systems where
1 - 100 of 218 matches
Mail list logo
