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
