The bitmaps are not in the common.a library that I can see. Instead
they get built into a C++ source file by including a header file that
has code generating qualities to it. That is, the header file
essentially contains the bitmap generating C++ code. See file
include/bitmaps.h which includes a ton of C++ code in the form of *.xpm
files.
Actually it's a mixture of these.
bitmaps.h includes most of the xpm files, without having defined
XPMMAIN. All the xpm files contain #ifdefs so that when included
without XPMMAIN they give the externs. This file is then included by
many source files that use bitmaps to pick up those externs. Then
bitmaps.cpp defines XPMMAIN and includes bitmaps.h which results in
pulling in the actual bitmaps from the xpms into bitmaps.cpp. So they
do end up included in common.a
Some files do include individual xpm files rather than bitmaps.h. This
should probably be tidied. Get rid of this duplication. Move any items
that are in individual bitmaps folders to the main one, and include
them in bitmaps.h. That way it's all in a single place. One folder for
all the bitmaps. One include file for all bitmap externs. One cpp file
for all bitmaps (that ends up part of common.a).
1) bitmaps.h would simply list the externs only, as I stated. This
could be split into multiple files if needed, but I see no reason to do
so. The advantages of keeping one file: one place to look for
bitmaps, and it ensures that the char arrays generated by the bitmap
pixel code are all uniquely named in the C++ global namespace.
As above, this is what currently happens, but not all source files are using it.
2) there would be a single new CMakeLists.txt file for the bitmaps, even
though there are bitmaps in about 6 different child directories. I
would lean towards a single CMakeLists.txt file for this, since you are
building a single new static library, say bitmaps.a. You would have
to code longer paths to point to all these child directory *.xpm files.
As they are currently in common.a it's probably easier to leave them
there. As things stand, and if tidied as suggested above, to add a
bitmap only means adding a single line to the bitmaps.h. If you put
the files in an extra library you also have to update headers and
cmake each time you add a bitmap.
I would not spend any time right now on building a shared object
library. There is not enough incentive in terms of code space savings
to justify this.
Fair enough.
Richard.
------------------------------------
Yahoo! Groups Links
