[Kde-pim] Make KDE PIM 4 installable in parallel to KDE PIM 3

[Jason 'vanRijn' Kasper]

On 10/21/07, Allen Winter <winter at kde.org> wrote:

> If there are KDEPIM4 apps that are cause data loss or *really suck*
> then we I think we simply shouldn't build them in the toplevel
> CMakeLists.txt.
>
> Which reminds me of an idea I had...  we could have stuff like this in
> our top-level CMakeLists.txt files to exclude apps that aren't "
> KDE4.0-ready"
>
> if (NOT ${KDE_ENABLE_FINAL})
> add_subdirectory(appfoo)
> endif(NOT ${KDE_ENABLE_FINAL})
>
> then appfoo won't be built if the distro packagesuse 'cmake
> -DKDE_ENABLE_FINAL'.
>

I didn't see a firm resolution on this particular idea, but I think it (or
something very much like it) might have merit to my current situation.  In
particular, kpilot is suffering from a severe lack of attention right now,
despite my best intentions.  With Adriaan in denial (=;P), Bertjan back in
school, and me 2 weeks into a brand new job (woohoo) on the other side of
the continent with lots of time-consuming Real Life (TM) pending, I need to
figure out what to do with kpilot for 4.0 release.

Specifically, there are some conduits that I don't want to take out of the
normal compile/build process (otherwise they'll get even more broken as
changes are made in pim and elsewhere that won't get reflected in kpilot's
conduits), but I wouldn't want them to be included in an official release
due to possible data issues.

One option that would be trivial to implement would be to put early return
code into these conduits so that they put "sorry, this conduit isn't fully
functional yet" into the user's Palm sync log and don't risk damage to any
data.  My issue with this approach, though, is that the user is mislead to
think that the conduit is functional in the setup/configuration screen and
won't know that his/her data wasn't synced correctly unless they happen to
look in their sync log.

So, I was thinking that Allen's idea might be an option for me to disable
some of these not-yet-ready-for-prime-time conduits in a production build.
And, as I stated in an earlier thread, I don't want to disable kpilot
entirely from a release build because it does bring forward some
functionality from kde3 as well as provide some really cool new requested
functionality.

I'd very much appreciate any thoughts/comments/suggestions about this.

TIA!!  =:)


-- 
-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
-[ KDE PIM Developer         //  http://www.kde.org  ]-
-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/