tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [RFC] KDE without arts

Dieter Baron wrote:
> In article <> Hasso wrote:
> : * It makes sense to introduce arts option for x11/kdelibs3 only and
> : let other packages to depend on this option.
>   This is not how we handed similar situations previously.  I'm not
> opposed to it per se, we should just keep in mind that we are in new
> territory here.  Thus, two things to consider:
> - Once we are able to build binary packages for multiple option sets,
>   we will also want to build variants with and without arts for these
>   depending packages.

Yeah, but ...

> - Does it make sense to disable arts support selectively in only some
>   kde packages?  If so, they would need an option of their own.

If kdelibs is compiled without arts support, you just can't build kdebase 
or kdemultimedia without --without-arts configure switch. AFAICS all KDE 
programs having arts support want to link against libartskde (which is 
part of kdelibs) in this case.

> :   The problem is that although
> :   most of packages don't really care about arts at all, all packages
> : using autoconf from KDE base (yes, even kde3-i18n-*) must be
> : configured with --without-arts if you don't have arts. Any ideas how
> : to handle it better? I don't like the idea of patching every
> : kde3-i18n-* package with
> :
> :   .include "../../x11/kdelibs3/"
> :   BUILD_DEFS+=          PKG_BUILD_OPTIONS.kdelibs
> :
> :   .if empty(PKG_BUILD_OPTIONS.kdelibs:Marts)
> :     CONFIGURE_ARGS+=    --without-arts
> :   .endif
>   Does it do any harm to always use --without-arts for those package
> we know don't care about arts?

Yeah, that's a idea of course.

>   For the rest, we can encapsulate this in some mk fragment in kdelibs
> that is included in the depending packages.

I think that I'll investigate at first and identify packages which have 
some relationship with arts at all.


Hasso Tepper

Home | Main Index | Thread Index | Old Index