[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [RFC] KDE without arts
Dieter Baron wrote:
> In article <200811141456.33343.hasso%estpak.ee@localhost> 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/buildlink3.mk"
> : 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.
Main Index |
Thread Index |