[maemo-developers] hildon dependency on modified gtk+ (was: sbox2 & maemo)
From: Loïc Minier lool at dooz.orgDate: Fri Jul 27 15:41:07 EEST 2007
- Previous message: hildon dependency on modified gtk+ (was: sbox2 & maemo)
- Next message: hildon dependency on modified gtk+ (was: sbox2 & maemo)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Jul 26, 2007, Xan wrote:
> The issue here is: the pc file for hildon-1 hardcodes MAEMO_CHANGES to
> 1, so anything you build on top of it will get that define. This wan
> fine by the time we did it ("if you use hildon you surely want all the
> stuff and certainly you are using our gtk version"), but now that we
> aim to be an upstream project it is no longer acceptable. At the very
> least we should add the MAEMO_CHANGES to the pc file only if hildon-1
> is compiled against our gtk. More rational configuration management is
> badly needed here.
I agree this is a problem, but to my understanding some components
still require the filechooser Gtk patch, and then need MAEMO_CHANGES to
build; so this flag is going to be required as long as the filechooser
is mandatory.
What's the way forward? Some options I imagine:
1) split MAEMO_CHANGES in more conditional in modules:
- HAS_GTK_FILECHOOSER_API
- HAS_GDK_CLOSEALL_API
- etc.
=> lots of work, but most modular / flexible / powerful
2) make all apps build without the filechooser specific bits
=> some work, don't know if that's possible to implement at all, dead
end when one tries to use any of the MAEMO_CHANGES
3) only split HAS_GTK_FILECHOOSER_API as a separate conditional, but
use MAEMO_CHANGES for all the other changes
=> would work short term :)
What's the contract of the modules so far?
--
Loïc Minier
- Previous message: hildon dependency on modified gtk+ (was: sbox2 & maemo)
- Next message: hildon dependency on modified gtk+ (was: sbox2 & maemo)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
