KDE/kdevelop [POSSIBLY UNSAFE]

[Andreas Pakulat]

On 25.04.07 23:33:14, David Nolden wrote:
> On Wednesday 25 April 2007 23:13:44 Andreas Pakulat wrote:
> > On 25.04.07 18:48:16, Andreas Pakulat wrote:
> > > On 23.04.07 17:49:39, David Nolden wrote:
> > > > boost-serialization -- is used for the whole messaging system, is far
> > > > superior to qt's serialization-stuff, so it cannot be replaced. The
> > > > only problem, that still has to be worked on, is that it creates very
> > > > big executables when compiled in debug-mode.
> > >
> > > Wow, 15 Meg is really big (that is libnetwork as static lib).
> >
> > Well, as one can see from the commits I turned the whole plugin to
> > release mode. Now it links within seconds, before it would take >30
> > minutes, even if the 3 libs are built in release mode.
> >
> > This way there's no chance of debugging the teamwork plugin, so I'd like
> > to know how long it takes for others to link after removing the SET
> > calls in the CMakeLists.txt and using BUILD_TYPE=debugfull.
> >
> > Andreas
> 
> For me the linking usually takes about one minute I think, 30 minutes sounds 
> really extreme.

Well, the second try with release-build network and dynamictext libs was
maybe just 20 minutes of linking, then I killed it. I'm on a Centrino
1.4 GHz here, but I do have 1 Gig of ram. Also I installed the
boost*-dev packages so maybe the boost libs are larger too.

> Btw. I'm doing a big cleanup of the network-library right 
> now(it takes some time), which also includes making a lot of 
> template-functions simple member-functions, which makes it a little less 
> flexible, but maybe it will help about the linking-time and executable-size 
> problem.

Ok, thanks. Hope you don't get too many conflicts with the last changes
I checked in wrt include "network/foobar.h".

Also I found out what the problem is with having the commoncpp includes.
The reason is simply that the cmake macro for finding the include dir
was wrong, not sure how exactly but after using c++/network.h as the
header to find and a PATH_SUFFIX option using the commoncpp include is
no problem anymore.

Also on non-win32 it uses pkgconfig to find out about the library dir
and the include dir.

I'm committing these changes now.
BTW: I tried to make network a shared lib, but for that you need to add
export macro's to all classes that are used outside of the lib (i.e.
public API). I tried to do that but I still had undefined references
when linking the basicserver executable, the first one for the static
globalMessageTypeSets function. Not sure what was going on there.

Andreas

-- 
You are not dead yet.  But watch for further reports.