Re: [ft-devel] web page for the forthcoming 2.2.0 release

[david turner]

Hi Werner and all,

> Perhaps we shall *rename* the library to, say, `libft2', instead of
> `libfreetype', together with a new API prefix `FT2_' instead of `FT_'.
> This would avoid the whole mess.
>
>   
Simply changing the library name is not going to change a lot of things 
due to the way dynamic
linking works with ELF, it's simply equivalent to changing the so 
version number.

Now, if we talk about a new API prefix, we're essentially asking that 
*all* clients that use FreeType
be rewritten to use it, or they'll be stuck with 2.1.10 which we don't 
want to maintain anymore.

However, the percentage of "rogue" clients (i.e. the one that are going 
to break due to the new install) is,
much smaller, and easier to spot if you have access to their sources 
(since simple grepping is sufficient)

Another option is to use a new API prefix internally, but provide 
backwards compatibility macros like:

#define  FT_New_Face     FT2_New_Face

so that clients can be recompiled without modifications. The macros 
*should* be disabled when building
the library, to that the corresponding object files only contain FT2_ 
functions. This will avoid any bad
ELF magic to happen (though it may make debugging fun :-)

However, this will *not* prevent programs from being linked to both 
libfreetype.so.6 and, say, libft2.so.1 or
wathever. Even though the probabilities of crashes will be reduced, it 
might produce unexpected results.

And it will *still* break rogue clients that are compiled against the 
new version. Which is why I'm wondering
if it will solve anything at all ? Sure, you can use your package 
manager to refuse to install libfreetype.so.6 and
libfreetype.so.7 together, but you won't be able to install 
libfreetype.so.7 until all rogue clients are patched
anyway.

In other words, the big deal are the rogue clients, not all programs 
that use FreeType. We need to spot these,
and provide patches before making a public release.

Another option is to have ./configure refuse to install freetype 2.2.0 
if a previous release of the library is
detected on the system; that is, unless you use a super-duper parameter 
like --please-destroy-my-desktop
that only the cautious will care to use.

Any comments ?

- David Turner
- The FreeType Project  (www.freetype.org)

>     Werner
>
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>
>   

***********************************************************************************
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 
message.
***********************************************************************************