[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: koffice dependency for kdeedu
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2008-06-04 12:41:51
Message-ID: 200806041441.51280.cberger () cberger ! net
[Download RAW message or body]

Hello,

On Tuesday 03 June 2008, Thomas Zander wrote:
> The solution I suggested earlier for this issue was to make the
> marble-flake plugin use the svn-extern to link to the flake libs as long as
> they are not yet released.
>
> I think this still is the best solution to avoid a lot of problems for all
> parties and long long recompiles for Simon. (depending on 2 modules that
> change can't be easy).
svn:external doesn't make the flake library or marble changing less.

> Maybe with the new data point that Annma brought up (unwanted module
> dependency) we should re-evaluate this option?

"My" solution doesn't prevent anyone who want to use "svn:external" to use it. 
But the solution of also compiling the flake library with the "svn:external" 
sounds extremely problematic. The application that use the flake and the 
flake plugins need to use the same library object, or an API/ABI compatible 
one, so there would still be the need to update kdeedu for each release of 
KOffice.

And anyway, someone willing to use the marble shape, would have to have 
koffice... So with the "svn:external" solution (including library), you have 
to build the flake library twice. Unless you use "svn:external" only to get 
the headers, in which case the dependency problem is not solved, since you 
would still need to have KOffice libraries for linking... and using your 
shape...

Hence the only logical place to have code, that depends on two 
libraries/applications which can't have dependency on each other, is to have 
it outside both library/applications. Wether headers are easilly accessible 
or not.

Honestly, hijacking a thread to reopen subject where a decision has allready 
be taken with the agreement of most of the team, and which problem is not 
even related, is really not the best solution to make progress on both 
issues.

-- 
Cyrille Berger
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]