Mi Sep 10 2008 11:26:31 EDT von Chenthill in 0000000000Sent Items> an Patrick Ohly
Betreff: Re: [Evolution-hackers] Removing libical fork, moving to new upstream?>
> > How would you feel about a global flag which tells libical how to
> > allocate memory?
>
> The problem with that is that it is not possible to mix code which uses
> the old and the new semantic. For example, a program or library which
> uses libical directly, using the old semantic, couldn't be combined with
> the Evolution libraries.
Yes right. Its not possible to have the old semantic with changed memory
allocation.>Since we do really want to remove the fork and pick up packages from
> To let old and new code coexists I would suggest the following approach:
> 1. The Evolution patch gets applied, making the core functions safe
> to use
> 2. The function implementations whose semantic has changed get
> renamed; I kind of like the _r suffix, but _alloc or _copy would
> also work.
> 3. Under the old names small wrappers are added which establish the
> old behavior again by copying the string into the ring buffer
> and freeing the dynamically allocated one: this incurs some
> overhead, but usage of these versions of the calls is
> discouraged anyway. By using function attributes it would be
> possible to trigger deprecation warnings for code which still
> uses them.
> 4. In the header file both variants are declared.
> 5. In addition, ical.h also redefines the old names to the new
> names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code
> already does that and therefore continues to work with such a
> modified upstream libical without source code changes.
>
> I personally would prefer to avoid step 5 and rather do a search/replace
> in Evolution, but Chenthill didn't like that.
upstream, I can change the apis in evolution related packages if a new
set of apis with some suffix is provided from libical upstream.
The old patch is attached with bug 516408. You can find the patches at,
http://svn.gnome.org/viewvc/libical?view=revision&revision=633
and
http://svn.gnome.org/viewvc/libical?view=revision&revision=637
thanks, Chenthill.
Since it doesn't make sense imho to mix old style and new style api calls in one application imho, and I hink we can deprecate the old style.
It also should be exeptable to drop binary compatibility; raise the lib-version, and add one significant incompatible function here, which gets triggered, so distributors have to recompile applications.
I think the oldstyle methods realy should just be wrappers in the headers, and I like the idea of hiding them via an define.
We also have the new include schematic of having libical/ical.h than <ical.h> maybe this could be used to do it imlicit, so no define would be needed in the old case.
Wilfried Goesgens