Re: patch: c/cxxflags for static libraries
Matt Broadstone wrote: Well its not so much that I want a convenience lib, as I want a logical breakdown of the parts within a whole. For me it makes a lot more sense to build khtml in its pieces: dom, ecma, java, html etc. and then link them together in the whole. Furthermore, when I've been using my patch to build khtml, when I make simple changes inside ecma/debugger I no longer have to build the entirety of khtml. This may be a problem with cmake, as this should not necesarily be the case considering I haven't touched code that affects all of khtml, but that's what happens. If we can find a way around this, ie. change the CMakeLists.txt for khtml in such a way that simple changes in each module do not affect the entirety of khtml, then that's a decent solution. But for now, on my box, doing it this way (convenience, modular, whatever you want to call it :) ) works better for me, and I simply thought it might work better for others as well. I don't see how your solution can work. If you modify one file, you must compile it then link libkhtml. Isn't that what cmake is doing? How would introducing an intermediary step (create a .a) improve things? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpycG8KR10x9.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
small patch imlib and kuickshow
Hi!
I have a small cmake-patch for building kuickshow. Please have a look at
it and commit this too trunk.
Thanks
By
Marcus
Index: kdegraphics/cmake/modules/FindIMLIB.cmake
===
--- kdegraphics/cmake/modules/FindIMLIB.cmake (Revision 564004)
+++ kdegraphics/cmake/modules/FindIMLIB.cmake (Arbeitskopie)
@@ -20,7 +20,7 @@
# in the FIND_PATH() and FIND_LIBRARY() calls
INCLUDE(UsePkgConfig)
- PKGCONFIG(libagg _IMLIBIncDir _IMLIBLinkDir _IMLIBLinkFlags _IMLIBCflags)
+ PKGCONFIG(imlib _IMLIBIncDir _IMLIBLinkDir _IMLIBLinkFlags _IMLIBCflags)
set(IMLIB_DEFINITIONS ${_IMLIBCflags})
@@ -30,17 +30,17 @@
/usr/local/include
)
- FIND_LIBRARY(IMLIB_LIBRARIES NAMES Imlib
+ FIND_LIBRARY(IMLIB_LIBRARIES NAMES Imlib libImlib
PATHS
${_IMLIBLinkDir}
/usr/lib
/usr/local/lib
)
-
+
if (IMLIB_INCLUDE_DIR AND IMLIB_LIBRARIES)
- SET(imlib_found true)
+ SET(IMLIB_FOUND true)
endif (IMLIB_INCLUDE_DIR AND IMLIB_LIBRARIES)
-
+
if (IMLIB_FOUND)
set(CACHED_IMLIB YES)
if (NOT IMLIB_FIND_QUIETLY)
@@ -48,6 +48,9 @@
endif (NOT IMLIB_FIND_QUIETLY)
else (IMLIB_FOUND)
set(CACHED_IMLIB NO)
+if (NOT IMLIB_FIND_QUIETLY)
+ message(STATUS didn't find IMLIB)
+endif (NOT IMLIB_FIND_QUIETLY)
if (IMLIB_FIND_REQUIRED)
message(FATAL_ERROR Could NOT find IMLIB)
endif (IMLIB_FIND_REQUIRED)
Index: kdegraphics/CMakeLists.txt
===
--- kdegraphics/CMakeLists.txt (Revision 564004)
+++ kdegraphics/CMakeLists.txt (Arbeitskopie)
@@ -12,10 +12,12 @@
macro_optional_find_package(Gphoto2)
macro_optional_find_package(Sane)
macro_optional_find_package(OpenGL)
+macro_optional_find_package(IMLIB)
MACRO_LOG_FEATURE(GPHOTO2_FOUND libgphoto2 Need to build kamera project http://heanet.dl.sourceforge.net/sourceforge/gphoto/; FALSE )
MACRO_LOG_FEATURE(SANE_FOUND libsane Sane lib is needed to build kooka project http://www.sane-project.org/; FALSE )
-MACRO_LOG_FEATURE(OPENGL_FOUND libopengl OpenGl lib is need to build kpovmodeler project http://www.X.org; FALSE )
+MACRO_LOG_FEATURE(OPENGL_FOUND libopengl OpenGl lib is need to build kpovmodeler project http://www.X.org/; FALSE )
+MACRO_LOG_FEATURE(IMLIB_FOUND imlib imlib is need to build kuickshow project http://www.gnome.org/; FALSE )
# are these two really required ?
find_package(ZLIB REQUIRED)
@@ -66,7 +68,8 @@
add_subdirectory(kruler)
add_subdirectory(ksnapshot)
if (IMLIB_FOUND)
- add_subdirectory(kuickshow)
+ MESSAGE(STATUS port kuickshow!)
+ #add_subdirectory(kuickshow)
endif (IMLIB_FOUND)
add_subdirectory(kviewshell)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: small patch imlib and kuickshow
On Wednesday 19 July 2006 08:36, Marcus Hufgard (Kalkwerk Hufgard GmbH) wrote: Hi! I have a small cmake-patch for building kuickshow. Please have a look at it and commit this too trunk. Apply thanks. Regards Thanks By Marcus ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Convenience Libraries (was RFC: KHTML modular build)
On Monday 17 July 2006 20:09, Matt Broadstone wrote: Hi, I submitted a patch to kfm-devel to convert khtml to use libtool-esque convenience libraries yesterday, and wanted to move the discussion over here as it seems more appropriate. What is the reason for that? Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
On 7/19/06, Thiago Macieira [EMAIL PROTECTED] wrote: Matt Broadstone wrote: Well its not so much that I want a convenience lib, as I want a logical breakdown of the parts within a whole. For me it makes a lot more sense to build khtml in its pieces: dom, ecma, java, html etc. and then link them together in the whole. Furthermore, when I've been using my patch to build khtml, when I make simple changes inside ecma/debugger I no longer have to build the entirety of khtml. This may be a problem with cmake, as this should not necesarily be the case considering I haven't touched code that affects all of khtml, but that's what happens. If we can find a way around this, ie. change the CMakeLists.txt for khtml in such a way that simple changes in each module do not affect the entirety of khtml, then that's a decent solution. But for now, on my box, doing it this way (convenience, modular, whatever you want to call it :) ) works better for me, and I simply thought it might work better for others as well. I don't see how your solution can work. If you modify one file, you must compile it then link libkhtml. Isn't that what cmake is doing? How would introducing an intermediary step (create a .a) improve things? What I am referring to is that when I'm working on khtml (in this example) and make a change to say dom/, in my build dir I can cd to kdelibs/build/khtml/dom and build from that directory instead of the khtml directory and it will only rebuild the dom lib and then link things accordingly. Perhaps it should be the case when I make the change and build from khtml/, but it doesn't work that way - when I build from khtml in that example it rebuilds all of khtml. That's all I'm trying to get around... Matt Broadstone -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Am Mittwoch, 19. Juli 2006 17:06 schrieb Matt Broadstone: What I am referring to is that when I'm working on khtml (in this example) and make a change to say dom/, in my build dir I can cd to kdelibs/build/khtml/dom and build from that directory instead of the khtml directory and it will only rebuild the dom lib Under autotools, you'd have got a libdom.a convenience lib by that time. So no other files are recompiled than those this lib depends onto. So far so good. and then link things accordingly. And now it gets interesting. Did you use automake in this step formerly (i. e. make all in khtml/)? If yes, it'll do dependency checking and *will* recompile all affected files, will rebuild all changed convenience libs and only then will relink libkhtml.so. So unless you did fancy stuff the default way to build things did never ever relieve one from rebuilding necessary dependencies under autotools. Perhaps it should be the case when I make the change and build from khtml/, but it doesn't work that way - when I build from khtml in that example it rebuilds all of khtml. That's all I'm trying to get around... The general problem in khtml is that it's tightly coupled, i. e. nearly every header includes nearly every other header, transitively. So what may look like a total recompile could simply be a large set of files affected by transitive includes. OTOH, if cmake is really rebuilding *everything*, it looks like more a bug in the buildsystem. mfg Leo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
