>Mi Sep 10 2008 11:26:31 EDT von Chenthill in 0000000000.Sent 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.
>
>>>
>>> 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.
>>
>Since we do really want to remove the fork and pick up packages from
>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
_______________________________________________
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
