Re: Modular building of kde modules
On Tue, Mar 17, 2009 at 20:03, Matthew Woehlke wrote:
Parker Coates wrote:
I've often wished CMake had a construct equivalent to Python's if
__name__ == '__main__' : that would let you run certain code only if
the current file was being run as the top level CMakeLists.txt.
You mean like this?
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
Okay, so we've determined that I /can/. The next question is whether I /should/.
Is this a good idea? Will people reading it actually understand what
I'm trying to do? Is there a more elegant alternative?
Parker
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
On Thursday 19 March 2009, Maciej Mrozowski wrote: On Thursday 19 of March 2009 22:49:13 Alexander Neundorf wrote: On Thursday 19 March 2009, Lubos Lunak wrote: On Wednesday 18 of March 2009, Parker Coates wrote: For example, my app Killbots is quite happy to be built as part of the KDEGames module. But to build it as a standalone app would require adding some setup and dependency checks to the CMake file. These are normally performed by the module level CMake file, so blindly including them in my app would lead to double checks the majority of the time. I am not a cmake expert, but I thought results of checks were cached, so repeating them shouldn't matter? That's correct. But it leads to more cmake script code in our repositories (i.e. it would look more crowded/complicated). Besides it's not possible to really build everything separately (for now) due to following reasons: - some modules rely on relative include paths or just assume that whole toplevel directory (like kdebase/workspace) is present and available. This is due to fact, that some library include files reused by many modules are not installed. The notable example is libkdepim - it's added to includedirs in toplevel CMakeLists.txt, so it just needs to be present while building any other kdepim module, even when libkdepim is actually installed in system. There are some other examples like recently added screenpreviewwidget to libs/kworkspace (reused by kwin, but screenpreviewwidget.h is not installed along libkworkspace), some files from libkonq needed by dolphin and konqueror to be build (konq_copytomenu.h, konq_popupmenuinformation.h) and many more (I could provide a list if anyone is interested). Yes, applications which use libs from the own module need more work. - some modules need to compile sth from the other modules (like some I think now we are getting in trouble with terminology. You mean directories inside the modules, not modules, right ? - some modules possibly would have circular build dependencies if built really separately (again kdepim: kresources-akonadi) I didn't check, but that shouldn't be the case. If it was, I think we would have a problem already right now ? - some modules just for now cannot be built separately, as they all are part of one export unit (KDE4Workspace). Actually they can be built Two issues here: -finding the right granularity for these files (I'd like to make kdelibs at least partially separately installable) -do we really want to support installing each library separately, e.g. from kdebase/workspace ? (I don't think so) Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
On Thursday 19 of March 2009 22:49:13 Alexander Neundorf wrote: On Thursday 19 March 2009, Lubos Lunak wrote: On Wednesday 18 of March 2009, Parker Coates wrote: For example, my app Killbots is quite happy to be built as part of the KDEGames module. But to build it as a standalone app would require adding some setup and dependency checks to the CMake file. These are normally performed by the module level CMake file, so blindly including them in my app would lead to double checks the majority of the time. I am not a cmake expert, but I thought results of checks were cached, so repeating them shouldn't matter? That's correct. But it leads to more cmake script code in our repositories (i.e. it would look more crowded/complicated). Besides it's not possible to really build everything separately (for now) due to following reasons: - some modules rely on relative include paths or just assume that whole toplevel directory (like kdebase/workspace) is present and available. This is due to fact, that some library include files reused by many modules are not installed. The notable example is libkdepim - it's added to includedirs in toplevel CMakeLists.txt, so it just needs to be present while building any other kdepim module, even when libkdepim is actually installed in system. There are some other examples like recently added screenpreviewwidget to libs/kworkspace (reused by kwin, but screenpreviewwidget.h is not installed along libkworkspace), some files from libkonq needed by dolphin and konqueror to be build (konq_copytomenu.h, konq_popupmenuinformation.h) and many more (I could provide a list if anyone is interested). - some modules need to compile sth from the other modules (like some dialogs, they need to moc them, hence just extracting them doesn't work - observed in libkdepim as well, another example is generating dbus interfaces - as well issue of kdepim) - some modules possibly would have circular build dependencies if built really separately (again kdepim: kresources-akonadi) - some modules just for now cannot be built separately, as they all are part of one export unit (KDE4Workspace). Actually they can be built separately, but their export file (KDE4WorkspaceLibraryTargets.cmake in this example) is not useful in such case (it's incomplete as only contains export for actually built module) cannot be used. So separating build process for modules in such organizational unit would require major rework of this mechanism. So far it's static export (doesn't support/detect dependencies and it would be necessary if for example KDE4Workspace was about to be built split) but provides out-of- the box and reliable pkg-config sort of replacement. -- regards MM -- Program tylko dla graczy komputerowych! Ogladaj http://link.interia.pl/f207f ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
Parker Coates wrote:
I've often wished CMake had a construct equivalent to Python's if
__name__ == '__main__' : that would let you run certain code only if
the current file was being run as the top level CMakeLists.txt.
if(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
On Wednesday 18 March 2009, Parker Coates wrote:
On Tue, Mar 17, 2009 at 20:03, Matthew Woehlke wrote:
Parker Coates wrote:
I've often wished CMake had a construct equivalent to Python's if
__name__ == '__main__' : that would let you run certain code only
if the current file was being run as the top level
CMakeLists.txt.
You mean like this?
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
Okay, so we've determined that I /can/. The next question is whether
I /should/.
Is this a good idea? Will people reading it actually understand what
I'm trying to do?
If in doubt add a comment.
Regards,
Ingo
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: Modular building of kde modules
On Wednesday 18 March 2009, Matthew Woehlke wrote: Adding fedora-devel ;-). Alexander Neundorf wrote: On Tuesday 17 March 2009, Matthew Woehlke wrote: Somewhat OT, but one thing I would really appreciate is if I could install kcalc without dragging in the entire bulk of cups due to printer-applet. (This is partly a Fedora problem, however; IOW, I wish they'd split kdeutils - and, for that matter, kdepim - into smaller bites.) Yes, that's a problem of Fedora. I just checked, in kdeutils/ each subdirectory is added using macro_optional_add_subdirectory(), i.e. there is an option which can be used to enable/disable each subdirectory individually, e.g. you can enable BUILD_kcalc and disable all other BUILD_* options and then only kcalc will be included in the build. Unfortunately, I don't think this helps in this instance. When building RPM's, I don't think there is an easy way to do multiple *builds* from a single source (which is the solution methodology you are proposing). Not sure about the way how RPM's are built. At leats in theory you could just set up multiple build dirs, one for each subproject and build there. Or you could do $ svn co --non-recursive kdeutils $ cd kdeutils $ svn co cmake $ svn co kcalc $ ...run cmake and make This should work for most projects. What you can do (and is often done) is split a single build into multiple RPM's at the file level. Therefore I'm not sure KDE needs to change anything. Actually of course it would be even nicer if you could just check out kdeutils/kcalc/ and just build that, but that requires more (although basically boilerplate) work from the developers. This would be the alternative to the above, but as you say, more work for developers. Yes, I'm also not sure if this is really what we want. E.g. for kdepim/kjots/ it is already implemented on request. Plus it means you must split *every* subdir into its own RPM, which probably isn't ideal. No, there is no must. And some packagers want it that way, every app and every library its own package. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
On Wednesday 18 March 2009, Parker Coates wrote:
On Tue, Mar 17, 2009 at 20:03, Matthew Woehlke wrote:
Parker Coates wrote:
I've often wished CMake had a construct equivalent to Python's if
__name__ == '__main__' : that would let you run certain code only if
the current file was being run as the top level CMakeLists.txt.
You mean like this?
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
Okay, so we've determined that I /can/. The next question is whether I
/should/.
Is this a good idea? Will people reading it actually understand what
I'm trying to do? Is there a more elegant alternative?
Well, this comparison says is the current source dir equal to the top level
source dir, i.e. is this project being built as part of a bigger project.
Another way to check would be to ask is this project being built as part of
e.g. kdeutils ?
This could be done like this:
if (NOT kdeutils_SOURCE_DIR)
... build as separate project
endif (NOT kdeutils_SOURCE_DIR)
This is more specific, and could more easily break (e.g. if the
project kdeutils is renamed to KDEUtils or so).
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
Alexander Neundorf wrote: On Wednesday 18 March 2009, Matthew Woehlke wrote: Adding fedora-devel ;-). ...and please keep them in the CC list if it involves Fedora :-). (I think wondering about how rpm's are built qualifies.) Not sure about the way how RPM's are built. At leats in theory you could just set up multiple build dirs, one for each subproject and build there. That would be the best solution if, for some reason, splitting at the installed-file level doesn't work. (Of course, splitting at the installed-file level had probably *better* work or you probably have rpm's with conflicts :-).) Or you could do $ svn co --non-recursive kdeutils $ cd kdeutils $ svn co cmake $ svn co kcalc $ ...run cmake and make RPM's are built from a source tarball; building from VCS sources is discouraged (though permitted when there are valid reasons to do so). Having an rpmbuild do a VCS checkout to obtain the sources is probably forbidden (as in, I haven't actually checked, but I'd be surprised if it isn't). Plus it means you must split *every* subdir into its own RPM, which probably isn't ideal. No, there is no must. Hmm... well, you'd have a harder time creating the source tarball. And some packagers want it that way, every app and every library its own package. True :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I like to think of it as 'unplanned dissonance' -- A fellow chorister ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Modular building of kde modules
On Tuesday 17 March 2009, Matthew Woehlke wrote: Alexander Neundorf wrote: ... Or should we make it easier to build parts of kdelibs separately ? Or structure kdelibs a bit like kdebase, with a set of core libraries (kdecore, kdeui, kio, kfile), and some not so-core stuff, like e.g. katepart, lkhtml, plasma, ftp and http ioslaves, kdoctools, etc. ? I suspect distros wouldn't complain about that :-). Somewhat OT, but one thing I would really appreciate is if I could install kcalc without dragging in the entire bulk of cups due to printer-applet. (This is partly a Fedora problem, however; IOW, I wish they'd split kdeutils - and, for that matter, kdepim - into smaller bites.) Yes, that's a problem of Fedora. I just checked, in kdeutils/ each subdirectory is added using macro_optional_add_subdirectory(), i.e. there is an option which can be used to enable/disable each subdirectory individually, e.g. you can enable BUILD_kcalc and disable all other BUILD_* options and then only kcalc will be included in the build. I just committed a patch to kdelibs/cmake/modules/MacroOptionalAddSubdirectory.cmake which lets you disable all subdirectories in one go, so that it is easier to enable only selected ones, e.g. for kdeutils: $cmake -DDISABLE_ALL_OPTIONAL_SUBDIRECTORIES=TRUE -DBUILD_kcalc kdeutils_dir ... This way you get a build which includes only kcalc. Actually of course it would be even nicer if you could just check out kdeutils/kcalc/ and just build that, but that requires more (although basically boilerplate) work from the developers. My impression is that using macro_add_optional_subdirectory() is at least the much easier way to go to do this. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
Adding fedora-devel ;-). Alexander Neundorf wrote: On Tuesday 17 March 2009, Matthew Woehlke wrote: Somewhat OT, but one thing I would really appreciate is if I could install kcalc without dragging in the entire bulk of cups due to printer-applet. (This is partly a Fedora problem, however; IOW, I wish they'd split kdeutils - and, for that matter, kdepim - into smaller bites.) Yes, that's a problem of Fedora. I just checked, in kdeutils/ each subdirectory is added using macro_optional_add_subdirectory(), i.e. there is an option which can be used to enable/disable each subdirectory individually, e.g. you can enable BUILD_kcalc and disable all other BUILD_* options and then only kcalc will be included in the build. Unfortunately, I don't think this helps in this instance. When building RPM's, I don't think there is an easy way to do multiple *builds* from a single source (which is the solution methodology you are proposing). What you can do (and is often done) is split a single build into multiple RPM's at the file level. Therefore I'm not sure KDE needs to change anything. Actually of course it would be even nicer if you could just check out kdeutils/kcalc/ and just build that, but that requires more (although basically boilerplate) work from the developers. This would be the alternative to the above, but as you say, more work for developers. Plus it means you must split *every* subdir into its own RPM, which probably isn't ideal. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
On Wed, Mar 18, 2009 at 1:03 AM, Matthew Woehlke
mw_tr...@users.sourceforge.net wrote:
Parker Coates wrote:
I've often wished CMake had a construct equivalent to Python's if
__name__ == '__main__' : that would let you run certain code only if
the current file was being run as the top level CMakeLists.txt.
You mean like this?
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
?
(Probably not the most elegant solution, but... bonus points for being
almost an exactly equivalent of the Python you mentioned ;-).)
Wouldn't that fail if there is a CMakeLists.txt doing INCLUDE(
subdirectory/CMakeLists.txt ) ?
dir/CMakeLists.txt -- There is an INCLUDE( subdirectory/CMakeLists.txt ) here
dir/subdirectory/CMakeLists.txt
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
Pau Garcia i Quiles wrote:
On Wed, Mar 18, 2009 at 1:03 AM, Matthew Woehlke
mw_tr...@users.sourceforge.net wrote:
Parker Coates wrote:
I've often wished CMake had a construct equivalent to Python's if
__name__ == '__main__' : that would let you run certain code only if
the current file was being run as the top level CMakeLists.txt.
You mean like this?
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
?
(Probably not the most elegant solution, but... bonus points for being
almost an exactly equivalent of the Python you mentioned ;-).)
Wouldn't that fail if there is a CMakeLists.txt doing INCLUDE(
subdirectory/CMakeLists.txt ) ?
Maybe, but I expect that to break horribly :-). (Certainly I'd expect
subdirectory/CMakeLists.txt to need to know that it will be parsed this
way, which sort-of obviates the need to check if you're top-level.)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
You're on your own for the pony. -- Richard Hughes, on feature requests
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
On Tue, Mar 17, 2009 at 17:32, Alexander Neundorf wrote: I just committed a patch to kdelibs/cmake/modules/MacroOptionalAddSubdirectory.cmake which lets you disable all subdirectories in one go, so that it is easier to enable only selected ones, e.g. for kdeutils: $cmake -DDISABLE_ALL_OPTIONAL_SUBDIRECTORIES=TRUE -DBUILD_kcalc kdeutils_dir ... This way you get a build which includes only kcalc. Actually of course it would be even nicer if you could just check out kdeutils/kcalc/ and just build that, but that requires more (although basically boilerplate) work from the developers. My impression is that using macro_add_optional_subdirectory() is at least the much easier way to go to do this. I've often wished CMake had a construct equivalent to Python's if __name__ == '__main__' : that would let you run certain code only if the current file was being run as the top level CMakeLists.txt. For example, my app Killbots is quite happy to be built as part of the KDEGames module. But to build it as a standalone app would require adding some setup and dependency checks to the CMake file. These are normally performed by the module level CMake file, so blindly including them in my app would lead to double checks the majority of the time. Parker ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
