2009/4/14 Dmitry Timoshkov dmi...@codeweavers.com
Oran Agra o...@monfort.co.il wrote:
Waiting to see your suggested solution.
I'd once again suggest to stop making FreeType code ugly and force
broken platforms to upgrade their compiler toolchain instead.
Actually, I'm trying to make the code easier to maintain and comprehend.
There are already quite a few wacky things in the way we currently manage
modules/drivers/renderers/services, and we could certainly make the
internals
simpler and easier to manage in various ways.
Even the build system could be slightly improved to require much less
verbosity,
from a higher-level description of modules, their dependencies and other
stuff.
Especially since it's been stated that not all code was/will be
converted. There is no need to do the compiler/linker job in
the source code.
Yes, the PIC support is problematic because if we want to change internals
in a
significant way, we'll need to modify all these crazy macros as well.
Converting
the rest of the source code is a huge task, and I now don't think there is a
simple way
to do that simply relying on the C pre-processor.
I think that if we don't find a convenient meta-programming approach to
generate
the PIC support code, we should simply scratch it from the main branch. We
can
still put it in a separate branch for the people who depend on it, where
they'll be
free to update it and integrate mainline fixes as they see fit.
- David
--
Dmitry.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel