Monday 17 July 2006 00:14, Matt Broadstone wrote:
Attached is a patch to make khtml build in pieces. It breaks all the
subdirs (but for ecma right now) into static libs and then uses those
to build khtml. I wanted to ask you all whether you thought this was a
good idea I mainly did it because I was sick of rebuilding all of
khtml every time I made a small change in my soc project under
ecma/debugger, but I have talked to people who think the A) longer
link times B) reverting to autotools-like behavior here, are unwanted
sideeffects of this change. Anyway, let me know what you all think.

Convenience libs are not really supported by cmake, the conversion from the
libtool convenience libs to compile-all-in-one was done by purpose.
If you find a way to make this work portable with cmake on all supported
platforms I'd be very happy.
As it is now, changing this to static libs may break things on some platforms.
I strongly recommend not to change it to static libs except you know very
well what you are doing.
#

Bye
Alex

7/17/06, Alexander Neundorf <neundorf (AT) kde (DOT) orgwrote:
Monday 17 July 2006 00:14, Matt Broadstone wrote:
Attached is a patch to make khtml build in pieces. It breaks all the
subdirs (but for ecma right now) into static libs and then uses those
to build khtml. I wanted to ask you all whether you thought this was a
good idea I mainly did it because I was sick of rebuilding all of
khtml every time I made a small change in my soc project under
ecma/debugger, but I have talked to people who think the A) longer
link times B) reverting to autotools-like behavior here, are unwanted
sideeffects of this change. Anyway, let me know what you all think.

Convenience libs are not really supported by cmake, the conversion from the
libtool convenience libs to compile-all-in-one was done by purpose.
If you find a way to make this work portable with cmake on all supported
platforms I'd be very happy.
As it is now, changing this to static libs may break things on some platforms.
I strongly recommend not to change it to static libs except you know very
well what you are doing.
#

Well I'm assuming by other platform you mean win32? Could you possibly
test on win32? I don't have a box running it to test the build on. I
mean if the only reason that this is going to be rejected is that it
"might not work on the windows build" then it seems we might better
spend our time trying to figure out how to make it work on windows?

Matt

Bye
Alex

Monday 17 July 2006 18:14, you wrote:
7/17/06, Alexander Neundorf <neundorf (AT) kde (DOT) orgwrote:
Monday 17 July 2006 00:14, Matt Broadstone wrote:
Attached is a patch to make khtml build in pieces. It breaks all the
subdirs (but for ecma right now) into static libs and then uses those
to build khtml. I wanted to ask you all whether you thought this was a
good idea I mainly did it because I was sick of rebuilding all of
khtml every time I made a small change in my soc project under
ecma/debugger, but I have talked to people who think the A) longer
link times B) reverting to autotools-like behavior here, are unwanted
sideeffects of this change. Anyway, let me know what you all think.

Convenience libs are not really supported by cmake, the conversion from
the libtool convenience libs to compile-all-in-one was done by purpose.
If you find a way to make this work portable with cmake on all supported
platforms I'd be very happy.
As it is now, changing this to static libs may break things on some
platforms. I strongly recommend not to change it to static libs except
you know very well what you are doing.
#
>libraries.3F
>
Well I'm assuming by other platform you mean win32?

Linux, *BSD, S X, Solaris, Win with MSVC, Win with mingw.
I also have "only" a Linux box and from time to time a FreeBSD box available.
From several discussions I can remember that there are several issues with
this.
Here are some links:

Could you possibly
test on win32? I don't have a box running it to test the build on. I
mean if the only reason that this is going to be rejected is that it
"might not work on the windows build" then it seems we might better
spend our time trying to figure out how to make it work on windows?

So if you can find a way t do this reliably and in a portable way, I'm all for
it. But kde-core-devel (AT) kde (DOT) org, kde-buildsystem (AT) kde (DOT) org and cmake (AT) cmake (DOT) org
are better lists to discuss this.

If so much is recompiled because you changed something in ecma/debugger/, then
there *is* probably a dependency why it really should be recompiled.
Maybe you can figure it out what it is ?

Bye
Alex

Monday 17 July 2006 10:44, Allan Sandfeld Jensen wrote:
Monday 17 July 2006 00:14, Matt Broadstone wrote:
Attached is a patch to make khtml build in pieces. It breaks all the
subdirs (but for ecma right now) into static libs and then uses those
to build khtml. I wanted to ask you all whether you thought this was a
good idea I mainly did it because I was sick of rebuilding all of
khtml every time I made a small change in my soc project under
ecma/debugger, but I have talked to people who think the A) longer
link times B) reverting to autotools-like behavior here, are unwanted
sideeffects of this change. Anyway, let me know what you all think.

I think it's excellent. Probably will help the cmake-times as well.

I don't understand how it can possibly help. Rebuilding a .a is not enough,
one needs to relink the .so that uses it anyway. So in all cases one needs
to go up to the khtml level and type make there, and it has to relink libkhtml.so,
just like it would have to do if using .o files instead of .a - so what do we gain?

Thursday 20 July 2006 20:15, Allan Sandfeld Jensen wrote:
Thursday 20 July 2006 11:17, David Faure wrote:
Monday 17 July 2006 10:44, Allan Sandfeld Jensen wrote:
Monday 17 July 2006 00:14, Matt Broadstone wrote:
Attached is a patch to make khtml build in pieces. It breaks all the
subdirs (but for ecma right now) into static libs and then uses those
to build khtml. I wanted to ask you all whether you thought this was
a good idea I mainly did it because I was sick of rebuilding all of
khtml every time I made a small change in my soc project under
ecma/debugger, but I have talked to people who think the A) longer
link times B) reverting to autotools-like behavior here, are unwanted
sideeffects of this change. Anyway, let me know what you all think.

I think it's excellent. Probably will help the cmake-times as well.

I don't understand how it can possibly help. Rebuilding a .a is not
enough, one needs to relink the .so that uses it anyway. So in all cases
one needs to go up to the khtml level and type make there, and it has to
relink libkhtml.so, just like it would have to do if using .o files
instead of .a - so what do we gain?

From seeing cmake try to analyze unity, I assume it is using quadratic
time.

Also all the time it uses to analyze could be paralyzed by compiling
another module.

With the soon-to-be-released cmake 2.4.3 you will be able to do "make
html/fast" which will skip this step.
(or current cmake 2.4 branch, not HEAD)

Bye
Alex