8 a.m.
Hi.
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.
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).
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
but I have also attached it as one patch, which might be easier to
review.
This should be simpler and more robust (for instance, against weird
linker problems), with less duplication, and it allows faster builds via
make -j.
It also removes the pre/post configure system and the *-gen.am system
which can be unfamiliar to regular users of autotools.
Patrick's minimum requirement was to still have the version number
autogenerated from the git version, and I have managed to keep that.
Patrick also preferred not having to list all the templates and config
files, but I have only partly achieved that.
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...
Regards,
Krzesimir
9:20 a.m.
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.
11:22 a.m.
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
> 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.
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/Makefil...
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.
11:53 a.m.
On Fr, 2011-08-26 at 13:22 +0200, Krzesimir Nowak wrote:
2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> On Fr, 2011-08-26 at 10:00 +0200, Krzesimir Nowak wrote:
>> +- 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).
Ok. Also, ActiveSync backend will need to be adapted to non-recursive
automake too if this patch is going to be pushed.
I'll merge it into the "master" branch directly after merging Chris'
work. Then we can fix its rules as part of switching to the new build
system.
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.
The rationale must be that "make dist" is intended to produce the same
result, always, no matter what the environment or configure options are.
Just guessing, though.
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.
Sounds good.
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).
I wouldn't mind including these rules in all cases.
--
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.
2:33 p.m.
2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
On Fr, 2011-08-26 at 13:22 +0200, Krzesimir Nowak wrote:
> 2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> > On Fr, 2011-08-26 at 10:00 +0200, Krzesimir Nowak wrote:
> >> +- 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).
>
> Ok. Also, ActiveSync backend will need to be adapted to non-recursive
> automake too if this patch is going to be pushed.
I'll merge it into the "master" branch directly after merging Chris'
work. Then we can fix its rules as part of switching to the new build
system.
> 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.
The rationale must be that "make dist" is intended to produce the same
result, always, no matter what the environment or configure options are.
Just guessing, though.
This sounds sensible. Going this path I'd say that there are two solutions:
1. Distribute README.html - that would need README.html to be always
generated and that in fact - a syncevo's dependency on rst2html, that
is - configure would end with an error if there is no rst2html.
2. Don't distribute README.html - then it would be generated if
rst2html existed on system.
Above solutions clearly contradict your conclusion about README.html
being distributed if it can be build.
> 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.
Sounds good.
> 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).
I wouldn't mind including these rules in all cases.
Done.
--
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.
2:42 p.m.
On Mo, 2011-08-29 at 16:33 +0200, Krzesimir Nowak wrote:
2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> The rationale must be that "make dist" is intended to produce the same
> result, always, no matter what the environment or configure options are.
> Just guessing, though.
>
This sounds sensible. Going this path I'd say that there are two solutions:
1. Distribute README.html - that would need README.html to be always
generated and that in fact - a syncevo's dependency on rst2html, that
is - configure would end with an error if there is no rst2html.
2. Don't distribute README.html - then it would be generated if
rst2html existed on system.
Above solutions clearly contradict your conclusion about README.html
being distributed if it can be build.
"intention" instead of "conclusion" is a better word here ;-)
The goal was to have the file around when using source .tar.gz from
syncevolution.org, because those are built in an environment where we
ensure that rst2html is around.
Let's go for option 2. README.packagers must be extended with a hint to
packagers that they now (SyncEvolution >= 1.3) should make rst2html a
build requirement.
--
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.
1:05 p.m.
2011/8/29 Patrick Ohly <patrick.ohly(a)intel.com>:
On Mo, 2011-08-29 at 16:33 +0200, Krzesimir Nowak wrote:
> 2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> > The rationale must be that "make dist" is intended to produce the
same
> > result, always, no matter what the environment or configure options are.
> > Just guessing, though.
> >
>
> This sounds sensible. Going this path I'd say that there are two solutions:
> 1. Distribute README.html - that would need README.html to be always
> generated and that in fact - a syncevo's dependency on rst2html, that
> is - configure would end with an error if there is no rst2html.
> 2. Don't distribute README.html - then it would be generated if
> rst2html existed on system.
>
> Above solutions clearly contradict your conclusion about README.html
> being distributed if it can be build.
"intention" instead of "conclusion" is a better word here ;-)
The goal was to have the file around when using source .tar.gz from
syncevolution.org, because those are built in an environment where we
ensure that rst2html is around.
Let's go for option 2. README.packagers must be extended with a hint to
packagers that they now (SyncEvolution >= 1.3) should make rst2html a
build requirement.
Done.
I also added a warnings system like described in [1]. It may be useful.
Again, I'm attaching a complete patch made against
dbus-server-reorganization branch.
[1] http://www.murrayc.com/blog/permalink/2011/01/18/avoiding-use-of-deprecat...
--
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.
9:37 a.m.
On Di, 2011-08-30 at 15:05 +0200, Krzesimir Nowak wrote:
I also added a warnings system like described in [1]. It may be
useful.
[1] http://www.murrayc.com/blog/permalink/2011/01/18/avoiding-use-of-deprecat...
Yes, sounds useful. In the nightly testing I add "-Werror -Wall" to the
CXXFLAGS/CFLAGS on the command line, but this --enable-warnings=fatal is
nicer.
Ah, minor caveat: libsynthesis doesn't support it yet. So at the moment,
the explicit flags are still needed when compiling both at the same
time.
Again, I'm attaching a complete patch made against
dbus-server-reorganization branch.
I've fast-forwarded "master" to your autotools-cleanup-2 branch this
morning and started testing it, after fixing the ActiveSync backend and
runtests.py (invoked make in the wrong directories/with wrong targets).
Works fine so far.
In the meantime you also made a similar change for ActiveSync. I think
I'll stay with my version because a) it doesn't add the
--export-dynamic, which no longer seems to be necessary (if it ever was)
and b) it doesn't include an unrelated change to addressbook.am.
But you are right about SYNCEVO_WFLAGS and wrapping AS_HELP_STRING(),
will fix that.
--
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.
9:52 a.m.
2011/8/31 Patrick Ohly <patrick.ohly(a)intel.com>:
On Di, 2011-08-30 at 15:05 +0200, Krzesimir Nowak wrote:
> I also added a warnings system like described in [1]. It may be useful.
> [1] http://www.murrayc.com/blog/permalink/2011/01/18/avoiding-use-of-deprecat...
Yes, sounds useful. In the nightly testing I add "-Werror -Wall" to the
CXXFLAGS/CFLAGS on the command line, but this --enable-warnings=fatal is
nicer.
Ah, minor caveat: libsynthesis doesn't support it yet. So at the moment,
the explicit flags are still needed when compiling both at the same
time.
> Again, I'm attaching a complete patch made against
> dbus-server-reorganization branch.
I've fast-forwarded "master" to your autotools-cleanup-2 branch this
morning and started testing it, after fixing the ActiveSync backend and
runtests.py (invoked make in the wrong directories/with wrong targets).
Works fine so far.
In the meantime you also made a similar change for ActiveSync. I think
I'll stay with my version because a) it doesn't add the
--export-dynamic, which no longer seems to be necessary (if it ever was)
and b) it doesn't include an unrelated change to addressbook.am.
and c) it does add README file into distribution.
And that change in addressbook.am was removing a leftover from old
build system (there are no separate Makefiles anymore), so maybe
you'll want to remove it sometime later.
But you are right about SYNCEVO_WFLAGS and wrapping AS_HELP_STRING(),
will fix that.
--
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.
2:43 p.m.
2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> +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.
This is hopefully fixed in HEAD of my branch. (Forced installation to
be partially sequential).
For now I couldn't test make -j or make -jX, where X is greater than
2, because it eats too much memory on my computer and gcc is being
killed by OOM Killer.
--
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.
6:34 p.m.
On Mi, 2011-08-31 at 20:23 +0200, Ove Kåven wrote:
Den 26. aug. 2011 11:20, skrev Patrick Ohly:
>> +- Add a check for qt-mobility for QtContacts backend.
>
> Not important. I wonder whether I should remove obsolete backends after 1.2.
Would this mean I'd have to fork the qtcontacts backend for Harmattan?
Oh, sorry. No, I merely forgot that there is still some use for it. In
that case we should keep it in the master branch and make all necessary
changes there to keep it working (API or build system changes). However,
I am not compiling it anymore, so it is likely that it'll break at some
point unless you keep an eye on it.
--
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.
3:55 p.m.
As far as I can tell, this patch should be applied. Or is there some
reason to compile the code in dbus/ if --enable-dbus-service is not
used?
I don't know if this is a regression.
--
Murray Cumming
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
4:09 p.m.
On Do, 2012-01-05 at 16:55 +0100, Murray Cumming wrote:
As far as I can tell, this patch should be applied. Or is there some
reason to compile the code in dbus/ if --enable-dbus-service is not
used?
For a while I compiled sync-ui and core SyncEvolution separately in
MeeGo. In that case, D-Bus service is disabled and dbus/glib needs to be
compiled.
In other words, decoupling dbus compilation from D-Bus service
compilation makes sense. But probably some of the current checks for
what needs to be compiled inside dbus are not quite correct, because
there is no real "enable/disable D-Bus" switch in configure.
--
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.
9:22 a.m.
On Fri, 2012-01-13 at 17:09 +0100, Patrick Ohly wrote:
On Do, 2012-01-05 at 16:55 +0100, Murray Cumming wrote:
> As far as I can tell, this patch should be applied. Or is there some
> reason to compile the code in dbus/ if --enable-dbus-service is not
> used?
For a while I compiled sync-ui and core SyncEvolution separately in
MeeGo. In that case, D-Bus service is disabled and dbus/glib needs to be
compiled.
In other words, decoupling dbus compilation from D-Bus service
compilation makes sense. But probably some of the current checks for
what needs to be compiled inside dbus are not quite correct, because
there is no real "enable/disable D-Bus" switch in configure.
I don't really understand. What is the dbus/ code used for if no
dbus-service is built or used?
We also noticed a relinking problem during make install, which is fixed
by this commit:
https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolut...
It's already in the concurrent-sync-sessions branch, though this
URL will probably stop working after a future rebase:
http://meego.gitorious.org/meego-middleware/syncevolution/commit/cac0725b...
I suggest that you put this in master.
This is necessary because you install some libraries in
<prefix>/lib/syncevolution/ but other libraries in <prefix>/lib/ and
autotools is apparently not able to deal with that when relinking before
installing. Is there a good reason for installing some libraries in a
sub-directory. Simplifying that might let use remove some hacks from the
build files.
--
Murray Cumming
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
10:05 a.m.
On Mi, 2012-01-25 at 10:22 +0100, Murray Cumming wrote:
On Fri, 2012-01-13 at 17:09 +0100, Patrick Ohly wrote:
> On Do, 2012-01-05 at 16:55 +0100, Murray Cumming wrote:
> > As far as I can tell, this patch should be applied. Or is there some
> > reason to compile the code in dbus/ if --enable-dbus-service is not
> > used?
>
> For a while I compiled sync-ui and core SyncEvolution separately in
> MeeGo. In that case, D-Bus service is disabled and dbus/glib needs to be
> compiled.
>
> In other words, decoupling dbus compilation from D-Bus service
> compilation makes sense. But probably some of the current checks for
> what needs to be compiled inside dbus are not quite correct, because
> there is no real "enable/disable D-Bus" switch in configure.
I don't really understand. What is the dbus/ code used for if no
dbus-service is built or used?
It provides the D-Bus client libraries that could be used in combination
with a syncevo-dbus-service that was compiled separately. It's a bit
unusual to compile the same code twice; I had to do it in the past
because of the way how MeeGo was configured in OBS at the time (GTK not
part of the core OS).
We also noticed a relinking problem during make install, which is
fixed
by this commit:
https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolut...
It's already in the concurrent-sync-sessions branch, though this
URL will probably stop working after a future rebase:
http://meego.gitorious.org/meego-middleware/syncevolution/commit/cac0725b...
I suggest that you put this in master.
Thanks, merged. I think I saw that once, but then couldn't reproduce,
probably because "make -j" happened to not trigger it all the time.
This is necessary because you install some libraries in
<prefix>/lib/syncevolution/ but other libraries in <prefix>/lib/ and
autotools is apparently not able to deal with that when relinking before
installing. Is there a good reason for installing some libraries in a
sub-directory. Simplifying that might let use remove some hacks from the
build files.
I've wondered about that myself recently. In the end I settled on adding
some hacks instead of moving the libs, mostly just because it was the
smaller change.
The original motivation was to avoid file clashes with other packages
also providing libgdbus.so. That alone wasn't enough, because later
symbols in that lib clashed with similarly named symbols in glib, so the
lib and all symbols were renamed.
I don't think there still is any reason to install normal libraries in
usr/lib/libsyncevolution. It should be used only for modules which get
dlopened(). Want to provide a patch?
--
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.
10:24 a.m.
On Wed, 2012-01-25 at 10:05 +0000, Patrick Ohly wrote:
I don't think there still is any reason to install normal
libraries in
usr/lib/libsyncevolution. It should be used only for modules which get
dlopened(). Want to provide a patch?
Sure. I will do that.
--
Murray Cumming
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
1:55 p.m.
On Wed, 2012-01-25 at 10:05 +0000, Patrick Ohly wrote:
--
Murray Cumming
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
Is there a good reason for installing some libraries in a
> sub-directory. Simplifying that might let use remove some hacks from
the
> build files.
I've wondered about that myself recently. In the end I settled on
adding
some hacks instead of moving the libs, mostly just because it was the
smaller change.
The original motivation was to avoid file clashes with other packages
also providing libgdbus.so. That alone wasn't enough, because later
symbols in that lib clashed with similarly named symbols in glib, so
the
lib and all symbols were renamed.
I don't think there still is any reason to install normal libraries in
usr/lib/libsyncevolution. It should be used only for modules which get
dlopened(). Want to provide a patch?
Sorry for the delay. Here it is. It's very simple.
This might also make the whole install-am override/hack unnecessary, but
let's be cautious.
2:25 p.m.
On Mon, 2012-02-13 at 14:55 +0100, Murray Cumming wrote:
On Wed, 2012-01-25 at 10:05 +0000, Patrick Ohly wrote:
> Is there a good reason for installing some libraries in a
> > sub-directory. Simplifying that might let use remove some hacks from
> the
> > build files.
>
> I've wondered about that myself recently. In the end I settled on
> adding
> some hacks instead of moving the libs, mostly just because it was the
> smaller change.
>
> The original motivation was to avoid file clashes with other packages
> also providing libgdbus.so. That alone wasn't enough, because later
> symbols in that lib clashed with similarly named symbols in glib, so
> the
> lib and all symbols were renamed.
>
> I don't think there still is any reason to install normal libraries in
> usr/lib/libsyncevolution. It should be used only for modules which get
> dlopened(). Want to provide a patch?
Sorry for the delay. Here it is. It's very simple.
... and it breaks "make -j install" ;-}
http://syncev.meego.com/2012-02-15-11-13_dist/lucid-amd64/4-compile/outpu...
The libs are installed with:
/bin/bash ./libtool --mode=install /usr/bin/install -c src/syncevo/libsyncevolution.la
src/gdbus/libgdbussyncevo.la src/dbus/glib/libsyncevo-dbus.la
'/data/runtests/work/lucid-amd64/install/usr/lib'
That's libsyncevolution.la before libgdbussyncevo.la. I guess it would
work if libgdbussyncevo.la came before libsyncevolution.la...
All in master now:
commit db574bec4477d8e6b0f4bedf2b709d105f8df196
Author: Murray Cumming <murrayc(a)murrayc.com>
Date: Mon Feb 13 13:41:03 2012 +0100
Do not install libgdbussyncevo in a subdir
commit 8602d3d216c93f8c903b5aa53250be5aae1c9c14
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Feb 15 14:03:54 2012 +0000
autotools: compile GDBus before libsyncevolution
libsyncevolution depends on GDBus, which therefore must be dealt
with first.
Mostly the dependencies take care of the right compilation order.
Installing the results is different, items of the same kind are
installed in the order in which they are added to their variables,
which in turn is defined by the order in which .am files are
included.
That broke when making libgdbussyncevo a normal lib like
libsyncevolution (see next commit).
--
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.
3258
days inactive
3431
days old
syncevolution@synevolution.org
18 comments
4 participants
participants (4)
-
Krzesimir Nowak -
Murray Cumming -
Ove Kåven -
Patrick Ohly