[Telepathy] One big repository

[Olli Salli]

On Fri, Dec 2, 2011 at 1:01 AM, Alvaro Soliverez
<alvaro.soliverez at collabora.co.uk> 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
> telepathy at lists.freedesktop.org
> 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