freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] endian issue in ftmac.c


From: mpsuzuki
Subject: Re: [ft-devel] endian issue in ftmac.c
Date: Thu, 22 Jun 2006 12:33:54 +0900

Hi,

Werner LEMBERG <address@hidden> wrote:
>> Attached is revised version that uses Endian.h macros
>> suggested by Mr. Sean McBride.
>
>If you don't mind I would like to put the responsibility for the Mac
>OS part into your hands.  Neither David (AFAIK) nor me are using a
>Mac, so please go on!

Thank you for steering, just I've committed the quick
workaround as temporal fix, now I've started to full
byte-order cleaning of ftmac.c.

BTW, considering previous posts about ftmac.c's dependency
with Carbon framework, I have a few questions about FreeType2
policy.

(1) freetype2.pc should include CFLAGS and LDFLAGS for ftmac.c?
---------------------------------------------------------------

At present, both files don't refrect LDFLAGS in configuration.
So, when freetype2 is configured on MacOS X to use ftmac.c
with Carbon framework, both of freetype-config and pkg-config
return CFLAGS & LDFLAGS without options to use ftmac.c.

Therefore, when package builders make some MacOS X software
which is dependent with FreeType2, they have to be careful
whether their prebuilt-FreeType2 is Carbon dependent or Carbon
independent.

In the case of MacOS X developer community, I think, the number
of developers who build "./configure && make", as just same with
common UNIX, is not negligible. In fact, freetype-config and
freetype2.pc are introduced to avoid the manual management of
configuration options.

I suppose, the reason why freetype-config and freetype2.pc
don't include CFLAGS and LDFLAGS is to drop unexpected options
like optimization, uninstalled libary linking etc. So,
now I'm thinking of import ftmac.c-specific CFLAGS & LDFLAGS
to freetype-config & freetype2.pc. How do you think of?

(2) dummy functions for ftmac.c are required?
---------------------------------------------

Considering the binary compatibility when ftmac-enabled FreeType2
is replaced by ftmac-disabled FreeType2 on MacOS X, adding dummy
functions returning just FT_Err_Unimplemented is expected to avoid
problem by unresolvable symbols?

However, rather I hesitate to add new functions even if they are
portable dummy.

Regards,
mpsuzuki




reply via email to

[Prev in Thread] Current Thread [Next in Thread]