Re: [ft-devel] Regarding Position-Independent-Code, modules, etc..
I've started doing PIC-related changes on my own branch, which I just uploaded to the git server under the branch name david-pic-changes for you to look. For all people who are not that acquainted with git: To check out this locally, please do git checkout -b david-pic-changes origin/david-pic-changes (assuming that you already have cloned the FreeType git repository). You can then switch forth and back between the `master' and `david-pic-changes' branches with git checkout master and git checkout david-pic-changes Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Regarding Position-Independent-Code, modules, etc..
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
[ft-devel] Regarding Position-Independent-Code, modules, etc..
Hello, just to let you know that I have recently tried to cleanup a bit the recent Position-Independent-Code that was contributed to the FreeType sources. While this works is really nice, I believe it represents a vast challenge in terms of maintanability for the people who don't care about PIC. Moreover, not all modules have been converted to PIC-compatible wrappers and deifnitions, and doing so is going to be very demanding. I've started doing PIC-related changes on my own branch, which I just uploaded to the git server under the branch name david-pic-changes for you to look. My initial idea was to use macros and a heavy dose of pre-processing to simplify and reduce the PIC-related declarations needed in the source code. However, even after modifying a few things, it's clear that the end result is not tremendously more maintanable. The code is definitely shorter, and easier to modify, but it is also harder to comprehend. It's essentially equivalent to what you can do with a set of crazy templates in C++, and of course it's also as difficult to debug when something isn't just right. For this reason, I think we should try something more drastic to scale this approach. I'm mainly thinking about using a custom pre-processing tool (e.g. a custom Python script), that would translate a very simple and human-readable high-level description of each module and the constant structures it requires, into equivalent C code that could be compiled in PIC or non-PIC mode. I'll try to post more about that when I have something working, but wanted to let you know, in case you have other ideas on the subject. Regards - David ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Regarding Position-Independent-Code, modules, etc..
Hello, just to let you know that I have recently tried to cleanup a bit the recent Position-Independent-Code that was contributed to the FreeType sources. While this works is really nice, I believe it represents a vast challenge in terms of maintanability for the people who don't care about PIC. Moreover, not all modules have been converted to PIC-compatible wrappers and deifnitions, and doing so is going to be very demanding. I've started doing PIC-related changes on my own branch, which I just uploaded to the git server under the branch name david-pic-changes for you to look. My initial idea was to use macros and a heavy dose of pre-processing to simplify and reduce the PIC-related declarations needed in the source code. However, even after modifying a few things, it's clear that the end result is not tremendously more maintanable. The code is definitely shorter, and easier to modify, but it is also harder to comprehend. It's essentially equivalent to what you can do with a set of crazy templates in C++, and of course it's also as difficult to debug when something isn't just right. For this reason, I think we should try something more drastic to scale this approach. I'm mainly thinking about using a custom pre-processing tool (e.g. a custom Python script), that would translate a very simple and human-readable high-level description of each module and the constant structures it requires, into equivalent C code that could be compiled in PIC or non-PIC mode. I'll try to post more about that when I have something working, probably in another server branch, but wanted to let you know, in case you have other ideas on the subject. Regards - David ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Regarding Position-Independent-Code, modules, etc..
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. 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. -- Dmitry. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
