[kde-edu]: Kig dependancies ?

[Maurizio Paolini]

> From: Dominique Devriese <dominique.devriese at student.kuleuven.ac.be>
>
> I've been working a bit on python scripting for Kig.  This has turned
> out to not be too hard, especially because I'm using the fantastic
> Boost.Python library [1].  I'm making good progress, the code
> basically works, but I haven't started working on the user interface
> of the feature.

Good work!

> However, I have some questions about whether it would be a good idea
> to make Kig depend on python and Boost.python.
> Basically, I see two options:
>
> 1 make kig depend on the libs, and make it not compile at all without
>   python installed, which obviously has the disadvantage that users
>   will need two libraries installed in order to be able to use Kig.. 
> 2 make the kig build disable the scripting features if the user
>   requests to not use the libraries.  However, this has the
>   disadvantage that it creates compatibility problems between the
>   program with scripting, and the program without ( User A has
>   scripting, creates a file with a scripted object, and sends it to
>   User B who doesn't have scripting, and obviously can't open the
>   file.. ).  Kig would have to tell User B that he needs kig with
>   scripting in order to use the file..

I guess that you should base such choices upon the most probable scenario
in the next future.  When kde3.2 is out it will include kig in it, which
means that all major distributions will build packages with kig precompiled.
In such scenario the compile options (if any) are decided by the packager
and not the user, which means in the end that the majority of kig executables
around would be basically all compiled with the same options.  In this
sense I guess it would not be a real disadvantage to make it possible to
disable scripting while "making" kig; anyone doing it would be motivated
to do so and aware of the consequences.
On the other end if a packager compiles with scripting support, then the
resulting package would depend on python (not a big problem) and "boost"
(which *can* be a problem) e.g. I can find the rpm package of boost in
the "RawHide" of RedHat, which means that presumably it will be included in
a future redhat release, but is not yet included in the present release.

If we had a "crystal sphere" we could know if there will be other software
depending on "boost", in which case the dependency would not be a real
problem... but we actually don't know :-(

Option 2 would leave the choice to the packager, who perhaps is in a better
position to make a decision.

Cheers,

maurizio