| Thread Previous • Date Previous • Date Next • Thread Next |
Richard A Burton wrote:
Dick, I was looking at the todo list for something useful but simple that I could take a quick look at, and wondered about this one: "We should: 8 1) make a library out of ALL the xpm files, and 9 2) develop a simple header file which declares ALL of them using conventional C/C++: 10 extern char * somename2_xpm[]; 11 extern char * somename3_xpm[];" There certainly is some oddness and overlap in the way the bitmaps are handled. I was wondering if the answer to this might be to have a library, not just for the bitmaps, but for all the other common code. Obviously I'm thinking a shared one rather than a static one like we already have (common.a), a libkicad.so which all the applications could make use of. There are a number of places where the same code is compiled more than once, or linked into several binaries, just crying out to be refactored. Otherwise the bitmaps are currently already in common and it'd just be a matter of removing references to various individual header files throughout the rest of the code. Unless I'm missing something about the aim of this todo item. Either way I can have a look at this one, just don't want to miss the point of what you were after. Richard.
Richard,Before you get too far into it, verify that an *.xpm file can be compiled as a C++ file without the compiler complaining. You will have to dream up some command line options possibly.
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.
My comments in the todo.txt file seem pretty clear given this. But I will elaborate just a little:
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.
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. 3) Then we rely on the linker to pull out the bitmaps that are needed and put them into the program images. That means adding the bitmaps.a library to the linker spec for each program.
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. At some point we might use a shared object (DLL) approach to help implement some of the python support. An idea that I have used in the past is to put most (actually all) of the app into a DLL shared object, then the application program is a tiny binary that loads the shared object as its main goal in life. The shared object can then be called from some other language like Java or Python. I did this with Java. But there is no incentive in terms of space savings. Reason: the shared object files have to link in everything that might be used, whereas as static link links in only what is actually used.
HTH, Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
