Re: [SyncEvolution] Syncevolution build system conversion

On Fr, 2011-08-26 at 10:00 +0200, Krzesimir Nowak wrote: > My name is Krzesimir Nowak. I work for Openismus GmbH who asked me to > try to convert Syncevolution's build system to a (simpler) non-recursive > Automake build. I now have something that works, with no obvious > regressions. Thanks a lot. I look forward to trying out the speed-up with "make -j" on the nightly build server :-) > I've been working in a remote branch (I branched from Chris Kuehl's > dbus-server-reorganization because that already has some improvements > and it looks like it will get into master first). Indeed. I have been working on minimizing test failures in the night tests. I have almost reached the point where all tests pass (hello Thomas, please fix Memotoo :-) I'll branch a 1.2 maintenance/release branch now and start integrating all the pending patches, starting with Chris' work. > I think it would be wise to make further step-by-step improvements once > this first step is in master. For instance, see: > https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c... > diff --git a/AUTOTOOLS-TESTING b/AUTOTOOLS-TESTING > [...] > +Untested: > +- flags of configure script: > +  --enable-mlite > +  --enable-gui=all or --enable-gui=moblin > +  --enable-akonadi > +  --enable-kcalextended > +  --enable-qtcontacts (see TODO) > +  --enable-kwallet > +  --enable-buteo-tests > +  --enable-buteo > +  --enable-maemocal > +  ... probably more. Some of these are obsolete. I suggest that you don't worry too much about them. The relevant parts will (have to!) be part of the nightly builds. That reminds me... need to enable KDE there. > +Tested and failed: > +- make -j2 distcheck (see IMPROVEMENTS in AUTOTOOLS-TODO) Fixing that would be important. distcheck is run multiple times with different configurations when preparing a release, so running it in serial mode would become the main bottleneck.

> diff --git a/AUTOTOOLS-TODO b/AUTOTOOLS-TODO > [...] > +IMPROVEMENTS: > + > + > +- Add a check for qt-mobility for QtContacts backend. Not important. I wonder whether I should remove obsolete backends after 1.2. > +- Probably client test should be built only when unit tests or integration tests > +  are enabled. Yes. If I remember correctly, CPPUnit is only checked for when at least some tests are enabled, so there's no guarantee that client-test can be build if all of them are disabled.

> +- Look at the note at the bottom of configure.ac: > + > +  # Avoid hard-coding paths in backends. These names are chosen so > +  # that a backend can alternatively use its own top-level configure > +  # with PKG_CHECK_MODULES(SYNCEVOLUTION, "syncevolution") to set them. > +  # need absolute path, use pwd instead of relative $srcdir > +  SYNCEVOLUTION_CFLAGS=-I`cd $srcdir && pwd`/src > +  SYNCEVOLUTION_LIBS=`pwd`/src/syncevo/libsyncevolution.la > +  AC_SUBST(SYNCEVOLUTION_CFLAGS) > +  AC_SUBST(SYNCEVOLUTION_LIBS) > + > +  Backends does not have their own top-level configure scripts, so usage of > +  absolute path have to be checked. For now this is worked around > +  in generated backends.am. Also, for relative path not $(srcdir) should be used > +  but $(builddir). This comment applies to the out-of-tree ActiveSync backend: http://git.infradead.org/activesyncd.git/blob/HEAD:/syncevolution/Makefil... It sets SYNCEVOLUTION_CFLAGS/LIBS via PKG_CHECK_MODULES(SYNCEVOLUTION).

> +- Fix building when rst2html is not installed - build system tries to generate > +  README.html from README.rst during `make dist' even when distributing it was > +  disabled at configure stage. Build system somehow puts README.html into list > +  of distributed files even when condition is false. This is put in IMPROVEMENTS > +  because such behavior also exists in old build system. For some kind > +  of solution see: > +  http://stackoverflow.com/questions/7027606/autoconf-automake-conditionals-and-dist-rules > > +  Should README.html be distributed at all? See https://bugs.meego.com/show_bug.cgi?id=21331 The conclusion was that it should only be distributed if it can be build.

> +- Check why distcheck outputs: > +  ================== > +  All 0 tests passed > +  ================== > + > +  There should have been at least one test being run. The same behavior exists > +  in old build system. > + > + > +- Check why there are so many failed tests when running `make check' explicitly. > +  The same number of failures exists in old build system: > + > +  Run: 583   Failure total: 528   Failures: 206   Errors: 322 I don't use "make check", but it should pass nevertheless. client-test depends on too much setup work in the environment (working EDS, account configuration, ...) to be of much use. To avoid "make check" failures, running client-test probably should be limited to those tests which must pass in all environments. "client-test SyncEvolution" would be a good start, if --enable-unittests is used. Otherwise no stand-alone tests exist in client-test. > +QUESTIONS: > + > + > +- Should LINGUAS be generated or rather should it be put under git control? I would prefer to have it generated. It's another one of those pesky manual file lists. On the other hand, it is not changing much anymore. So put it under git control if that is easier. > +- More general: should LINGUAS, backends.am, all autotroll.am be generated at > +  build system generation time or rather should be static and under git control? > +  If they should be generated then for now some more am files also should > +  (specifically the ones working around `nobase_' deficiencies in nonrecursive > +  Automake - configs_xml.am, templates.am, profiles.am). I haven't looked at backends.am and autotroll.am yet, so I can't answer this at the moment.

> +NITPICKS: [...] > +- Check if /etc/sync and /lib/sync really have to be created, even if they are > +  going to be empty after install (this is probably some buteo stuff). Buteo is obsolete. Let's remove after merging all patches. > +- Change $(foo) to @foo@ for all variables substituted by configure script. This > +  might be useful when looking for actual value of variable appearing out of > +  nowhere in .am file. Can you give an example? In the old system, I found $(foo) more useful. When looking at the final Makefile, for example CXXFLAGS still has some structure: syncevolution_CXXFLAGS = $(SYNCEVOLUTION_CXXFLAGS) $(CORE_CXXFLAGS) $(KEYRING_CFLAGS) -I$(srcdir)/gdbus $(DBUS_CFLAGS) $(KDE_KWALLET_CFLAGS) If the Makefile.am had used @SYNCEVOLUTION_CXXFLAGS@ ... then I would just have one long list of parameters, without any hint where each one came from.

> +- Should stamp files be marked as intermediate or rather as secondary files? No idea.

-- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.