Hi,
I have to say that in my opinion it might be that the only way to have a clean
maintainable code is to avoid the two-mode code (having code that can be built
for both PIC and non-PIC).
Meaning, to change the code to always be PIC-compatible, this will produce a
small overhead on the current non-PIC library.
The code will have only very few macros, and none that can be defined in two
different ways.
All the structs with pointers to functions or other structs, will be moved to
the module instances, and the module/driver mechanism will change.
Waiting to see your suggested solution…
Oran.
From: [email protected]
[mailto:[email protected]] On Behalf Of
David Turner
Sent: Monday, April 13, 2009 4:02 PM
To: [email protected]
Subject: [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
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
