[Opensync-devel] Relocate OpenSync

[Henrik /KaarPoSoft <kaarposoft@us...>]

Dear developers, testers, and everyone else!

If you build OpenSync out of SVN, it will not be "relocatable".

What I mean is:
- If you try to build with a different CMAKE_INSTALL_PREFIX
- If you move the whole installation e.g. from /usr/local/lib to /local/lib
then you are out of luck: it will not work.

There are - as far as I can see - two reasons for this problem:
- CMakeLists.txt uses absolute paths instead of realative for INSTALL
- Hard coded paths get into libopensync.so (mostly due to config.h).

I do not know about .deb packages, but at least rpm has an option to use 
a different prefix, and this will not work.
Further, if you pack with CPack, or build in /usr/local and want to 
distribute in /usr/ then you are out of luck.

I have submitted bug reports to this effect: #854 and #855 and also 
libsyncml #166.

Well, they are not just bug reports, they actually contain PATCHES which 
seems to fix the problems.

Hence I would be really grateful and really appreciate, if all you 
hawk-eyes out there would have a look at the patches and let me (us...) 
know if they look OK, and then if some of you with sufficient privileges 
would check the changes into SVN.

Thanks in advance
/Henrik

Re: [Opensync-devel] Assertions are killing frontend GUI's

[Henrik /KaarPoSoft <kaarposoft@us...>]

Daniel Gollub wrote:
> On Tuesday 09 September 2008 23:06:14 Henrik /KaarPoSoft wrote:
>   
>> Hi all,
>>
>> A frontend GUI wants to stay alive, no matter what errors may be
>> encountered in libraries it calls.
>>
>> An OpenSync frontend GUI may protect itself against signals and
>> exceptions on the main thread.
>> However, OpenSync are spawning new threads.
>>
>> Does anybody know a way a frontend GUI may protect itself against
>> signals and exceptions on those threads?
>>
>> As an example, see https://sourceforge.net/forum/message.php?msg_id=5232971
>> One user of my frontend GUI (http://bluezync.kaarposoft.dk/) users
>> reports  that a problem in libsyncml kills Thunderbird (the frontend GUI).
>>
>> Is there any way a frontend GUI can protect itself against such errors?
>> Or some way OpenSync may not just bail out, but present a nice error
>> message to the GUI?
>>
>> Any thoughts on this would be much appreciated.
>>     
>
> That's the purpose of assert(). We often are lazy instead of writing proper 
> error handling we just place an assert(). Developers should of course only 
> use assert() to hunt only very very unintended and complex error conditions. 
> (Wrong API usage, unintended values in internal API, ...)
>
> When shipping this to a regular user (maybe also tester?) you should make sure 
> the build which got used is compiled with -DNDEBUG. So an assert() will not 
> cause an expection:
>
> --- man 3 assert ---
>  DESCRIPTION
>        If  the  macro  NDEBUG  was  defined  at the moment <assert.h> was last
>        included, the macro assert() generates no code, and hence does  nothing
>        at all.  Otherwise, the macro assert() prints an error message to stan‐
>        dard error and terminates the program by calling abort(3) if expression
>        is false (i.e., compares equal to zero).
>
>        The  purpose  of  this macro is to help the programmer find bugs in his
>        program.   The  message  "assertion  failed  in  file  foo.c,  function
>        do_bar(), line 1287" is of no help at all to a user.
> ----
>
> So, anything you find via assert() - report them! Make sure for "production" 
> release (in CMake there is a default BuildType which is called 
> RelWithDebInfo, which should also include -DNDEBUG) is build with -DNDEBUG.
>
> Of course assert() which handle error conditions (OOM, wrong values from some 
> device/protocol/user, ...) should be replaced by proper error handling.
>
> best regards,
> Daniel
>
>   
I only partially agree )-:

I do not think just compiling with NDEBUG is a good idea.
If the assert was appropriate in development/unstable phase, it is also 
appropriate in distribution.
After all, if the assertion should have triggered but was not compiled in,
we will probably just fail in a different place.

And I do think that either way, the threads created by OpenSync should 
be protected against signals!
In my opinion it would be much better to report the error to the end 
user than to crash his application.

The first time an end user sees his frontend crash and corrupt his 
calendar or address book,
is going to be the last time he uses it!

/Henrik

Re: [Opensync-devel] Assertions are killing frontend GUI's

[Daniel Gollub <dgollub@su...>]

On Tuesday 09 September 2008 23:06:14 Henrik /KaarPoSoft wrote:
> Hi all,
>
> A frontend GUI wants to stay alive, no matter what errors may be
> encountered in libraries it calls.
>
> An OpenSync frontend GUI may protect itself against signals and
> exceptions on the main thread.
> However, OpenSync are spawning new threads.
>
> Does anybody know a way a frontend GUI may protect itself against
> signals and exceptions on those threads?
>
> As an example, see https://sourceforge.net/forum/message.php?msg_id=5232971
> One user of my frontend GUI (http://bluezync.kaarposoft.dk/) users
> reports  that a problem in libsyncml kills Thunderbird (the frontend GUI).
>
> Is there any way a frontend GUI can protect itself against such errors?
> Or some way OpenSync may not just bail out, but present a nice error
> message to the GUI?
>
> Any thoughts on this would be much appreciated.

That's the purpose of assert(). We often are lazy instead of writing proper 
error handling we just place an assert(). Developers should of course only 
use assert() to hunt only very very unintended and complex error conditions. 
(Wrong API usage, unintended values in internal API, ...)

When shipping this to a regular user (maybe also tester?) you should make sure 
the build which got used is compiled with -DNDEBUG. So an assert() will not 
cause an expection:

--- man 3 assert ---
 DESCRIPTION
       If  the  macro  NDEBUG  was  defined  at the moment <assert.h> was last
       included, the macro assert() generates no code, and hence does  nothing
       at all.  Otherwise, the macro assert() prints an error message to stan‐
       dard error and terminates the program by calling abort(3) if expression
       is false (i.e., compares equal to zero).

       The  purpose  of  this macro is to help the programmer find bugs in his
       program.   The  message  "assertion  failed  in  file  foo.c,  function
       do_bar(), line 1287" is of no help at all to a user.
----

So, anything you find via assert() - report them! Make sure for "production" 
release (in CMake there is a default BuildType which is called 
RelWithDebInfo, which should also include -DNDEBUG) is build with -DNDEBUG.

Of course assert() which handle error conditions (OOM, wrong values from some 
device/protocol/user, ...) should be replaced by proper error handling.

best regards,
Daniel