How to run interface kit tests (for libbe.so)

Development OS
1

It occured to me that I’ve not seen this documented, so I thought i might write a small topic about this.

The first step is to compile your modified libbe.so in your haiku repo, for jam one can just name the target. The -j4 are the number of processors. you can adjust this in your case.

~/proj/haiku: jam -j4 libbe.so

The second part is compiling the tests.

~/proj/haiku: cd src/tests/kits/interface/
~/proj/haiku/src/tests/kits/interface: jam -j4

Some tests will probably fail to compile here. This is to be expected as they are seldomly used for testing!
If this happens either ignore it, or roll up your sleeves and fix it. :slight_smile:

Now that you have compiled your tests you can run them. But care has to be taken to run it with the correct libbe.so, the one you just compiled

To do this one can either use the LIBRARY_PATH variable, and prepend a folder with the libbe.so in it. Or in this case I will use LD_PRELOAD, this is a variable with which we can specify a library that the dynamic linker should load before it checks the LIBRARY_PATH.

First we have to go to where the finished tests are moved by the buildsystem:

~/proj/haiku: cd generated/objects/haiku/x86_64/release/

For my machine this is x86_64, but on a older 32bit system this would be different (or on a riscV or arm system)

The next path depends on wether you have compiled the tests in debug mode or in release mode, the default is the release mode, so we will go there.

~/proj/haiku/generated/objects/haiku/x86_64: cd release/tests/

And then into the folder for the interface tests (or other tests if you prefer)

~/proj/haiku/generated/objects/haiku/x86_64/release/tests: cd kits/interface/

Now we need to prepend the enviroment variable to the command we wish to execute, eithe export this to the enviroment or write it before every command

To export it you would do this:

export LD_PRELOAD=../../../kits/libbe.so

Or alternatively just write it before the commands:

~/proj/haiku/generated/objects/haiku/x86_64/release/tests/kits/interface: LD_PRELOAD=../../../kits/libbe.so layout/widget_layout_test/WidgetLayoutTest BTextControl

The test used here is a bit more complex, but this should work similarily for other layout kit tests, or other tests in general.

I hope this has been somewhat informative, maybe it was too verbose? let me know what you think.

Regards

3 Likes
2

Useful post, thanks.

There’s a typo here

I know there’s another way to load a specific library, i.e. putting it into a lib folder beside the executable. Does it work with libbe.so? I’ve never managed to use a version of it build with debug info.

3

Yes, this should work. If you check LIBRARY_PATH, you wil see this is that mechanism.

~/proj/haiku: echo $LIBRARY_PATH
%A/lib:/boot/home/config/non-packaged/lib:/boot/home/config/lib:/boot/system/non-packaged/lib:/boot/system/lib

The %A here means “location of the executable”. So %A/lib is the lib/ dir next to the executable that you are used to.

(I’ve for example have replaced system libraries with newer versions in ~/config/non-packaged/lib on ocasion)

Loading a debug symbol libbe.so should work. If you try to do this with LD_PRELOAD and run the application you wish, what does the output of listimage say? Does it list the path of your custom build libbe.so or the one in /system?

4

It loads the alternate version when libbe.so is inside the lib folder but the Debugger does not show the libbe C++ code. So it must be something with the way my libbe is built.
Nevertheless, it’s worth mentioning this third method as well.

5

It is already mentioned in the original post. Does your build libbe.so show up in listimage for the image of your test application? if yes then something else is wrong (and potentially a bug to be filed)

6

Sorry, I’m confused. I can spot only two methods:
1.

I don’t see the third one, that is putting a lib folder with libbe.so in it beside the executable.
Or am I shortsighted? :smile:

7

It does, therefore I suppose there must be something else occurring.

8

putting it into lib/ is the same method as using LIBRARY_PATH, it is one of severall folders that are in the variable per default. If you clear this variable or write something else into it the lib/ folder is no longer used.

By default this var also includes non-packaged/lib in both config and the /system variant.

In any case, stuffing libraries next to executables in the lib/ folder relative to the exectutable is not practical for the exercise here since the tests are spread out over severall folders. Properly adjusting the LIBRARY_PATH to specify a specific folder would be the equivalent practical solution.

1 Like
9

Why not compile UnitTester and use that to run the tests?

10

I’ve not used that before. Looking at old blog posts this seems to be intended to run unit tests? Not something I needed in the past.

11

Well, at least some of the Interface Kit tests are real unit tests wired into the unit testing framework. But I suppose the “widget layout test” isn’t.

12

Alright, It is a good point however. I will check it out. Thanks