kicad-developers team mailing list archive

["Richard A Burton" <richardaburton@...>]

> 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.