2011/8/26 Patrick Ohly <[email protected]>: > 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-cleanup/blobs/autotools-cleanup/AUTOTOOLS-TODO > > >> 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. >
Yes, I'm looking at it right now. >> 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. 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: > http://git.infradead.org/activesyncd.git/blob/HEAD:/syncevolution/Makefile.am > > 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: >> + >> 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. > 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' >> 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. > 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 generated too. 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 (gen-autotroll.pl). >> +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. > 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 secondary files? > > No idea. > 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. > > > _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
