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 _______________________________________________ maemo-developers mailing list [email protected] https://lists.maemo.org/mailman/listinfo/maemo-developers
