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: address@hidden
[mailto:address@hidden On Behalf Of David Turner
Sent: Monday, April 13, 2009 4:02
PM
To: address@hidden
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