10:51 a.m.
Hello Ove!
In the following commit you changed the rule for syncevo-webdav-lookup:
commit ff97574d7026a008efa79bdc8a46c7fc6688d218
Author: Ove Kåven <ovek(a)arcticnet.no>
Date: Sat Aug 11 12:11:30 2012 +0200
Fixed broken rule for creating syncevo-webdav-lookup.
src/backends/webdav/syncevo-webdav-lookup:
$(srcdir)/src/backends/webdav/syncevo-webdav-lookup.sh
$(AM_V_GEN)rm -f $@ ; \
- ln -s $< $@
+ cd src/backends/webdav && ln -s $(notdir $<) $(notdir $@)
I noticed recently that this broke out-of-tree compilation, causing
syncevolution.org binaries to not have the script anymore.
Do you remember why the rule was broken for you? It works for me. Could
it be that srcdir was empty?
Guido fixed something like that for builddir:
commit 85fca619139a27016503fe8f312b9fcc870dc563
Author: Guido Günther <agx(a)sigxcpu.org>
Date: Sat May 18 19:14:39 2013 +0200
build: use top_builddir instead of builddir
when building syncevo-local-sync. Maemo's old automake doesn't now
about builddir.
This only fixes the one occurence relevant to Maemo.
diff --git a/src/src.am b/src/src.am
index 8da50e2..5505b07 100644
--- a/src/src.am
+++ b/src/src.am
@@ -183,7 +183,7 @@ src_syncevo_local_sync_LDADD = $(gdbus_build_dir)/libgdbussyncevo.la
$(CORE_LDAD
src_syncevo_local_sync_CPPFLAGS = -DHAVE_CONFIG_H -I$(gdbus_dir) $(src_cppflags)
src_syncevo_local_sync_CXXFLAGS = $(PCRECPP_CFLAGS) $(SYNCEVOLUTION_CXXFLAGS)
$(CORE_CXXFLAGS) $(GLIB_CFLAGS) $(DBUS_CFLAGS) $(LIBSOUP_CFLAGS) $(SYNCEVO_WFLAGS)
src_syncevo_local_sync_LDFLAGS = $(PCRECPP_LIBS) $(CORE_LD_FLAGS) $(LIBSOUP_LIBS)
-src_syncevo_local_sync_DEPENDENCIES = $(builddir)/$(gdbus_build_dir)/libgdbussyncevo.la
$(EXTRA_LTLIBRARIES) $(CORE_DEP) $(SYNTHESIS_DEP)
+src_syncevo_local_sync_DEPENDENCIES =
$(top_builddir)/$(gdbus_build_dir)/libgdbussyncevo.la $(EXTRA_LTLIBRARIES) $(CORE_DEP)
$(SYNTHESIS_DEP)
# Do the linking here, as with all SyncEvolution executables.
I'm now wondering why Guido only had to replace $(builddir) in one
place. $(builddir) and $(srcdir) still get used in several places, some
of them relevant for Maemo (?). A global search/replace seems in order
to fix the issue everywhere. With the non-recursive build system used by
SyncEvolution top_builddir == buildir and top_srcdir == srcdir anyway,
the non-top version is just a bit shorter.
Attached a patch for the syncevo-webdav-lookup problem. Does this look
right?
--
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.
5:10 p.m.
On 25. april 2014 12:51, Patrick Ohly wrote:
Hello Ove!
In the following commit you changed the rule for syncevo-webdav-lookup:
commit ff97574d7026a008efa79bdc8a46c7fc6688d218
Author: Ove Kåven <ovek(a)arcticnet.no>
Date: Sat Aug 11 12:11:30 2012 +0200
Fixed broken rule for creating syncevo-webdav-lookup.
src/backends/webdav/syncevo-webdav-lookup:
$(srcdir)/src/backends/webdav/syncevo-webdav-lookup.sh
$(AM_V_GEN)rm -f $@ ; \
- ln -s $< $@
+ cd src/backends/webdav && ln -s $(notdir $<) $(notdir $@)
I noticed recently that this broke out-of-tree compilation, causing
syncevolution.org binaries to not have the script anymore.
Do you remember why the rule was broken for you?
Well, it should be obvious. If you do something like
ln -s src/backends/webdav/syncevo-webdav-lookup.sh
src/backends/webdav/syncevo-webdav-lookup
then you're going to end up with a symlink in src/backends/webdav which,
relative to the current directory, would resolve to
src/backends/webdav/src/backends/webdav/syncevo-webdav-lookup.sh
which doesn't exist, i.e., you've just created a dangling symlink. (And
out-of-tree shouldn't matter. For in-tree builds, srcdir is supposed to
be ".", for out-of-tree builds it would be ".." or something. Both
cases
would create a broken symlink.)
So no, your change would not fix the issue.
In Debian's "debhelper" package, there's a "dh_link" that can
be used by
packagers to avoid such surprises (dh_link calculates the correct
relative path to use for the symlink before invoking ln). Sadly, that
script is, of course, only available on Debian and Ubuntu.
Anyway, I'm not sure what exactly you're trying to achieve by creating
this symlink? If this was for out-of-tree builds, couldn't you just,
say, copy the file?
Also, I'm not sure what problems Guido ran into. Which Maemo version?
Although I haven't tried compiling syncevolution 1.4 on Fremantle yet, I
didn't have any builddir issues with syncevolution 1.3, at least not
when I used the newest version of automake available for Fremantle
(automake 1.10.1), instead of the SDK default (automake 1.8.5). (That's
why I had the autogen-maemo.sh script, to force use of the best
autotools versions on Fremantle.)
5:25 p.m.
On Fri, 2014-04-25 at 19:10 +0200, Ove Kåven wrote:
On 25. april 2014 12:51, Patrick Ohly wrote:
> Hello Ove!
>
> In the following commit you changed the rule for syncevo-webdav-lookup:
>
> commit ff97574d7026a008efa79bdc8a46c7fc6688d218
> Author: Ove Kåven <ovek(a)arcticnet.no>
> Date: Sat Aug 11 12:11:30 2012 +0200
>
> Fixed broken rule for creating syncevo-webdav-lookup.
>
> src/backends/webdav/syncevo-webdav-lookup:
> $(srcdir)/src/backends/webdav/syncevo-webdav-lookup.sh
> $(AM_V_GEN)rm -f $@ ; \
> - ln -s $< $@
> + cd src/backends/webdav && ln -s $(notdir $<) $(notdir $@)
>
> I noticed recently that this broke out-of-tree compilation, causing
> syncevolution.org binaries to not have the script anymore.
>
> Do you remember why the rule was broken for you?
Well, it should be obvious. If you do something like
ln -s src/backends/webdav/syncevo-webdav-lookup.sh
src/backends/webdav/syncevo-webdav-lookup
then you're going to end up with a symlink in src/backends/webdav which,
relative to the current directory, would resolve to
src/backends/webdav/src/backends/webdav/syncevo-webdav-lookup.sh
which doesn't exist, i.e., you've just created a dangling symlink. (And
out-of-tree shouldn't matter. For in-tree builds, srcdir is supposed to
be ".", for out-of-tree builds it would be ".." or something. Both
cases
would create a broken symlink.)
I typically run "<absolute path>/configure" and then srcdir is an
absolute path. Perhaps it's different when using "mkdir build; cd
build; ../configure ...".
So no, your change would not fix the issue.
It fixed out-of-tree builds for me, but I agree, it doesn't handle the
other case.
Anyway, I'm not sure what exactly you're trying to achieve by
creating
this symlink? If this was for out-of-tree builds, couldn't you just,
say, copy the file?
The only advantage of the symlink is slightly lower disk usage, that's
all. Totally irrelevant in this case. So my first solution indeed used a
simply copy. I'll use that instead of trying to get the symlink right.
I think this broke when introducing the non-recursive make system. When
make ran inside the backend directory, using a symlink was easy.
Also, I'm not sure what problems Guido ran into. Which Maemo
version?
Although I haven't tried compiling syncevolution 1.4 on Fremantle yet, I
didn't have any builddir issues with syncevolution 1.3, at least not
when I used the newest version of automake available for Fremantle
(automake 1.10.1), instead of the SDK default (automake 1.8.5). (That's
why I had the autogen-maemo.sh script, to force use of the best
autotools versions on Fremantle.)
Perhaps he used the SDK default. I don't know. Anyway, if you don't have
a problem with the rules as they are now, then there's no reason to
change anything.
--
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:27 p.m.
On Fri, Apr 25, 2014 at 07:10:07PM +0200, Ove Kåven wrote:
[..snip..]
Also, I'm not sure what problems Guido ran into. Which Maemo
version?
Although I haven't tried compiling syncevolution 1.4 on Fremantle yet, I
didn't have any builddir issues with syncevolution 1.3, at least not when I
used the newest version of automake available for Fremantle (automake
1.10.1), instead of the SDK default (automake 1.8.5). (That's why I had the
autogen-maemo.sh script, to force use of the best autotools versions on
Fremantle.)
Setting up the Fremantle SDK is enough pain already so it is nicer to
use as few newer tools as possible (especially sine syncevolution is
quit consevative in that regards) and the change from builddir to
top_builddir seemed simple enough without any drawbacks.
Having the maemo build as much in line with the other builds so we don't
need a separate autogen.sh was a nice side effect.
Cheers,
-- Guido
2951
days inactive
2951
days old
syncevolution@synevolution.org
3 comments
3 participants
participants (3)
-
Guido Günther -
Ove Kåven -
Patrick Ohly