opensync-users

[Opensync-users] Problem compiling synce plugin in FC4

[A. <re...@am...>]

Hi

I'm trying to compile the synce plugin on my newly installed fedora core
4. Synce is installed using the usual repositories, and I have the
following packages:
synce-0.9.1-3.fc4
synce-devel-0.9.1-3.fc4

unfortunatly, the since plugin is looking for include files
in /usr/include/rra/ while they are all in /usr/include/.

Trying to use --with-rra options for configure is not working since it's
looking for the rra folder.

Is there a solution (outside creating manually the rra folder and
copying the include files in it)?

RemyA

-- 
E-mail : Re...@Am...
Web : http://www.amouroux.org/
Yahoo Id: kelkooremya

Re: [Opensync-users] Problem compiling synce plugin in FC4

[Armin B. <arm...@de...>]

Hi,

i commited a fix. the --with-rra option should now work for fedora as
well. so please do a "svn up" for the synce plugin

Armin

R=C3=A9my Amouroux wrote:
> Hi
>=20
> I'm trying to compile the synce plugin on my newly installed fedora cor=
e
> 4. Synce is installed using the usual repositories, and I have the
> following packages:
> synce-0.9.1-3.fc4
> synce-devel-0.9.1-3.fc4
>=20
> unfortunatly, the since plugin is looking for include files
> in /usr/include/rra/ while they are all in /usr/include/.
>=20
> Trying to use --with-rra options for configure is not working since it'=
s
> looking for the rra folder.
>=20
> Is there a solution (outside creating manually the rra folder and
> copying the include files in it)?
>=20
> RemyA
>=20

Re: [Opensync-users] Problem compiling synce plugin in FC4

[A. <re...@am...>]

Hello armin and thanks for your reactivity

The modification you have made is working for me only if I modify the
verification that syncmngr.h exists. As in the following:
Index: acinclude.m4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- acinclude.m4        (revision 701)
+++ acinclude.m4        (working copy)
@@ -76,8 +76,8 @@
        AC_CHECK_LIB(rra,rra_syncmgr_new,,[
                AC_MSG_ERROR([Can't find RRA library])
                ])
-       AC_CHECK_HEADERS(rra/syncmgr.h,,[
+       AC_CHECK_HEADERS(syncmgr.h,,[
                AC_MSG_ERROR([Can't find rra/syncmgr.h])
                ])

-])
\ No newline at end of file
+])


But, since the .c files are hard-coded looking for rra/..., it won't
work anyway. Example in synce_plugin.c

#include <rra/appointment.h>
#include <rra/contact.h>
#include <rra/task.h>
#include <rra/matchmaker.h>
#include <rra/uint32vector.h>
#include <rra/syncmgr.h>

The last person modifying the spec file for the synce package for FC4 is
andreas.bierfert[AT]lowlatency.de (from the changelog).

(the packages are provided within the EXTRAs part of FC4).

I'll try to contact him to understand why the include files are not in a
subdirectory (which is the sensible thing to do from my point of view).

Regards

	RemyA

On Mon, 2005-10-03 at 12:01 +0200, Armin Bauer wrote:
> Hi,
>=20
> i commited a fix. the --with-rra option should now work for fedora as
> well. so please do a "svn up" for the synce plugin
>=20
> Armin
>=20
> R=C3=A9my Amouroux wrote:
> > Hi
> >=20
> > I'm trying to compile the synce plugin on my newly installed fedora cor=
e
> > 4. Synce is installed using the usual repositories, and I have the
> > following packages:
> > synce-0.9.1-3.fc4
> > synce-devel-0.9.1-3.fc4
> >=20
> > unfortunatly, the since plugin is looking for include files
> > in /usr/include/rra/ while they are all in /usr/include/.
> >=20
> > Trying to use --with-rra options for configure is not working since it'=
s
> > looking for the rra folder.
> >=20
> > Is there a solution (outside creating manually the rra folder and
> > copying the include files in it)?
> >=20
> > RemyA
> >=20
>=20
--=20
E-mail : Re...@Am...
Web : http://www.amouroux.org/
Yahoo Id: kelkooremya

Re: [Opensync-users] Problem compiling synce plugin in FC4

[Armin B. <arm...@de...>]

R=C3=A9my Amouroux wrote:
> Hello armin and thanks for your reactivity
>=20
> The modification you have made is working for me only if I modify the
> verification that syncmngr.h exists. As in the following:
> Index: acinclude.m4
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- acinclude.m4        (revision 701)
> +++ acinclude.m4        (working copy)
> @@ -76,8 +76,8 @@
>         AC_CHECK_LIB(rra,rra_syncmgr_new,,[
>                 AC_MSG_ERROR([Can't find RRA library])
>                 ])
> -       AC_CHECK_HEADERS(rra/syncmgr.h,,[
> +       AC_CHECK_HEADERS(syncmgr.h,,[
>                 AC_MSG_ERROR([Can't find rra/syncmgr.h])
>                 ])
>=20
> -])
> \ No newline at end of file
> +])
>=20
>=20
> But, since the .c files are hard-coded looking for rra/..., it won't
> work anyway. Example in synce_plugin.c
>=20
> #include <rra/appointment.h>
> #include <rra/contact.h>
> #include <rra/task.h>
> #include <rra/matchmaker.h>
> #include <rra/uint32vector.h>
> #include <rra/syncmgr.h>
>=20
> The last person modifying the spec file for the synce package for FC4 i=
s
> andreas.bierfert[AT]lowlatency.de (from the changelog).
>=20
> (the packages are provided within the EXTRAs part of FC4).
>=20
> I'll try to contact him to understand why the include files are not in =
a
> subdirectory (which is the sensible thing to do from my point of view).=

>=20

yes. but the way that synce handles things is also not completely
correct. if the --with-rra switch adds the ${includedir}/rra dir to the
included directories _and_ the #include commands search for a rra/ again
the switch wont work correctly.

I think the correct way is to do it like this:

rra and synce get installed into a directory ${includedir}/rra-$version/r=
ra

this way its possible to use the rra/ prefix in the #include statement
(which works also a sort of a namespace so includes dont overlap) but it
is also possible to install several versions separately.

> Regards
>=20
> 	RemyA
>=20
> On Mon, 2005-10-03 at 12:01 +0200, Armin Bauer wrote:
>=20
>>Hi,
>>
>>i commited a fix. the --with-rra option should now work for fedora as
>>well. so please do a "svn up" for the synce plugin
>>
>>Armin
>>
>>R=C3=A9my Amouroux wrote:
>>
>>>Hi
>>>
>>>I'm trying to compile the synce plugin on my newly installed fedora co=
re
>>>4. Synce is installed using the usual repositories, and I have the
>>>following packages:
>>>synce-0.9.1-3.fc4
>>>synce-devel-0.9.1-3.fc4
>>>
>>>unfortunatly, the since plugin is looking for include files
>>>in /usr/include/rra/ while they are all in /usr/include/.
>>>
>>>Trying to use --with-rra options for configure is not working since it=
's
>>>looking for the rra folder.
>>>
>>>Is there a solution (outside creating manually the rra folder and
>>>copying the include files in it)?
>>>
>>>RemyA
>>>
>>

Re: [Opensync-users] Problem compiling synce plugin in FC4

[A. <re...@am...>]

Waiting for an answer from the synce-devel maintainer, I wanted to go
further compiling the synce plugin.

I came back to what is in CVS by redoing a checkout and created a rra
directory containing all the include files provided by
synce-devel-0.9.1-3.fc4.

I'm using the last gcc provided with the FC4: gcc-4.0.1-4.fc4

So, now, configure works like a charm and I have no include errors since
rra/ is there.

But, I have compilation errors :-(

Here is the traces.

gcc -DHAVE_CONFIG_H -I. -I. -I..
-I/home/amourouxr/Tools/usr/local/include/rra
-I/home/amourouxr/Tools/usr/local/include -Wall -Werror
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/libxml2
-I/home/amourouxr/Tools/usr/local/include/opensync-1.0 -g -O2 -MT
synce_plugin.lo -MD -MP -MF .deps/synce_plugin.Tpo -c synce_plugin.c
-fPIC -DPIC -o .libs/synce_plugin.o
cc1: warnings being treated as errors
synce_plugin.c: In function 'm_report_todo_changes':
synce_plugin.c:256: warning: pointer targets in passing argument 1 of
'osync_print_binary' differ in signedness
synce_plugin.c: In function 'm_report_cal_changes':
synce_plugin.c:304: warning: pointer targets in passing argument 1 of
'osync_print_binary' differ in signedness

After removing the two lines (calls to osync_print_binary seems to be
only for debugging purposes), everything compiles fine.

I'll try synchronisation tomorrow.

one comment below about your answer, armin.

> I think the correct way is to do it like this:
> 
> rra and synce get installed into a directory ${includedir}/rra-$version/rra
> 
> this way its possible to use the rra/ prefix in the #include statement
> (which works also a sort of a namespace so includes dont overlap) but it
> is also possible to install several versions separately.

I'm not sure it's really interesting to have the version in the
directory name. It makes things difficult for the developper using the
library since it has to provide configuration files managing the version
information and cannot rely on a default location.
If the maintainer of the package really want to allow several
installations of the same package, he has to make that package
relocatable. Thus, with a simple --with-rra=DIR, you can use different
version of the library.

Regards

RemyA
-- 
E-mail : Re...@Am...
Web : http://www.amouroux.org/
Yahoo Id: kelkooremya

Re: [Opensync-users] Problem compiling synce plugin in FC4

[Armin B. <arm...@de...>]

R=C3=A9my Amouroux wrote:
> Waiting for an answer from the synce-devel maintainer, I wanted to go
> further compiling the synce plugin.
>=20
> I came back to what is in CVS by redoing a checkout and created a rra
> directory containing all the include files provided by
> synce-devel-0.9.1-3.fc4.
>=20
> I'm using the last gcc provided with the FC4: gcc-4.0.1-4.fc4
>=20
> So, now, configure works like a charm and I have no include errors sinc=
e
> rra/ is there.
>=20
> But, I have compilation errors :-(
>=20
> Here is the traces.
>=20
> gcc -DHAVE_CONFIG_H -I. -I. -I..
> -I/home/amourouxr/Tools/usr/local/include/rra
> -I/home/amourouxr/Tools/usr/local/include -Wall -Werror
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> -I/usr/include/libxml2
> -I/home/amourouxr/Tools/usr/local/include/opensync-1.0 -g -O2 -MT
> synce_plugin.lo -MD -MP -MF .deps/synce_plugin.Tpo -c synce_plugin.c
> -fPIC -DPIC -o .libs/synce_plugin.o
> cc1: warnings being treated as errors
> synce_plugin.c: In function 'm_report_todo_changes':
> synce_plugin.c:256: warning: pointer targets in passing argument 1 of
> 'osync_print_binary' differ in signedness
> synce_plugin.c: In function 'm_report_cal_changes':
> synce_plugin.c:304: warning: pointer targets in passing argument 1 of
> 'osync_print_binary' differ in signedness
>=20
> After removing the two lines (calls to osync_print_binary seems to be
> only for debugging purposes), everything compiles fine.
>=20

Thanks. i committed a fix for this.


> I'll try synchronisation tomorrow.
>=20
> one comment below about your answer, armin.
>=20
>=20
>>I think the correct way is to do it like this:
>>
>>rra and synce get installed into a directory ${includedir}/rra-$version=
/rra
>>
>>this way its possible to use the rra/ prefix in the #include statement
>>(which works also a sort of a namespace so includes dont overlap) but i=
t
>>is also possible to install several versions separately.
>=20
>=20
> I'm not sure it's really interesting to have the version in the
> directory name. It makes things difficult for the developper using the
> library since it has to provide configuration files managing the versio=
n
> information and cannot rely on a default location.
> If the maintainer of the package really want to allow several
> installations of the same package, he has to make that package
> relocatable. Thus, with a simple --with-rra=3DDIR, you can use differen=
t
> version of the library.

ok, right. with opensync i use pkgconfig so i always get the correct
include path from it but i can also install another version and
overwrite the include.

>=20
> Regards
>=20
> RemyA

[Opensync-users] Synce plugin in FC4

[A. <re...@am...>]

Hello

I finally compiled the synce plugin using a fresh checkout from cvs and
used it  for synchronisation with evo2 and the file plugin

I first tried to use a pair synce-evo2.

Unfortunately, I had a segmentation fault and it was impossible to
understand which one had a problem.

So, I put in place a pair synce-file and did my first synchronisation.

$ msynctool --showgroup ipaqFile
Groupname: ipaqFile
Member 1: synce-plugin
Member 2: file-sync


It worked perfectly well and I had a folder full of files containing
each either a VCAL or a VCALENDAR. And it looks like they had all one
probl=C3=A8me: wherever the value of the field contained a non ascii
character (like an accent letter), the value was cut.
For instance, instead of=20
   SUMMARY:Appeler caisse d'=C3=A9pargne
I have
   SUMMARY:Appeler caisse d'

I naturally did some modifications (manually) on a fem items on my Ipaq
and tried to synch again.

msynctool started to ask questions about conflicts with the following
trace before asking the question:

Conflict for Mapping 0x879f460:

Entry 1:
UID: 02002e1e
File: 02002e1e
Size: 211

Entry 2:
UID: 02002e1e
<?xml version=3D"1.0"?>
<contact>
  <UnknownNode>
    <NodeName>PRODID</NodeName>
    <Content>-//SYNCE RRA//NONSGML Version 1//EN</Content>
  </UnknownNode>
  <Telephone>
    <Content>+33 820 04 20 20</Content>
    <Type>WORK</Type>
    <Type>VOICE</Type>
    <Type>PREF</Type>
  </Telephone>
  <Telephone>
    <Content>+33 800 08 24 24</Content>
    <Type>WORK</Type>
    <Type>VOICE</Type>
  </Telephone>
  <FullName>
    <Content>Achard, Sandrine</Content>
  </FullName>
  <Name>
    <LastName>Achard</LastName>
    <FirstName>Sandrine</FirstName>
  </Name>
  <Organization>
    <Name>Total Gaz</Name>
  </Organization>
</contact>

Which entry do you want to use (D for Duplication)?

Each time I answered "2" (which is wrong in my case, since member 2 is
the file plugin and no changes were done in that part) but it looks like
I had a conflict with each entry, thus I simply stopped the sync.

Any idea about what I should do (apart debugging the stuff myself) ?=20


Information about opensync and FC4.

On Mon, 2005-10-03 at 23:17 +0200, Armin Bauer wrote:
>=20
> R=C3=A9my Amouroux wrote:
> > Waiting for an answer from the synce-devel maintainer, I wanted to go
> > further compiling the synce plugin.

He answered quite quickly: opensync is in his todolist and the opensync
rpms should appear in Fedora extra in a matter of days.

regards

	RemyA
--=20
E-mail : Re...@Am...
Web : http://www.amouroux.org/
Yahoo Id: kelkooremya

Re: [Opensync-users] Problem compiling synce plugin in FC4

[Pierre O. <drz...@dr...>]

Armin Bauer wrote:
> 
> yes. but the way that synce handles things is also not completely
> correct. if the --with-rra switch adds the ${includedir}/rra dir to the
> included directories _and_ the #include commands search for a rra/ again
> the switch wont work correctly.
> 

I had a look at this and it seems that synce is particularly confused. 
 From what I can tell from it's Makefile.am it is supposed to install 
stuff into /usr/include, which is also where they end up on my system. 
But the .m4 macros that are included still insist on /usr/include/rra. 
Something is rotten in the state of Denmark...

I suggest we revert the rra/-addition in the m4-script.

Rgds
Pierre

Re: [Opensync-users] Problem compiling synce plugin in FC4

[David E. <tw...@us...>]

On Thu, 2005-10-13 at 16:36 +0200, Pierre Ossman wrote:
> Armin Bauer wrote:
> > 
> > yes. but the way that synce handles things is also not completely
> > correct. if the --with-rra switch adds the ${includedir}/rra dir to the
> > included directories _and_ the #include commands search for a rra/ again
> > the switch wont work correctly.
> > 
> 
> I had a look at this and it seems that synce is particularly confused. 
>  From what I can tell from it's Makefile.am it is supposed to install 
> stuff into /usr/include, which is also where they end up on my system. 
> But the .m4 macros that are included still insist on /usr/include/rra. 
> Something is rotten in the state of Denmark...
> 
> I suggest we revert the rra/-addition in the m4-script.
> 
> Rgds
> Pierre

They are meant to install to an rra subdirectory.

See the Makefile.am:

http://cvs.sourceforge.net/viewcvs.py/synce/rra/lib/Makefile.am?rev=1.19&view=auto


-- 
Regards,
               -\- David Eriksson -/-

        SynCE - http://synce.sourceforge.net
      ScummVM - http://scummvm.sourceforge.net
     Desquirr - http://desquirr.sourceforge.net

Re: [Opensync-users] Synce plugin in FC4

[Armin B. <arm...@de...>]

Hi Remy,

are the vcards you are synchronizing of type 3.0 or 2.1?

R=C3=A9my Amouroux wrote:
> Hello
>=20
> I finally compiled the synce plugin using a fresh checkout from cvs and=

> used it  for synchronisation with evo2 and the file plugin
>=20
> I first tried to use a pair synce-evo2.
>=20
> Unfortunately, I had a segmentation fault and it was impossible to
> understand which one had a problem.
>=20
> So, I put in place a pair synce-file and did my first synchronisation.
>=20
> $ msynctool --showgroup ipaqFile
> Groupname: ipaqFile
> Member 1: synce-plugin
> Member 2: file-sync
>=20
>=20
> It worked perfectly well and I had a folder full of files containing
> each either a VCAL or a VCALENDAR. And it looks like they had all one
> probl=C3=A8me: wherever the value of the field contained a non ascii
> character (like an accent letter), the value was cut.
> For instance, instead of=20
>    SUMMARY:Appeler caisse d'=C3=A9pargne
> I have
>    SUMMARY:Appeler caisse d'
>=20
> I naturally did some modifications (manually) on a fem items on my Ipaq=

> and tried to synch again.
>=20
> msynctool started to ask questions about conflicts with the following
> trace before asking the question:
>=20
> Conflict for Mapping 0x879f460:
>=20
> Entry 1:
> UID: 02002e1e
> File: 02002e1e
> Size: 211
>=20
> Entry 2:
> UID: 02002e1e
> <?xml version=3D"1.0"?>
> <contact>
>   <UnknownNode>
>     <NodeName>PRODID</NodeName>
>     <Content>-//SYNCE RRA//NONSGML Version 1//EN</Content>
>   </UnknownNode>
>   <Telephone>
>     <Content>+33 820 04 20 20</Content>
>     <Type>WORK</Type>
>     <Type>VOICE</Type>
>     <Type>PREF</Type>
>   </Telephone>
>   <Telephone>
>     <Content>+33 800 08 24 24</Content>
>     <Type>WORK</Type>
>     <Type>VOICE</Type>
>   </Telephone>
>   <FullName>
>     <Content>Achard, Sandrine</Content>
>   </FullName>
>   <Name>
>     <LastName>Achard</LastName>
>     <FirstName>Sandrine</FirstName>
>   </Name>
>   <Organization>
>     <Name>Total Gaz</Name>
>   </Organization>
> </contact>
>=20
> Which entry do you want to use (D for Duplication)?
>=20
> Each time I answered "2" (which is wrong in my case, since member 2 is
> the file plugin and no changes were done in that part) but it looks lik=
e
> I had a conflict with each entry, thus I simply stopped the sync.
>=20
> Any idea about what I should do (apart debugging the stuff myself) ?=20

i think there are 3 separate problems here:

1. the segfault: this should not happen of course. a trace from opensync
and a backtrace with gdb should help to find the bug.

2. wrong handling of non ascii characters: this is a know bug. the cause
is that there is no way currently to specify the encoding of a vcard. so
the encoding is not changed and opensync cannot handle the input since
it is not utf8. this will be fixed in one of the next versions.

3. conflicts: since your first sync failed, opensync will do a slow-sync
which means that it will load all objects from each side and compare
them again. the comparison obviously does not work correctly since it
raises a lot of conflicts. a trace of the synchronization that raises
these conflicts should help.

Armin

>=20
>=20
> Information about opensync and FC4.
>=20
> On Mon, 2005-10-03 at 23:17 +0200, Armin Bauer wrote:
>=20
>>R=C3=A9my Amouroux wrote:
>>
>>>Waiting for an answer from the synce-devel maintainer, I wanted to go
>>>further compiling the synce plugin.
>=20
>=20
> He answered quite quickly: opensync is in his todolist and the opensync=

> rpms should appear in Fedora extra in a matter of days.
>=20
> regards
>=20
> 	RemyA

Re: [Opensync-users] Synce plugin in FC4

[A. <rem...@ke...>]

On Wed, 2005-10-05 at 21:13 +0200, Armin Bauer wrote:
> Hi Remy,
> 
> are the vcards you are synchronizing of type 3.0 or 2.1?

>From the file stored in the folder used by the file-sync plugin, they
are 2.1

> i think there are 3 separate problems here:
> 
> 1. the segfault: this should not happen of course. a trace from opensync
> and a backtrace with gdb should help to find the bug.

I'll provide that later this week.

> 
> 2. wrong handling of non ascii characters: this is a know bug. the cause
> is that there is no way currently to specify the encoding of a vcard. so
> the encoding is not changed and opensync cannot handle the input since
> it is not utf8. this will be fixed in one of the next versions.

Is it not possible for the synce plugin to assume a given charset
(windows something) for the pocketpc and then translate to utf8 before
passing the information to the opensync engine itslef ?

> 3. conflicts: since your first sync failed, 

well, the sync between the pocketpc and the file looked to have worked
correctly. Remember: it was a sync for a new pair. The one that did not work
was the evo2-synce and I did not use it anymore.

> opensync will do a slow-sync
> which means that it will load all objects from each side and compare
> them again. the comparison obviously does not work correctly since it
> raises a lot of conflicts. a trace of the synchronization that raises
> these conflicts should help.

by trace, you mean the debug output (mainly synce plugin traces) ad in
the attached file ? (it is the STDERR output of msynctool during the
sync with the conflicts)

BTW, the question for each of the conflict makes me think that the
plugin presents the content of the entry as a file and not as a
vcard/vcal stuff. Should the plugin presents the entry information as
the xml shown in the questions (in that case coming from the
file-sync) ?

Regards

	RemyA

-- 
E-mail : Re...@Am...
Web : http://www.amouroux.org/
Yahoo Id: kelkooremya
-- 
E-mail : Rem...@ke...
Kelkoo/Yahoo Architecture (http://www.yahoo.com/)
Yahoo Id: kelkooremya

Re: [Opensync-users] Problem compiling synce plugin in FC4

[Pierre O. <drz...@dr...>]

David Eriksson wrote:
> On Thu, 2005-10-13 at 16:36 +0200, Pierre Ossman wrote:
>   
>> Armin Bauer wrote:
>>     
>>> yes. but the way that synce handles things is also not completely
>>> correct. if the --with-rra switch adds the ${includedir}/rra dir to the
>>> included directories _and_ the #include commands search for a rra/ again
>>> the switch wont work correctly.
>>>
>>>       
>> I had a look at this and it seems that synce is particularly confused. 
>>  From what I can tell from it's Makefile.am it is supposed to install 
>> stuff into /usr/include, which is also where they end up on my system. 
>> But the .m4 macros that are included still insist on /usr/include/rra. 
>> Something is rotten in the state of Denmark...
>>
>> I suggest we revert the rra/-addition in the m4-script.
>>
>> Rgds
>> Pierre
>>     
>
> They are meant to install to an rra subdirectory.
>
> See the Makefile.am:
>
> http://cvs.sourceforge.net/viewcvs.py/synce/rra/lib/Makefile.am?rev=1.19&view=auto
>
>
>   

Hmm... missed the define there. A bit unorthodox solution. Perhaps that 
breaks on certain versions of autotools, causing the wrong location? 
It's not in rra/ on FC4, and there is no magic performed in the build 
process there.

Rgds
Pierre

Re: [Opensync-users] Problem compiling synce plugin in FC4

[David E. <tw...@us...>]

On Thu, 2005-10-13 at 17:00 +0200, Pierre Ossman wrote:
> David Eriksson wrote:
> > On Thu, 2005-10-13 at 16:36 +0200, Pierre Ossman wrote:
> >   
> >> Armin Bauer wrote:
> >>     
> >>> yes. but the way that synce handles things is also not completely
> >>> correct. if the --with-rra switch adds the ${includedir}/rra dir to the
> >>> included directories _and_ the #include commands search for a rra/ again
> >>> the switch wont work correctly.
> >>>
> >>>       
> >> I had a look at this and it seems that synce is particularly confused. 
> >>  From what I can tell from it's Makefile.am it is supposed to install 
> >> stuff into /usr/include, which is also where they end up on my system. 
> >> But the .m4 macros that are included still insist on /usr/include/rra. 
> >> Something is rotten in the state of Denmark...
> >>
> >> I suggest we revert the rra/-addition in the m4-script.
> >>
> >> Rgds
> >> Pierre
> >>     
> >
> > They are meant to install to an rra subdirectory.
> >
> > See the Makefile.am:
> >
> > http://cvs.sourceforge.net/viewcvs.py/synce/rra/lib/Makefile.am?rev=1.19&view=auto
> >
> >
> >   
> 
> Hmm... missed the define there. A bit unorthodox solution. Perhaps that 
> breaks on certain versions of autotools, causing the wrong location? 
> It's not in rra/ on FC4, and there is no magic performed in the build 
> process there.

Yeah it should not reuse "includedir", I'll get to it any decade... :-)

-- 
Regards,
               -\- David Eriksson -/-

        SynCE - http://synce.sourceforge.net
      ScummVM - http://scummvm.sourceforge.net
     Desquirr - http://desquirr.sourceforge.net