First a small remark for planetkde readers, this post is not in particular about KDE, but I believe it is an interesting read for the developers among the readers. This post is about language tools for C++ and in particular … Continue reading
The usual thing, long time no blogging. Well, real life got a good deal in the way. Not for bad though. While I did my MSc. thesis at KDAB I got the possibility to start an Ph. D. position on information visualization at ILOG (now part of IBM) in Paris. This meant packing our stuff from our Berlin apartment (not too much luckily as we rented furnished) and moving it back to the Netherlands at first. Then using the next couple of months to sort out and pack our remaining stuff which we didn’t take to Berlin and find an apartment in Paris. As you probably can imagine, this was slightly stress-full, but I’m pleased to say that we are finally settled now. We have a nice apartment south of Paris, only a 20 min walk from the office I work and we have Internet access again The only thing we don’t have yet is the ability to understand french…. Well, lets see if that changes over time.
What triggered me to write this blog was something different though. First a note of warning, I didn’t do any other research than presented in the remaining of this writing. My former colleague Marc wrote two great articles (here and here) on the topic of d-pointers. Its in German, though it shouldn’t be too hard to read if you’re somewhat familiar with the topic and German. One topic he doesn’t address though (or I skimmed too fast now, it was some time ago I really read them) is the performance of d-pointer classes versus value classes. Recently I was writing a class which has the potency of getting created a lot and often which triggered the question where and how much the cost difference would be. We all know that creating objects on the heap is more expensive than creating them on the stack, so I quickly deduced from this that d-pointer classes must be more expensive. Okay, that shouldn’t have come as too much of a surprise. Two questions remain though, what is the price one pays and where (e.g. creation, copy, access).
Intrigued by these questions I set up a real quick and dirty benchmark just to get some rough ideas. By no means I pretend to be complete and given that I’m quite tired I might have made some horrible mistakes as well. So feel free to comment on the results. Here’s what I did: I created three different classes: DPointerClass, ValueClass and InlineValueClass (the latter just for additional comparison). The classes are very simple, they just hold an int which you can get (const access) and set (non-const access). Complete source can be found here. Next I created a test class using QTest lib with the following methods:
In these methods I use the QBENCHMARK macro to benchmark the actions described by the test names (using walltime). This leaded to the following results:
In this image you see the number iterations for each action. To be honest, when seeing that graph I’m not completely sure how to interpret it. As I understand from the QTest doc, for walltime a higher number of iterations might be needed to get more precise results. However, what more precise results mean is not clear to me and neither why there is such a big variation in the number of iterations per tests for the individual classes as well as between all tests. (E.g. for value it is high for the CreateDestruct test, low for HeapCreateDestruct and again high for Copy). Well I guess the second issue is closely related to the first one so if anyone could enlighten me on that It’d be great.
Secondly, and slightly more interesting is the following graph:
Here you see the time (in msec) it took per iteration. We can directly conclude that for creation/destruction and copying the difference is significant. For assignment and the access operations the difference is negligible. So the extra step of indirection doesn’t seem to add, more strangely it seems to be slightly faster even. The factors between DPointer and Value for CreateDestruct, HeapCreateDestruct and Copy are respectively 42, 20 and 12 20, 42 and 12.
Concluding we can say that only for CreateDestruct, HeapCreateDestruct and Copy the differences are significant. For creation this is logical, for copying I assume that the byte-by-byte copying from the default constructors are performing slightly better than custom ones. For assignment and access there is no performance loss. One last question remains, although the difference is significant even in the worst case we’re talking about 0.0012 msec. How does one determine whether this is too much for his application and thus fall back to creating classes with private members? The class I’m working on has the potention of getting created in large amounts in short time (e.g. 100.000 several times in a number of consecutive calls) I’m somewhat tempted at the moment to move away from value classes to d-pointer classes for the obvious design reasons as the class will become part of a library. Any comments and thoughts on this are welcome. Continue reading
Lies, damned lies…and statistics. In KDE we have several means to guarantee the quality of our code base. These means include unit testing, continuous building on several platforms, policies on various levels and krazy2. What we fail to do in my opinion is to give insight in how these measures actually affect the KDE SC. That is, we do not have a high level overview on how these measures develop over time. Of course, not all measures taken are quantifiable but some of them are. Take for example unit tests, it would be nice to see at various levels the number of tests, the number of performed test and the success ratio for each release. Giving insight in these kind of numbers, again in my opinion, can be a good argument in conversations on high level (e.g. convince someone of deploying KDE SC or convincing someone of basing his software on the KDE SC stack). Of course this only works when the numbers are convincing.
For this reason (and also because I have a fetish for numbers) I started to extend the architecture of krazy2 in order to be able to extract quality related information of our code base. The first step to achieve this was to add XML output support to krazy2. This made the tool set a bit more flexible. The next step was to add support for sloccount to krazy2. The raw number of issues is relatively useless for comparison over various releases as this is only meaningful in relation to the lines of code of both releases. Krazy2ebn was replaced by krazy2xml which generates a set of XML files on component/module/submodule level. A set of XSLT style sheets transforms these files to HTML for the ebn website. Additionally I wrote a small tool which parse these XML files and put the result in a database (currently there is support for sqlite and postgres). Up to this level the tools are currently in a reasonable shape. So the numbers are there, but how do we give insight in these numbers? The EBN site had some statistics but these where really marginal. As I’m lacking both SQL and PHP skills I had no good idea on to do this, until a prof. of mine pointed me to IBM’s manyeyes. This site lets you upload a dataset in a simple plain text format and than provides you with various ways to create visualizations for the uploaded datasets. So another tool added to the chain, db2maneyeyes. Look at the source if you’re not convinced about my lack of SQL skills, ooh well we don’t really care about performance anyway in this context. Its not finished yet, that is I’d like to add some more export functions but the first results are there.
So, the lies^Wstatistics. I created a topic center on manyeyes for KDE SC related statistics. You’ll need a Java enabled browser for interactive browsing of the data. It does not contain many datasets yet but that will change the next weeks. Most datasets currently there, show how the SLOC evolved over time on various levels for the KDE4 life cycle. Some random facts related to SLOC:
Well, all of this you can see yourself in the various visualizations I created. This of course does not say much about the actual quality. Here I still have some work to do but the first data is there. Number of issues vs. lines of code on component level. If you select in this graph both the number of issues and the ratio we notice two things:
Conclusions: The number of issues (as said before) in itself is not a useful measure. We (as a community) do seem to care about the issues reported by krazy2 and actually fix them, or at least make sure that new code has fewer or no issues.
Final remark, how useful the checks performed by krazy2 are is a different discussion. I definitely would not suggest that these numbers show that the overall quality of KDE SC is improving. For that we would need similar statistics from different quality measures we have. Anyway, it’s a start in giving insight in these statistics. If you’re interested in this topic, want krazy2 stats at a specific level or have ideas for improvements please find me in #ebn on freenode.
And finally:
And
Thanks, Adriaan for providing this wonderful graphic! Continue reading
Its the time of the year again, spring. Meaning, time for the big clean up. Not the house of course, we leave that to the people feeling themselves called to clean houses. I’m talking about code. Over time we, as in developers, come to the conclusion that this neat API we wrote is not as neat as it looked in the first place. So we redesign our API and BIC lovers as we are, mark methods that should not be used anymore as deprecated.
This is of course very nice, but how do we actually get an overview of the methods that are marked as deprecated, more important how do we get an overview of how often deprecated methods are still in use? Well, kdevcpptools to the rescue. As I blogged before I worked on a C++ query and transformation engine for KDevelop as part of my Msc thesis. After an awesome lot of stabilization work of Milian "code monkey" Wolf, the plugin really is in quite a nice state at the moment and I would say quite usable. In the rest of this post I’ll show how to use it by taking kdepimlibs as an example.
The first thing to do is to create a query file containing the queries for the deprecated functions. The query (and transformation) file is a relative simple XML file describing the queries and optionally transformations. There are some example files in the git repository, but don’t jump to that yet as I want to show a cool feature Milian implemented. Lets find the deprecated functions first. Okay, no fancy tools for that (yet?), so just a plain ack-grep on "KDE_DEPRECATED" in kdepimlibs. This gives me a lot of files containing this macro. We startup KDevelop and create a new empty query file with the following content:
?xml version="1.0" encoding="UTF-8"?
porting-description
queries
/queries
/porting-description
(Yes, the formatting sucks, don’t know how to make drupal output XML in a sane way). Next, open one of the files that showed up in the results of your grep and go to one of the deprecated functions. Make sure that you have the kdevcpptools tool view enabled and right click the function. The context menu shows you this wonderful option: Copy XML query:
Copy the resulting XML from the clipboard into your file and there you go, its that easy. I did this for whole kdepimlibs, you can find the file here. First observations: we’ve 47 deprecated functions in whole kdepimlibs and we really have a shitload of date string formatting functions in kdepimlibs, so…. if you need one…..
When you’re done putting in your queries in there, you can open the XML file in the kdevcpptools plugin. This enables you to query a project. I did this for kdepim, meaning, the result I get are all uses of deprecated functions from kdepimlibs in kdepim. This result was so to say pleasantly surprising. Have a look at the next picture:
In the lower part of the screen you see an overview of the results for kdepim. Vertical axis are files horizontal axis are queries. First observation here: there are surprisingly few uses of deprecated functions. (Note: we’re only talking here about functions, explicitly marked as deprecated). Second observation: though not particularly interesting for such few results, the curve you see in the total column looks promising. I.e. most uses in only a small part of the files. Meaning, only a couple of files need "major" changes. This must of course be seen in perspective, this reasoning is not particular interesting when you only have seven hits for a ~700KLOC code base. Would you had have a similar curve for ~8000 uses this would of course already make a lot more sense. The curve in the total column will actually tell you how the migration work is distributed over the code base you’re querying.
So, my initial idea was to do a bit of clean up in kdepim but it turned out that this is hardly needed with respect to this specific area. The good thing is that we now know that it isn’t needed. This means that as soon as KDE5 development kicks off we can get rid of these deprecated methods without a lot of work (in kdepim at least). I’d really encourage anyone interested in these kind of analysis on his/her code base, either from a lib perspective like I did, or from an application perspective (anyone interested in building up a query file for qt3support and query the various kde modules for it?) to checkout the plugin[1] and play with it. You can find me and Milian in KDevelop if you need help on getting started with the plugin.
Next step is using the transformation engine to do (at least part of) the migration work automatically. I hope to blog about that soon. But first a thesis to finish…..
[1] http://gitorious.org/kdevcpptools Continue reading
(Warning: long post coming up. Read on if you are interested in performance of the various Akonadi database back ends).
Last weeks I’ve been looking (again) whether or not it was possible to create a working sqlite back end for Akonadi. The last time I tried was around august last year and by then sqlite just wasn’t able to meet the multi-threading requirements that Akonadi has for its database back ends. A couple of sqlite releases later things seem to have changed. I managed to clean up some problematic code paths in Akonadi server and voila, we’ve a sqlite back end that is on par (unit test wise) with the mysql back end.
There are some catches of course. The first being that the default sqlite driver that comes with Qt does not work. It uses the sqlite API in a non-blocking way. So I had to adjust that to make the driver consistent with the sqlite documentation which states that when sqlite calls return BUSY, you have to wait a bit and try again. This custom driver can be found in kdesupport/akonadi/qsqlite.
The next catch is related to performance. Though we did not had the numbers until now, it was expected that sqlite would perform worse compared to mysql. Given that we have another back end, postgresql and are working on yet another one: a file system back end, it seemed a good time to do some benchmarking. So I brushed up the item benchmark a bit and performed the benchmark for all back ends. The benchmark tests the performance of Akonadi over two dimensions. The first dimension is the number of items and the second dimension the size of the payloads. We used the Qt data driven test framework and added rows to it like: ${number-of-items}-${payload-size}. Then we benchmark the important actions of Akonadi, which are creation, modification, fetching and deletion of items. This enables us to see how the performance scales with the two dimensions.
Before getting to the results I first have to make a note about the file system back end. This one is designed to be a fall-back for large payloads. The idea is that database actions become too slow for large payloads. So at a certain offset Akonadi doesn’t store payloads in the database but in plain files. The benchmark for the file system back end is set up to always write the payload to the file system. This enables us to find out the offset that gives best of two worlds, i.e. fast performance for small payloads by using the database and fast performance for large files by using the file back end. (Note: currently the file system back end is disabled by default, there still are some issues with it that need to be sorted out).
Sooooo, show me the numbers, I hear you thinking. Well, here you go, lets start with item creation:
The image show the results scaled logarithmic on the x-axis (time on y-axis, but relative due to logarithmic scaling on x-axis). As you can see the, the files system back end (akonadi-fs) is hardly influenced by the file size, only by the number of items. For the other back ends we see that file size has influence on the performance too, but roughly scale linear. We also see here that sqlite does not perform as well as the others. Lets have a look at the absolute numbers:
The y-axis now shows time in msecs. The graph now shows us clearly that when items get larger and the number of items grows too, sqlite is clearly outperformed by all other back ends. We also see that databases in general don’t cope well with large payloads, which is exactly the reason to provide a file system back end too. First conclusion, don’t use sqlite unless you have very strong restrictions on your environment. (Which is the case when running Akonadi on Windows CE for example, where the number of processes is extremely limited and which we are working on here at KDAB). Still not convinced about sqlite performance? Okay, lets have a look at one more. Item modification:
Again, we see that sqlite is outperformed by all other back ends as soon as the payload size becomes large. When the payload size grows we also see that only the file system back end doesn’t start to grow exponentially like the database back ends do. So, sqlite works, might even work fast enough for you, but is definitely not fast enough for the general use case Akonadi was designed for in the first place: handle many large items. Again, unless you have very strict requirments on the environment where Akonadi is used.
The last thing I want to show is a benchmark with different payload sizes for 2500 items. This makes it easier to find the cutoff value for the file system back end. I.e. what payload size should be used to store an item using the file system back end in stead of the database? First the images (I only compared mysql and fs to have slightly clearer graphs, you can find the full results at the links posted at the end of the blog):
For creation and modification the cutoff value seems to 8 KB. However, fetching, which is also an often performed operation, has a cutoff value of 512B. A good trade-off between those two is probably around 4 KB.
So that’s all for now. Short recap. The sqlite back end for Akonadi seems to work, though its about ~5 times slower. Also, there are already some problems reported, so it still should be considered as a work in progress. Work on the file system back end is ongoing but seems promissing and with the right offset and file system/database combination (i.e. mysql) we get best of both worlds. Thanks for reading!
Links to the full (interactive) results:
Update: For a better comparison between database and fs back ends I added another benchmark which also uses 2500 items but only goes up to 8 KB payloads. Check the results here:
2500 items, multiple size, only up to 8K
[1] The title is meant to be a pun. Every now and than people pop up on the ML who think that sqlite is not a *full blown* (whatever they mean with that) database. Let me ensure you, it is. It supports SQL at a similar level as mysql, it does transactions and multithreading, it just tends to be smaller (and here I mean the library itself, not the database) and it does not run in a seperate process but it therefore has its limitations too. Continue reading
There seems to be lot of interests in slimming down all kind of libraries lately. Anyone trying to bring his great application or framework to a mobile platform maybe? For other reasons I was interested in the information passed to compilers and figured that having this information available can of course also be used to write tool to analyze dependencies. Given that I’m writing my thesis currently and need a bit of distraction every now and than I started working such a tool. By the way, it was a nice opportunity to play a bit with the Boost Graph Libraries. So, without further ado I present: C++ Dependency Analyzer.
The tool reads a file with compile commands and creates a dependency graph of it. Yes, I am aware that CMake can create a dependency graph but that one is limited. Also, for other reasons I’m interested in other information you can get from a build too, but well that’s long term. Anyways, a graph of a complete project (e.g. kdepim) in itself is not very useful because its huge and cluttered. Therefore I started working filtering options. In the image you see the subgraph of kdesupport containing only the dependencies of akonadiserver. All this is in a very early state. However, colleagues of mine put heavy pressure on me to stop working on my thesis and make it available. Thanks Volker, Keven!
So, if you’re sure you want to play with it:
git clone git://gitorious.org/cpp-dependency-analyzer/cpp-dependency-analyzer.git
As said, the whole thing is in very early stages. The UI you see for filtering is *only* functional for the targets part of it. That is, you can double click a target in the tree and update the graph. This will give you the dependencies for the selected targets only. The rest of the filtering is only UI. The current level of filtering is hard coded to leave out any source files and any object files, though both are part of the underlying graph.
The actual information comes from a file which contains lines existing of: the current working directory and the arguments passed to the compiler. I only wrote a parser for g++ and tested it only with g++ 4. It has been used already to create the graphs for kdesupport and kdepim though.
It is really slow for large graphs.
Some ideas to make you work on this application…. eh to document what I’d like to add to the application somewhere in the near future.
I hope to find some time to make the filtering a bit more complete. I already started working on the ui for it, but it still needs to get integrated in the graph logic. Especially useful would be to add duplicate edge filtering, because duplicate edges really clutter the graph at the moment.
A wrapper which stores the same information in an unborked way when using multiple compile jobs would be nice too, to reduce the time needed to generate graphs. However, this is a low priority thing for me.
Exporting graphs to svg would be nice too. This should be trivial, thus boring, thus don’t expect it too soon.
I’m quite convinced that this application has a great potential for maintenance and packaging purposes. But again (I can’t repeat it enough I guess) its in a very premature state at the moment. Expect failures, crashes, your cat eaten and who knows what more which you will have to solve yourself. Add to that that I’m very limited in time currently so feature requests will only be accepted in the form of patches.
Last but not least I’d like to thank our stl and boost guru Marc Mutz for helping me to get started with BGL! Continue reading
Every once in a while software needs to be ported. This seems to be more a rule than an exception. New versions of libraries are released, libraries are not maintained anymore or newer libraries outperforming the one currently used appear. So, there you’re sitting as a developer staring at the (potential huge) task lying in front of you.
Or imagine you’re the author of a library yourself. How do you determine how to split up your library in logical modules? Or where do you start when you want to optimize your library, given a couple of projects using your library?
These two scenarios are closely related to the research I do for my master thesis at KDAB. When doing work as described above, one would like to have tools that help him to estimate the work and where possible, to automate the work. For Java lots of tools are available for C++ however, it is a totally different ball game. Well, I guess most of you know why, parsing and analyzing C++ is, well, kind of difficult. There are good proprietary tools available, but part of my assignment was too evaluate how well a FOSS tool would do.
For several reasons, which I won’t outline here I chose to work with the KDevelop parser. It doesn’t do a full semantical analysis and unfortunately it doesn’t store all info I need during analysis but it gave me a descent starting point. The idea was to build a C++ query engine (i.e. find uses of type X, find uses of method X::y(), etc) and a transform engine (i.e. given an use of X::y(), transform it into foo<X>()). As said before, KDevelop doesn’t store all information needed to do a fully correct transformation but some useful transforms can already be done (more on that in another blog).
So, given a C++ query engine, a partly correct working transform engine and a (huge) porting job, what would we like to know and what can the plugin currently show? We start with putting in some queries which we can’t port (or even find) with our current scripts. We load the queries and run it on the project we want to port. First results:
In the tree you see an item for each file with as children results of the different queries run on the projects code base. Double clicking will bring you to the location in the editor. When a transform is defined for the query, selecting a query will enable the transform button and when transforms are applied you can view a diff. But well, as said the transform engine is a bit in a poor state still. However, at first we’re not directly interested in applying the transform. Remember, the customer didn’t sign any contract yet =;). So how do we know what to put in the contract in the first place? Lets enter the project view:
Here you see a more aggregated view of the results of the queries that where run. On the left side you see the files for which queries are run. On top you see which queries where run. Each cell contains the number of hits for a query in a file. Except for the first which shows the total of the row. Of course the results can be sorted for each separate column. So what can we learn from this picture? The first thing that is noticeable, when sorting on total is that the curve is broad at the top and getting narrow quite fast. Which means, given that the queries represent the amount of work to do, that most of the work has to be done in only a couple of files. Now, what kind of work do we need to do mostly? Lets sort by one of the queries:
Hey, that curve there on the right seems to correlate with the total curve. Hmm, so most work is due to query X. Aaaah, we know that this particular piece of code is [very easy|hard|very painful] to port so we need to bill our customer [a bit|a lot|an insane amount]. (But of course relative to the amount of file which are affected =;) ).
Up to now we’ve had the files as rows but it is also possible to switch the headers, which of course also changes the meaning of the image. Lets see:
Now we have the queries on the right and sorting on total gives you an overview which type/function/other construct is used most in the project you’re analyzing. Doing this for several projects using the library you’re maintaining/developing can help you in finding out which parts of your library you should optimize first, what the impact would be of changing the signature of that particular function or how to split up your library in modules when it gets too large.
Next thing I’ll be working on is visualizing the impact of transforms on the code base. Especially to show which parts of the documents are modified by the defined transform and if there are overlapping transforms. More on that later.
I didn’t release the code yet as its far from mature yet. However, if you feel brave and want to play with it, drop me a mail and I’ll send you the source. It will eventually become available under some free license (I should’ve read [ade] blogs better, I would have known which).
P.S. For who wants to know, these kind of views are called Table Lens views which are very powerfulf for finding trends. Continue reading
About two weeks ago I added the postfixop check to krazy. This checks for postfix uses of ++/– usage. Initially I constrained the check to for-loops. However this lead to a huge amount of issues because also postfix usage of ++/– operators on simple types where marked as an issue. After some discussion with Eckhart Woerner and Allen Winterz I relaxed the check more so that usage on simple types is also not taken in account anymore.
Although postfix usage on simple types won’t gain you any/much I still think it’s a good thing to consequently use prefix wherever appropriate. However that has more a cosmetic reason (which I why I took it out actually) then a perfomance reason. Consider for example the next piece of code (and yes I’ve seen something like this somewhere in the KDE codebase):
QList::Iterator it = list.begin();
for( int i = someNumber(); it != list.end(); ++it, i++ )
{
...
}
I realize that it’s partly a matter of taste if you like this kind of code snippets in your code base or not. However for people who never have had some in depth programming course it might look like if it is arbitrary what you choose.
Another thing I’ve been thinking about last weeks is "What is the importance of cosmetic changes in relation to code quality". When browsing through the source of KMail while fixing issues reported by krazy I see a lot of things which make me cry. For example defining variables which are used only ~25 lines later or in 3 different context. These kind of things make my fingers itch to rewrite such parts. Well, don’t be scared, I didn’t….. if it ain’t broken don’t fix it, right? But I still can’t find a good answer on the question: is that sort of code broken? In some sense it is in my opinion. When I as a newcomer to the KMail code look into some sections I really have to read that twice or sometimes even more times to get some vague idea what is happening over there. I think that is something that can be avoided (to some extend of course, as not everything in life is as easy as we would like it to be). All this made me think that it would be a nice to have something in addition to the normal krazy checks which checks for situations where some cosmetic change might improve the readability (and therefore the quality?) of the code.
Well, leave me a comment if you have some noteworthy ideas about these topics.
p.s. KMail only served as example here, I guess there are more places which have similar issues. It’s just that I was browsing through KMails code while these thoughts came up. Continue reading
Study has started again, which means that my attention is (slowly) shifting from KDE hacking to all kind of study related things. Which is not that bad as I have some quite interesting courses (information security, advanced c++ programming and computer vision). Normally this means for me that I don’t have time (but more, no energy) to do very much KDE hacking. However I found some task which can be done relative easily in between. Bringing down EBN issues. I have worked out a lot of issues in KPilot already and currently I’m giving a stab at KMail.
While it might seem very dull, which it is in some sense, it is also very satisfying. Not in the first place to see the numbers going down on EBN itself 
. But when working on the issues you also see code transforming, becoming more uniform and in some cases more readable. I don’t know what it is but I just enjoy seeing beautiful code. (Might be due to the book Google send me this summer, and by hanging out too much with [ade] in the past).
One of the things I noted in KMail (but I’ve seen this also in KPilot) is a quite inconsistent use of header inclusion. This happens in two areas. The first is that in some header files no forward declarations are used even when that is possible (when only pointers or references of that type are declared).
So
#include <QtModule/QClass>
class MyClass {
...
QCLass *mVariable;
....
void method( const QClass& c );
...
}
The second thing is that the include lists are a real mess in some files. Sometimes even k includes and Q includes are mixed up. What I would like to see is having a preferred order for includes in each file. Let’s say: own headers, project headers, k headers, q headers and other headers. And the next thing I’d like to see would be to have the includes sorted alphabetically. These are in fact relatively small changes but I think most of the headers and cpp files can be designed to look that way. This really would make it easier for (new) developers to see in a glance which classes/methods are actually used and also to see if the class he wants to used is included already. Another little annoyance I did see was mixing up (between files): #include KMyClass and #include "kmyclass.h". I guess most of these things are not new for the readers of my blog and still we (including myself) make really a mess of things so now and then =:).
This wasn’t meant as some rant on the kmail coding style or something. Just wanted to share some thought about this in general. Please let me know if you have some useful comment on this subject. Currently there is unfortunately not a check for unneeded includes in headers in krazy, but this would be very nice. If you have perl skills please give winterz a hand on this. p.s. Even this can snoop a lot of time which should be spend on my study =:S. p.p.s. If you find issues in KMail due to EBN Fixes I did, please drop me a mail at: [b DOT broeksema AT home DOT nl] and I’ll try to fix or revert the change if necessary. p.p.p.s. The line edits in KMail will soon have that cool clear button…. Continue reading
I finally tried out what I wanted to try for some time now. The problem (if you can call it a problem) I had is that one of the libs I worked on for my GSoC contained class that I wanted to test but that I did not want to expose to the rest of the world. As I did not have the time nor the knowledge to make that happen I just exported the classes so that the testcode could link against it.
Well that changed today and I took some time to figure this out. (Note: I’m not an expert on C++, libraries and such so if I do stupid things here, let me know). In the KPilot code we have an KPILOT_EXPORT define which looks like this:
#include <kdemacros.h>
#ifndef KPILOT_EXPORT
# if defined(MAKE_KPILOT_LIB)
/* We are building this library */
# define KPILOT_EXPORT KDE_EXPORT
# else
/* We are using this library */
# define KPILOT_EXPORT KDE_IMPORT
# endif
#endif
The way I understand this snippet is that it makes the symbol that is prefixed with it visible anyhow. But what I wanted is that the symbol is only exported when the tests are enabled. Therefore I added another define which looks like this:
#ifndef KPILOT_TEST_EXPORT
# if defined(HAVE_TESTS_ENABLED)
# define KPILOT_TEST_EXPORT KDE_EXPORT
# else
# define KPILOT_TEST_EXPORT KDE_NO_EXPORT
# endif
#endif
To make this work I added this to the CMakeLists.txt file:
string(COMPARE EQUAL ${KDE4_BUILD_TESTS} "ON" buildtests)
macro_bool_to_01(buildtests HAVE_TESTS_ENABLED)
configure_file(config-kpilot.h.cmake ${CMAKE_CURRENT_BINARY_DIR}/config-kpilot.h )
And the config-kpilot.h.cmake file got a line added that looks like:
#cmakedefine HAVE_TESTS_ENABLED
Now I can use:
class KPILOT_TEST_EXPORT IDMapperXmlSource
{
....
};
and the given class gets only global in the library when testing is enabled. I wondered why there is no such export in kdemacros.h as I found this quite a nice solution. The library won’t export symbols in release mode, which is a bit cleaner than just exporting everyting only to be able to test imo. But as said, I’m only a novice on this kind of things =:). This whole thing made wondering if there is some GUI tool to explore libraries. Continue reading