patch: c/cxxflags for static libraries
Thiago Macieira
thiago at kde.org
Wed Jul 19 08:32:50 CEST 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060719/2060e12c/attachment.pgp
More information about the Kde-buildsystem
mailing list