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

List:       kde-devel
Subject:    Re: Recommended application-development styles
From:       Michael Jansen <info () michael-jansen ! biz>
Date:       2011-04-10 13:51:59
Message-ID: 37217089.7nLh8ACn7d () gambit ! local ! michael-jansen ! biz
[Download RAW message or body]

On Sunday 10 April 2011 14:58:25 Ian Wadham wrote:
> What are the currently recommended application-development styles
> for KDE 4?  When KDE 4 started there were several alternatives:-
> 
>  1. Bleeding edge.  Use the very latest KDE 4 as your desktop and
>      keep it up to date, monthly maybe(?).
> 
>  2. Separate user A.  As for 1 (bleeding edge), but keep the desktop
>     and all development work under a separate user ID.
> 
>  3. Separate user B.  Use a KDE desktop from a standard distro and
>      installed by that distro.  Have a separate user ID for development,
>      but use scripts and .bashrc (e.g. the cs/cb suite) to set up
> environment variables (QTDIR, KDEDIR) when you want to compile, build or
> test.
> 
>  4. No separate user.  As for 3 (separate user B), but just keep development
> work in a separate disk area and use scripts, etc., when you want to
> compile, build or test.

If your hardware is up to the task there is option 5 which i suspect is the 
safest you will find. It is a variant of 1 and what aseigo said,

Have one installation with minimal distro packages. Remove all distro packages 
of stuff you plan to build from sources completely. Not only the devel 
packages but the binary ones too.

- Remove all kde packages completely.
- Remove all kdesupport packages completely (phonon, soprano ...)
- Do you need to compile qt from sources. The remove all qt and dependent 
packages too.

Rebuild everything from scratch. My script build-tool (http://michael-
jansen.biz/build-tool) is designed for this use case. It even supports the 
setting up a session for your self compiled stuff.

Have another installation with a standard distro kde desktop.

Put one of those two into a virtual machine. If you decide to put your distro 
install into a virtual machine use VirtualBox for it because it is (imho) the 
easiest to use.

If you put your development installation into the vm use kvm because from all 
i have heard it has the least performance impact on linux (saying goes only 4% 
for a complete kernel compile - test done by the kernel devs themselve).

Which one you put into the vm is your decision to make. I run kde bleeding 
edge for some years now and had to start my distro kde vm only twice because i 
couldn't use okular to print some pdf's (my fault ... not okulars). But i 
don't have that hard demands on my linux installation.

The vm approach with kvm has the charm that you can do snapshots (before you 
do a bigger update so you can go back if it borks your system) and copying 
/branching (for example at the time the maintenance branch is created to be 
able to switch to it fast). Needs some practicing and learning what the vm 
software supports. 

Mike
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]