On Fri, Dec 2, 2011 at 1:01 AM, Alvaro Soliverez <[email protected]> wrote: > On Thursday 01 December 2011 22:57:35 Xavier Claessens wrote: >> I would make a global ./configure && make. but with a --disable-foo for >> each submodules. I'm not sure GNOME people will like being forced to >> have qt-dev to build telepathy >> >> The question is would KDE people be shoked if tp-qt drops cmake in favor >> of autotools? > > How about the individual configure options? Each project has different ones.
Frankly, I don't see why we should make our lifes unnecessarily difficult by trying to have a configure script/makefile to rule them all (not to mention tp-qt4 doesn't even have ./configure because it's cmake and the paradigm is different!). The current situation is this: * you have to separately check out each module * they can't share the spec and codegen toolchain etc * and configure (or set cmake variables) and compile them separately * and maybe install them, or take care to pass correct prefixes / pkgconfig search paths to find uninstalled versions * AND take care of the dependencies yourself In the merged repo: * you check out all at once * the CAN share the spec and all which I think is the most important benefit * maybe still configure and compile them separately - it's not significantly harder to do that than to pass numerous --with-crap --without-thing --not-that-please-im-a-g-freak feature selection options to a master configure * but they can "know" where to look first for deps, so you don't have to specify dep paths manually * still take care of the deps yourself? exactly as hard as currently The main benefit of the global driver to me is being able to check that stuff builds and that stuff passes their unit tests after spec changes. The configure phase of individual components plays no role there - we just need a small top level script which runs make check in all submodules and assumes they're configured, to be used when you're making major spec changes rather than just e.g. fixing bugs or adjusting higher level API impl on some single component, which will still be much more common than the first task. > > And I think KDE people would be really shocked to be taken back in time, to > autotools. Yes. Not an option. The build system has really got a whole lot easier to maintain and also a lot faster thanks to ditching autotools. Also some people view the native windows support as a very big incentive to stay cmake (and go there in the first place, or else not adopt the library in their use at all). > > How about a global script where you can select the modules you want, and in > time, the script calls each individual build system? You just have to build a > global script, and you leverage existing build infrastructure. > > Regards, > Hei Ku > _______________________________________________ > telepathy mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/telepathy Maybe a sensible middle ground, but I don't really see the utility except for the "make check" aspect. Would save typing and thinking that gabble needs tp-glib? So what? There is shell history and if you're developing, you're not a complete idiot anyway. -- Br, Olli Salli _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
