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.
> $(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
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
then you're going to end up with a symlink in src/backends/webdav which,
relative to the current directory, would resolve to
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
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
Anyway, I'm not sure what exactly you're trying to achieve by
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
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
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.