Still not present in 0.7

Due to the long list of bugs for the MITK 0.8 release, there has been introduced a new intermediate release 0.7.3. All bugs from 0.8 have been moved to target milestone 0.7.3. If you do not manage to get your bugs fixed till 0.7.3, please set the target milestone for these bugs to 0.8.

This is definetly something for a "big" release. Maybe first tests can/should be made before.

See comment #3. First tests should be done earlier of course.

Probably also related to install package creation with CPack -> cc'in Matthias

rev 16239: include functionality libs in linux installation
rev 16240: separated win32 specific stuff more specific for linux installation

todo:

poco install prefix
poco includes nicht installieren
start skripte als vorstufe fuer ld_config

Bug has been chosen to get fixed in the MITK 1.0 release, Feb. 2010.

Sascha once sent me this patch in an email. It's supposed to facilitate the creation of an install target for linux systems.

However I did not test it. I simply attach it here to prevent it from being lost.

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

MITK-1-0 keyword is obsolete, use target milestones in the future.

Added an early requirements wiki page (internal only)

http://mitk.org/wiki/internal/T16SdkInstall

Looks good to me. I'm not sure about using FIND_PACKAGE everywhere, sounds a bit scary to me. Currently the module system does a full dependency check and makes sure every cmake file is only included once. I don't know how FIND_PACKAGE behaves.

I would like to define a few use cases / goals / reference workflows as well: what can the user/developer achieve with the new system

1. a) A privileged user builds MITK on Linux and makes install to e.g. /opt/mitk b) Users use this read-only installation, can create own Modules/Bundles etc.

1. Linux package building, separate packages for common libraries, headers and applications

1. Components:
   
   a) users can download a full installer and select the bundles they want to have in the installed application. Module dependencies are determined automatically
   
   b) developers can create installations with only a subset of modules c) package maintainers can create separate packages for subsystems like IGT, Diffusion etc.

Maybe we can also create a proper solution for T5524 as well.

Could you support cmake -DLIB_SUFFIX=64 ...? I know it seems a bit klugey, but this is the established convention in the CMake community for dealing with systems like my 64-bit box (a RHEL6 derivative) where libraries installed to /usr/lib64. Thanks!