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...
+ 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.