debugging support - multidimensional package selection - excursion

[Marc Weber]

If we want to add debugging support consider a packagetree like this:

a - b ( depends on b and c, c on d and e)
|
+ - c - d
    |
    + - e
 

its obvious if I want to have a profiling lib a I need b..e compiled
with -prof, too

But if I want to build it with debugging messages what about b,c,d,e 
They might have been compiled with debugging support but don't have to.

Consider the scenario a,c,d beeing compiled as debugging, but I'm also
working on another project which doesn't need c as debugging.

This would mean I need two versions of c (with debugging enabled and
disabled) -> naming conflict..

This could be solved by introducing aliases.

eg 

./cabal-install d as d-debug --enable-debug
./cabal-install c as c-debug --enable-debug --with d-debug as d
./cabal-install a  --with c-debug as c

and I would be done

This way you can even install different developement versions of your
libraries .. (sure testing should be done with HUnit or qpuickcheck not
with final applications ..)

Of course this is only useful for testing not for distribution ...

I don't think this would make things much more complicated but would
make the system much more flexible ..


Wait.. This would mean:
you have a package id and you have flags to select the right version
	a flag is a) version
	          b) configure options such as profile, debug, use lib a
		  instead of b, ...

But this would mean when deciding which libraries to install by default:
instance Default Stability  -- stable wins
instance Default Version  -- greater wins
instance Default Debug -- no debug wins
instance Default Profiling -- no profiling wins
if not specified else.

This leads me to the question: Is it enough to identify a package by
(name/id) and version?

I think a more dimensional way would be useful

Thus adding another dimension (os / 
instance Default Cross-Compilation-Target -- defaults to no cross-compilation
an easy extension..

And this would make it easy to manage libs for your os, that of your
neighbour, your microcontroller, ....

Of course ghc-pkg list will no longer show
Lib (version=2.0, debug=on, profiling=on, target-architecture=x64)
rather than
Lib-2.0

Some of those flags would be backtracking (architecture, profiling)
others not (debug = on)

Fortunately you don't have the design of ghc to test this as you can use
aliases ..

Any comments? Is this all nonsense ?

Marc