D28355: Introduce function ecm_install_configured_file

[Pino Toscano]

pino added inline comments.

INLINE COMMENTS

> davidedmundson wrote in ECMConfiguredInstall.cmake:46-48
> Maybe.
> 
> My rationale for not forcing a suffix is sometimes we do this configure dance 
> for .desktop files and there we have to be a bit careful with scripty.
> 
> But generally it's neater and easier to use when a suffix is used. Currently 
> Plasma is all over the place with what suffix to have, so I picked one at 
> random.

No problem either way. My idea is that if a precise suffix is required, then 
setting it //before// this function is merged is better, otherwise doing it 
once it is already in use means breaking potential (mis)users.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D28355

To: davidedmundson
Cc: pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, GB_2, 
bencreasy, michaelh, ngraham, bruns

D28355: Introduce function ecm_install_configured_file

[Pino Toscano]

pino added a comment.


  Nice one! I cannot test right now though, I might do it over the weekend (do 
not hold on me though).
  
  I took the liberty of doing some formatting changes to the header of the new 
file, what do you think?
  
#.rst:
# ECMConfiguredInstall
# 
#
# Take as ``.cmake.in`` file, runs ``configure_file`` and installs it in the
# given location.
#
# ::
#
#   ecm_install_configured_file( )
#
# Example usage:
#
# .. code-block:: cmake
#
#   ecm_install_configured_file(foo.txt.cmake.in 
${KDE_INSTALL_FULL_DATADIR})
#
# This will install the file as ``foo.txt`` with any cmake replacements made
# into the data directory.
#
# Since 5.69.0.


#=
# Copyright 2020  David Edmundson 
  
  Also, not sure whether you need a .rst file in the docs/module/ directory.

INLINE COMMENTS

> ECMConfiguredInstall.cmake:46-48
> +# strip .cmake.in from the end
> +# if that isn't there, we continue as-is
> +string(REGEX REPLACE ".cmake.in$"  "" _name ${_name})

considering we are documenting the input file as `.cmake.in`, should we enforce 
this here and ignore any file not ending like that?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D28355

To: davidedmundson
Cc: pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, GB_2, 
bencreasy, michaelh, ngraham, bruns

D28355: Introduce function ecm_install_configured_file

[Pino Toscano]

pino added a comment.


  Can you please adapt it so `_template` can be an absolute path?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D28355

To: davidedmundson
Cc: pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, GB_2, 
bencreasy, michaelh, ngraham, bruns

D17718: Use ECMGeneratePkgConfigFile to create the pkgconfig file.

[Pino Toscano]

pino added a comment.


  In D17718#380261 , @alexeymin 
wrote:
  
  > I tested this, it indeed fixes 390225
  >  Withoug this patch, generated pkgconfig file was:
  >
  >   prefix=/usr
  >   exec_prefix=bin
  >   libdir=lib/x86_64-linux-gnu
  >   includedir=include
  >  
  >   Name: libKActivities
  >   Description: libKActivities is a C++ library for using KDE activities
  >   URL: http://www.kde.org
  >   Requires: Qt5Core
  >   Version: 
  >   Libs: -Llib/x86_64-linux-gnu -lKF5Activities
  >   Cflags: -Iinclude
  >
  >
  > With this, version field is filled in and full paths are specified:
  >
  >   Name: libKActivities
  >   Description: libKActivities is a C++ library for using KDE activities
  >   Version: 5.54.0
  >   Libs: -L/usr/lib/x86_64-linux-gnu -llibKActivities
  
  
  This seems wrong to me, the library is called `KF5Activities` and not 
`libKActivities`.
  
  > Cflags: -I/usr/include/libKActivities
  
  Ditto.

REPOSITORY
  R6 KActivities

REVISION DETAIL
  https://phabricator.kde.org/D17718

To: cgiboudeaux, cfeck, #build_system, alexeymin
Cc: pino, alexeymin, kde-frameworks-devel, michaelh, ngraham, bruns

D16938: FindQHelpGenerator: try to find Qt5Help instead of Qt5Core

[Pino Toscano]

pino closed this revision.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D16938

To: pino, kossebau
Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D16938: FindQHelpGenerator: try to find Qt5Help instead of Qt5Core

[Pino Toscano]

pino created this revision.
pino added a reviewer: kossebau.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
pino requested review of this revision.

REVISION SUMMARY
  The Qt5Help CMake modules contain the Qt5::qhelpgenerator target, so
  look for that instead of Qt5Core.  Otherwise, the Qt5::qhelpgenerator
  is available only if Qt5Help was searched previously (which does not
  happen often).
  
  Using the Qt5::qhelpgenerator is more reliable than the search for the
  qhelpgenerator executable based on the qmake path.

TEST PLAN
  build some framework with -DBUILD_QCH=ON, and notice that
  the right path of qhelpgenerator is found directly with the
  Qt5::qhelpgenerator target.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  find-qhelpgenerator-target

REVISION DETAIL
  https://phabricator.kde.org/D16938

AFFECTED FILES
  find-modules/FindQHelpGenerator.cmake

To: pino, kossebau
Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D3830: Add a new FindGperf module

[Pino Toscano]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:c61aee80d647: Add a new FindGperf module (authored by 
pino).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D3830?vs=9502=14562#toc

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3830?vs=9502=14562

REVISION DETAIL
  https://phabricator.kde.org/D3830

AFFECTED FILES
  find-modules/FindGperf.cmake

To: pino, #windows, #frameworks, #build_system, kde-mac, adridg, rjvbb
Cc: kfunk, rjvbb, adridg

D3830: Add a new FindGperf module

[Pino Toscano]

pino added a comment.


  Ping?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3830

To: pino, #frameworks, #build_system, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

[Differential] [Commented On] D3830: Add a new FindGperf module

[pino (Pino Toscano)]

pino added a comment.


  In https://phabricator.kde.org/D3830#72696, @rjvbb wrote:
  
  > In https://phabricator.kde.org/D3830#72508, @pino wrote:
  >
  > > For the input file? Yes.
  >
  >
  > I did mean the gperf executable...!
  
  
  I don't get what you mean, sorry :/ The full path of gperf is determined 
using `find_program`, which looks in `$PATH` -- you can always specify the 
variable with the full path to force a custom location.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3830

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

[Differential] [Commented On] D3830: Add a new FindGperf module

[pino (Pino Toscano)]

pino added a comment.


  In https://phabricator.kde.org/D3830#72502, @rjvbb wrote:
  
  > You're still determining the location from the path with this new revision, 
right?
  
  
  For the input file? Yes.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3830

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

[Differential] [Updated, 125 lines] D3830: Add a new FindGperf module

[pino (Pino Toscano)]

pino updated this revision to Diff 9502.
pino added a comment.


  Typo fix in previous revision.

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3830?vs=9499=9502

BRANCH
  pino-gperf

REVISION DETAIL
  https://phabricator.kde.org/D3830

AFFECTED FILES
  find-modules/FindGperf.cmake

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

[Differential] [Updated, 125 lines] D3830: Add a new FindGperf module

[pino (Pino Toscano)]

pino updated this revision to Diff 9499.
pino added a comment.
Restricted Application added projects: Frameworks, Buildsystem.


  Use a full path for the output location.

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3830?vs=9408=9499

BRANCH
  pino-gperf

REVISION DETAIL
  https://phabricator.kde.org/D3830

AFFECTED FILES
  find-modules/FindGperf.cmake

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

[Differential] [Commented On] D3830: Add a new FindGperf module

[pino (Pino Toscano)]

pino added a comment.


  Cool -- thanks guys for the feedback on FreeBSD/Mac/Windows!

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3830

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

[Differential] [Commented On] D3830: Add a new FindGperf module

[pino (Pino Toscano)]

pino added a comment.


  Windows and Mac people: at least from a quick glance, GNU gperf should be 
already available on Windows and Mac; can you please confirm the new (build 
time only) dependency could be acceptable?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3830

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #kde_buildsystem, #windows, kde-mac

Re: Review Request 119696: KDECompilerSettings: Be more portable across libc's.

[Pino Toscano]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119696/#review64195
---



kde-modules/KDECompilerSettings.cmake
https://git.reviewboard.kde.org/r/119696/#comment44849

There's also GNU/kFreeBSD which uses GNU libc. Its CMAKE_SYSTEM_NAME is 
kFreeBSD, so please also match k.*BSD if you do OS-based selection.

But, in general, if you are really looking at the libc like your change 
hints, then do a compiler check, like I did in 
kde-dev-utils.git/kmtrace/CMakeLists.txt.


- Pino Toscano


On Ago. 10, 2014, 5:39 p.m., Raphael Kubo da Costa wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119696/
 ---
 
 (Updated Ago. 10, 2014, 5:39 p.m.)
 
 
 Review request for Extra Cmake Modules and Alex Merry.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 Defining _XOPEN_SOURCE to 500 is too restrictive: it corresponds to
 _POSIX_C_SOURCE 199506L, and hides several symbols that standard
 libraries like libc++ expect to find, leading to errors like this on
 FreeBSD:
 
   In file included from /tmp/attica/src/accountbalance.cpp:21:
   In file included from /tmp/attica/src/accountbalance.h:25:
   In file included from /usr/local/include/qt5/QtCore/QString:1:
   In file included from /usr/local/include/qt5/QtCore/qstring.h:50:
   In file included from /usr/include/c++/v1/string:437:
   In file included from /usr/include/c++/v1/string:437:
   /usr/include/c++/v1/cstdio:143:9: error: no member named 'snprintf' in the 
 global namespace
   using ::snprintf;
 ~~^
 
 This isn't a problem on Linux because defining _GNU_SOURCE enables a lot
 more features that are not made available on other libc implementations
 where it does not have any effect.
 
 Instead, stop defining _XOPEN_SOURCE at all and leave it up to the
 platform to show or hide as many symbols as necessary if no
 standards-related defines are set, and only set _GNU_SOURCE on systems
 where it is actually meaningful (Linux and Hurd), as we were doing
 before 81233a52 (Organise KDECompilerSettings.cmake more logically).
 
 
 Diffs
 -
 
   kde-modules/KDECompilerSettings.cmake 
 fdc930e48e489696e137c546fd7e00e0c4797243 
 
 Diff: https://git.reviewboard.kde.org/r/119696/diff/
 
 
 Testing
 ---
 
 Attica builds on FreeBSD.
 
 
 Thanks,
 
 Raphael Kubo da Costa
 


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: kdepimlibs dependency on nepomuk-core breaks build for Calligra and kdeplasma-addons

[Pino Toscano]

Alle lunedì 17 dicembre 2012, Ben Cooksley ha scritto:
 Currently build.kde.org is unable to successfully complete builds of
 kdeplasma-addons and Calligra due to recent changes in kdepimlibs.
 These changes are a port from Nepomuk (part of kdelibs) to
 NepomukCore (a seperate repository).
 
 As kdepimlibs uses the *Config.cmake method of exporting it's
 location, this means that the proper location of the library is not
 set correctly.
 The nepomukcore library will only be found if all projects which
 depend on kdepimlibs include the following:
 find_package(NepomukCore)

Simple: nepomuk-core/NepomukCoreConfig.cmake.in is broken (see 
NEPOMUK_CORE_LIB_DIR and NEPOMUK_CORE_LIBRARY).

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: kdepimlibs dependency on nepomuk-core breaks build for Calligra and kdeplasma-addons

[Pino Toscano]

Alle lunedì 17 dicembre 2012, Alexander Neundorf ha scritto:
 On Monday 17 December 2012, Pino Toscano wrote:
  Alle lunedì 17 dicembre 2012, Ben Cooksley ha scritto:
   Currently build.kde.org is unable to successfully complete builds
   of kdeplasma-addons and Calligra due to recent changes in
   kdepimlibs. These changes are a port from Nepomuk (part of
   kdelibs) to NepomukCore (a seperate repository).
   
   As kdepimlibs uses the *Config.cmake method of exporting it's
   location, this means that the proper location of the library is
   not set correctly.
   The nepomukcore library will only be found if all projects which
   depend on kdepimlibs include the following:
   find_package(NepomukCore)
  
  Simple: nepomuk-core/NepomukCoreConfig.cmake.in is broken (see
  NEPOMUK_CORE_LIB_DIR and NEPOMUK_CORE_LIBRARY).
 
 It needs absolute install paths, but beside that I don't see anything
 obvious wrong.

You just described the issue, yet don't see anything wrong?
And _LIB_DIR should just go, once the other is fixed.

(P.S.: please do not mail me directly, two mailing lists are enough, 
thanks.)

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: kde4 marbles

[Pino Toscano]

Hi,

Alle giovedì 22 aprile 2010, lux-integ ha scritto:
 [...]
 * Experimental Python binding support for the Marble
  library http://techbase.kde.org/Development/Languages/Python
  Experimental Python binding support for the Marble library
  Experimental Python binding support for the Marble library. To
  activate it pass -DEXPERIMENTAL_PYTHON_BINDINGS=TRUE to cmake.
 [...]
 I have already installed pyKDE4  from kdebindings-4.4.2.  Does  the
  above mean  that  if the  marble library  is required  I have to
  re-compile pyKDE4 with  -DEXPERIMENTAL_PYTHON_BINDINGS=TRUE 
  passed to cmake or is it another procedure and if so what is it?

Marble ships its own python binding with itself, so you need to pass
-DEXPERIMENTAL_PYTHON_BINDINGS=TRUE to kdeedu's cmake invocation to 
build it.

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Cross compiling KDE / Nokia N900

[Pino Toscano]

Alle mercoledì 23 dicembre 2009, Alexander Neundorf ha scritto:
 On Wednesday 23 December 2009, Pino Toscano wrote:
  Hi,
 
  Alle mercoledì 23 dicembre 2009, Alexander Neundorf ha scritto:
   Yes, it's also on my todo, but it would be really nice if somebody else
could actually do the work and I would just guide throught the
   necessary steps.
  
   There are mainly three things which lead to problems when cross
   compiling: 1) try to build and run executable during the configure
   check [...]
  
   1) is the hardest one. If somebody does a try_run
   (check_c_source_runs()) in a cross compile, it will build the
   executable, but it will not try to run it (since it can't, in general).
   Instead cmake will provide a template cmake script file prepared so
   that the expected values from the try_run() can be entered there
   manually. Also the compiled executable is made available, so that the
   developer can take it, run it on the target and in this way figure out
   the result which have to go into the prepared cmake script file. This
   file than has to be preloaded into cmake using -C on the next cmake
   run. Doing this for all try_run()s is actual work.
 
  I think this point could be solved if cmake would have the distinction
  between host (the platform it is building for) and build (the
  platform it is building on) compilers (of course, in case of no
  crosscompilation, host and build stuff would be the same).
 
 This is the case since cmake 2.6.0 :-)
 You can check
 if (CMAKE_CROSSCOMPILING)
  ...
 
 and you have CMAKE_SYSTEM_NAME (target host) and CMAKE_HOST_SYSTEM_NAME
  (build host), if not cross compiling both are the same.

I know cmake can do cross compiling this way (I do that at work), but it's far 
from being pain-free.

  For example, take the check_c_source_runs() example, and assume I'm
  crosscompiling on i386 (build gcc: cc) for arm (host cc: arm-linux-cc):
  check_c_source_runs() would be compiled using the build compiler (cc), so
  it can be run later.
 
 Do you mean that even when cross compiling the i386 gcc should be used for
 check_c_source_runs() ?
 This wouldn't make sense. The sources must be built using the target
  compiler (arm_linux-cc), since
 -host and target compiler may be completely different compilers (think gcc
  and sdcc, or msvc and gcc)
 -being able to compile and link the source with the host (i386) compiler
 doesn't tell you anything about whether it would also link on the target
 system
 -running it in the build host environment doesn't tell you anything about
  the target environment

Those points are valid, although there cold be situations where you want to do 
that anyway: for example, a small program that #include some version.h-like 
header, and outputs different stuff depending on different #if VERSION_MAJOR  
4 ... #elif VERSION_MAJOR  2 ... etc. This is so simple no compiler/toolchain 
could get it wrong.

Furthermore, there's still the other case of usefulness for having build and 
host compilers separated:

  This would have the advantage I could force the use of the build compiler
  for intermediate build steps, for example a custom target which has to
  compile some executable and run it to get the input files for other
  targets.

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE/kdepimlibs

[Pino Toscano]

Alle martedì 12 maggio 2009, Andreas Pakulat ha scritto:
 On 11.05.09 23:23:25, Pino Toscano wrote:
  Alle lunedì 11 maggio 2009, Christophe Giboudeaux ha scritto:
   SVN commit 966746 by cgiboudeaux:
  
   As mentioned by Alex when KDEPIMLIBS_INCLUDE_DIRS was created,
   installing the kdepimlibs CamelCase headers in the same dir as the
   kdelibs ones is not a good idea. (different package - different dir).
  
   They will now be installed in include/KDEPIMLIBS.
 
  I don't understand the logic behind this move.

 For one thing, it makes sure we don't get name clashes, which is
 particularly bad as CMake will just happily overwrite existing files
 without further notice.

If there is a name clash, then this won't solve anything, as doing
#include clashingheader.h
(with no path, assuming you added it in the include path).
And still, did we actually have this issue, yet?

  Currently, we have the following situation:
  - all the .h files from any KDE modules go to $prefix/include

 KDevPlatform and any public API from KDevelop plugins all go into
 $prefix/include/kdevplatform/$library and
 $prefix/include/kdevelop/$plugin

 So its not all KDE modules :)

Actually you've just proven my point, because kdevelop _does_ install them in 
$prefix/include, just organized them in a subdir.
The right comparison would have been if kdevelop installs them in let's say 
$prefix/kdevelop-include.

  - before this commit, all the CamelCase includes would go
  $prefix/include/KDE, from any KDE module (eg kdelibs, kdepimlibs,
  kdebase-workspace, kdegames, etc)
  But now kdepimlibs differs and will install its CamelCase includes in a
  different location. I don't see them conflicting with kdelibs (or other
  modules) ones, so... why?

 Not now, but what about the future? IMHO _all_ modules should do the
 same as kdepimlibs does. _No_ library should ever install headers
 directly into $prefix/include, they should _always_ be in
 $prefix/include/$library - IMHO. And thats also what distributions
 patch into their package anyway.

Again, you did not understand me.
I'm not speaking about the direct installation of .h files in 
$prefix/includes, but the installation of CamelCase headers for kdepimlibs, 
which before were in $prefix/include/KDE (which _is_ namespaced enough 
already) to $prefix/include/KDEPimLibs.
Isn't $prefix/include/KDE namespaced already?

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE/kdepimlibs

[Pino Toscano]

Alle martedì 12 maggio 2009, Andreas Pakulat ha scritto:
  to $prefix/include/KDEPimLibs.
  Isn't $prefix/include/KDE namespaced already?

 Yes, across all of KDE main modules, which might or might not be enough. If
 KDevPlatform would install camelcase versions of its public API into
 prefix/include/KDE we'd most probably have naming clashes rather sooner
 than later because of:

 IPlugin
 ICore
 IAssistant
 ISession
 ProjectModel

 and possibly more. And namespacing those files with KDev_ would obviously
 defeat the purpose of the camelcase includes.

And in such case, you would do like it has been done so far: grouping by 
namespace:
- $prefix/include/KDE/Plasma/Dialog for namespace Plasma { class Dialog; }
- $prefix/include/KDE/KCal/Alarm for namespace KCal { class Calendar; }
- $prefix/include/KDE/DOM for KHTML's DOM classes in namespace DOM
that, in your case, would be 
- $prefix/include/KDE/KDevelop/IAssistan for namespace KDevelop { class 
IAssistant }

Don't see anything bad in doing that. Especially in case of kdepimlibs, whose 
classes are already grouped in such way (see 
kdepimlibs/includes/CMakeLists.txt), so you would not see 
$prefix/include/KDE/Calendar.

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE/kdepimlibs

[Pino Toscano]

Alle lunedì 11 maggio 2009, Christophe Giboudeaux ha scritto:
 SVN commit 966746 by cgiboudeaux:

 As mentioned by Alex when KDEPIMLIBS_INCLUDE_DIRS was created, installing
 the kdepimlibs CamelCase headers in the same dir as the kdelibs ones is not
 a good idea. (different package - different dir).

 They will now be installed in include/KDEPIMLIBS.

I don't understand the logic behind this move.

Currently, we have the following situation:
- all the .h files from any KDE modules go to $prefix/include
- before this commit, all the CamelCase includes would go $prefix/include/KDE, 
from any KDE module (eg kdelibs, kdepimlibs, kdebase-workspace, kdegames, 
etc)
But now kdepimlibs differs and will install its CamelCase includes in a 
different location. I don't see them conflicting with kdelibs (or other 
modules) ones, so... why?

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Remove FindBoost.cmake from kdelibs

[Pino Toscano]

Alle mercoledì 06 maggio 2009, Alexander Neundorf ha scritto:
 Or how about that ?
 Instead of completely removing FindBoost.cmake, we replace it with an
 almost empty one:

 set(Boost_ADDITIONAL_VERSIONS 1.39.0 1.39 1.38.0 1.38
   1.37.0 1.37)

 include(${CMAKE_ROOT}/Modules/FindBoost.cmake)

 This way we wouldn't have additional logic in our version, but we would
 still add these version numbers so we stay compatible.
 (and it would be very local).

Looks a nicer solution indeed, but just with a variant:

set(Boost_ADDITIONAL_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
1.39.0 1.39 1.38.0 1.38 1.37.0 1.37)

so users can still set Boost_ADDITIONAL_VERSIONS it to add additional Boost 
versions, and having the same meaning as in FindBoost.cmake (ie more priority 
than the versions in it).

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Remove FindBoost.cmake from kdelibs

[Pino Toscano]

Alle martedì 05 maggio 2009, Andreas Pakulat ha scritto:
 On 14.04.09 19:15:17, Alexander Neundorf wrote:
  On Saturday 11 April 2009, Andreas Pakulat wrote:
   as cmake 2.6.2 and 2.6.3 ship with very good FindBoost.cmake files and
   the module has a dedicated maintainer who quickly responds to
   bugreports, how about removing the one in kdelibs? If removing is not
   an option, we should at least update it to the version thats being
   shipped with CMake 2.6.4.
  
   Thoughts?
 
  It's up to you, you know that module.
  We require CMake = 2.6.2, so please make sure whatever you do it works
  with CMake 2.6.2.
  (also if you go for updating to the version from CMake 2.6.4, check that
  there's nothing in it which breaks with 2.6.2).

 I finally remembered and did this now. There's one problem, the version
 in kdelibs already has been updated to include out of the box support
 for boost 1.37 (1.37 has been added to the _boost_TEST_VERSIONS
 variable). While cmake 2.6.2 only has 1.36.1 in it. So all places using
 find_package(Boost) would need to be adjusted to set
 Boost_ADDITIONAL_VERSIONS before finding boost.

What about adding in FindKDE4Internal.cmake a snippet like:
  set(_KDE_Boost_ADDITIONAL_VERSIONS 1.39.0 1.39 1.38.0 1.38
 1.37.0 1.37)
  set(Boost_ADDITIONAL_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
${_KDE_Boost_ADDITIONAL_VERSIONS})
this way:
a) there's no need to have an additional FindBoost.cmake
b) the internal _KDE_Boost_ADDITIONAL_VERSIONS variable will be updated to 
contain the list of Boost versions not covered by the FindBoost.cmake of the 
minimum cmake version we depend upon
c) if somebody specifies Boost_ADDITIONAL_VERSIONS on cmake command line, that 
value will have precedence over any other, like now
d) we can guarantee compatibility for KDE applications (as long as 
find_package(Boost) is called -after- find_package(KDE4), as the list of 
Boost releases will always be the one we want (cmake ones + new ones not yet 
covered, see b) too)
Does it sound reasonable or am I missing anything?

 I guess that means removing the file is not an option at the moment and
 as its pretty close to the release I'll re-tackle this after trunk/ is
 open for 4.4, so I don't create any problems just before releasing when
 updating the file to the cmake 2.6.4 version.

In case, out FindBoost.cmake should be updated for Boost 1.38 and 1.39 
(released three days ago). I can do that, whichever solution we agree about 
(ie mine above or our FindBoost.cmake).

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FindBoostPython.cmake in kdeedu

[Pino Toscano]

Hi,

I am the author of that module.

 while we're disussing the FindBoost.cmake - why is there a special
 FindBoostPython.cmake in kdeedu? Isn't this handled within FindBost?

No, they are not the same thing.
FindBoostPython.cmake looks for a valid boost+python combination, ie the right 
python version for a boost version. Note that does not mean picking the first 
boost found with the first python found.

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FindKdepimLibs should require Boost

[Pino Toscano]

Alle lunedì 04 agosto 2008, Andreas Pakulat ha scritto:
 Hi,

 I hope the subject doesn't stir up a flame-war. I'm not questioning the
 dependency. My question is: Shouldn't FindKdepimLibs.cmake be requiring
 Boost?

No, but do an extra check for the few parts that actually do require Boost.

 So shouldn't FindKdepimLibs.cmake have a find_package call for Boost,
 probably requiring it. After all its impossible to use all of kdepimlibs
 without boost.

Eh? It seems only syndication, gpgme++, qgpgme and akonadi-kde expose a Boost 
dependency in their public headers, while everything else does not (please 
any PIM people verify that). That means that more than half of the kdepimlibs 
libraries (ie kcal, kabc, kblog, kldap, etc) can be used without Boost.

 Or we need more logic in FindKdepimLibs.cmake setting 
 individual _FOUND variables for the individual libs and setting this to
 no if boost is not found but the specific library contains boost stuff
 in its public headers (like libsyndication).

Yes.

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE/kdelibs/cmake/modules

[Pino Toscano]

Alle martedì 20 maggio 2008, Allen Winter ha scritto:
  I don't think FindX11.cmake is the place to put this. It should be in the
  KDE code that requires X11 in the first place. In fact, it should be in
  the code that requires ICE and/or SM, since other parts of KDE may be
  just fine compiling with X11, but not those two.

 I thought about that.. but SM is needed by kdeui/kernel/kapplication.
 And I don't see any point compiling KDE without it.

I do: there's no need to carry on all the kdelibs dependancies when compiling 
other modules.
Use case: somebody install kde (or just kdelibs) from his distro (a 
non-source-based one, be it debian, opensuse, fedora, ubuntu, etc), and then 
develops an own application (or comple some other app). Then they basically 
don't need the SM/ICE headers at all (and most probably not even the X11 
ones).

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Building Docs with meinproc

[Pino Toscano]

Alle 04:23, mercoledì 17 gennaio 2007, Allen Winter ha scritto:
 I'm trying to implement the building of the docs in our cmake buildsystem.

Nice!

 Here's what I have so far:

 In KDE4Macros.cmake I added this macro
 -
 macro (KDE4_CREATE_HTML_HANDBOOK)
# iterate over all  files
foreach (_current_FILE ${ARGN})
   get_filename_component(_input ${_current_FILE} ABSOLUTE)
   set(_doc ${CMAKE_CURRENT_BINARY_DIR}/index.html)
   add_custom_command(OUTPUT ${_doc}
  COMMAND ${KDE4_MEINPROC_EXECUTABLE}
  ARGS --check --cache ${CMAKE_CURRENT_BINARY_DIR}/index.cache.bz2
  -o ${_doc}
  ${_input}
  MAIN_DEPENDENCY ${_input}
   )
endforeach (_current_FILE)
 endmacro (KDE4_CREATE_HTML_HANDBOOK)

Hmm it doesn't seem to be correct.
Let's sum up how to regenerate:
- meinproc [--check] index.docbook
  this generates only the HTML documentation from the specified docbook. Note 
that the HTML documentation is not just an index.html, but many files.
- meinproc [--check] --cache cachefile index.docbook
  generates only the cachefile (usually index.cache.bz2)

Note that in both cases you have to specify always the index file, even if the 
documentation is splitted into several files.

Regards,

-- 
Pino Toscano


pgpT967itP88H.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Poppler-qt4

[Pino Toscano]

Alle 13:41, giovedì 29 giugno 2006, Laurent Montel ha scritto:
 There is two cmake file which allows to search poppler-qt4:
 One into kdegraphics/cmake/module/FindPopplerQt4.cmake
 one into playground/graphics/cmake/modules/FindPoppler.cmake

I am the author of the latter, and I planned to do that merge in case of a 
moving of okular to kdegraphics.

 I will want to move one into kdelibs (because it duplicates)

 One which is into playground search poppler-qt4 = 0.5.2 so I will add it
 into kdelibs and I will want to rename it as FindPopplerQt4.cmake because
 it's a better name for it (and renamed variable to add qt4 suffix)

 Can I make it ?

Actually, there's a small issue: okular stricly requires Poppler-Qt4 = 0.5.3 
(yes, I have to update it) and this dependancy could raise if there will be 
new features needed for okular, while any other application that uses 
Poppler-Qt4 (kfile-pdf, kviewshell, krita maybe?) just want it with no 
particular requires on its version.
And if the minimum version for okular will be raised, should we keeping the 
kdelibs one updated?

Regards,

-- 
Pino Toscano


pgpJh2pZXXraF.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Poppler-qt4

[Pino Toscano]

Alle 22:06, giovedì 29 giugno 2006, Wilfried Huss ha scritto:
 Besides, okular's fork of the DVI code has thrown away 9 years of commit
 history. This is also a problem. I thougt KDE switched to SVN so that such
 things would not happen again.

Now the files are really copied, and no history is lost. Luckly SVN is smart 
enough.

Regards,

-- 
Pino Toscano


pgpmv3141BNyR.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Asking for a CMake feature

[Pino Toscano]

Alle 04:59, venerdì 14 aprile 2006, Brad King ha scritto:
 Albert Astals Cid wrote:
  unsermake had a nice feature that when doing
  make install
  did only really install what had changed, that is quite important,
  because imagine you fix one header in kdelibs and do make install, ALL
  headers are installed and automatically all your programs want to start
  rebuilding because they think the header changed.
 
  If only the changed header is installed things rebuild much less and my
  productivity increases.
 
  So, please please please, can CMake devels make this happen?

 Fixed in CVS CMake.

Are you sure it's fixed?
This morning I compiled and installed the new kdelibs snapshot.
Now I just updated and recompiled to have a fix in kdeui/kactionclasses.cpp 
and another one in a kdeprint module. make recompiled the two changed files 
and did the link of the libraries which depends on kdeui, and then a make 
install did the relink and reinstalled *all*.
Yes, using cmake 2.4.0beta, the version released 6 days ago.

Regards,

-- 
Pino Toscano


pgpAb0ogFGfb8.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Breaking a foreach loop

[Pino Toscano]

Alle 16:20, martedì 18 aprile 2006, Brad King ha scritto:
 Pino Toscano wrote:
  Hello,
 
  imagine I'm iterating using a foreach() like this:
  set(MY_OPTS foo bar etc)
  foreach(OPT ${MY_OPTS})
# do something ...
  endforeach(OPT ${MY_OPTS})
 
  is there a way to break the iteration, just like a break in C?
 
  Whether it exist, does it break even nested foreach()?

 This is not possible, but you can simulate it yourself:

 SET(OPT_DONE 0)
 foreach(opt ${MY_OPTS})
if(NOT OPT_DONE)
  #...code...
  if(..need to break..)
set(OPT_DONE 1)
  endif(..need to break..)
endif(NOT OPT_DONE)
 endforeach(opt)

That is not what I would like, as this would continue executing the loop. And 
if the foreach loop is inside another foreach loop, having to execute all the 
iterations is not my best plan...

Regards,

-- 
Pino Toscano


pgpOLXAP7sF31.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Trimming newlines from a string

[Pino Toscano]

Hello,

finally, I'm subscribed too! :)

First mail, first question: imagine I have a string made by a newline 
character only, ie the line
message(STATUS myvar: \${myvar}\)
would output
-- Found ...
-- myvar: 

-- Found ...
Doing a
STRING(REGEX REPLACE \\n?\\r?  myvar ${myvar})
have the result to make cmake output that the regexp matches an empty string.

Do you have any precious suggestion about sometimg that I'm missing?

Regards,

-- 
Pino Toscano


pgp1mZ7o4K8Zx.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem