[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 ]