2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
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
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:
> diff --git a/AUTOTOOLS-TESTING b/AUTOTOOLS-TESTING
> +- 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
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.
Yes, I'm looking at it right now.
> diff --git a/AUTOTOOLS-TODO b/AUTOTOOLS-TODO
> +- 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.
I have temporarily changed it that check for cppunit-config is always performed.
> +- 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:
It sets SYNCEVOLUTION_CFLAGS/LIBS via PKG_CHECK_MODULES(SYNCEVOLUTION).
Ok. Also, ActiveSync backend will need to be adapted to non-recursive
automake too if this patch is going to be pushed.
> +- 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:
> + Should README.html be distributed at all?
The conclusion was that it should only be distributed if it can be build.
Automake have some strange behavior I haven't yet fully understood
when it comes to selecting files for distribution. Looks like Automake
does not care about conditions when it composes a list of files to
distribute. So we can conditionally build it, but file is
conditionally (or not) assigned to some dist_ variable then it is
going to be distributed.
> +- 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'
> + 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.
> +- 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.
My personal opinions on this:
LINGUAS - may stay being autogenerated, maybe it would be good idea to
add LINGUAS.README stating that adding <lang>.po file is enough,
because LINGUAS is generated at build time.
backends.am - contains list of *Register.cpp files, list of backends
directories and includes to .am files, so this one could stay
autotroll.am - It contains some rules for generating source files by
moc. I have mixed feelings about it. Probably should be included by a
toplevel Makefile.am even when we don't need the rules in it. That
would remove some complexity of build system and one script
> +- 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
This was written mostly because I sometimes had problems finding
origin of a variable. Probably just making all AC_SUBSTed variables
uppercase and the rest lowercase just would do.
> +- Should stamp files be marked as intermediate or rather as
Oh, that was rather a note to self.
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.