incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <>
Subject Re: Project structure
Date Sun, 24 Jun 2012 20:02:38 GMT
> nice work! I tested it on my Ubuntu 12.04 64bit machine and just found one
> small glitch in the build system so far:
> Starting with a clean build tree and enabling BUILD_EXAMPLES and
> BUILD_SHELL leads to a linker error:
> Switching on BUILD_DEPENDENCY_MANAGER obviously solves the issue.

This is because the examples doesn't list the dependency manager as a
dependency. I guess I missed that one.
Simply updating the "celix_subproject" to include the dependency_manager as
a dependency (DEPS) should be enough.

> Not build system related, but I cannot figure out how to run the
> examples... the website "Building and Running" says that a configuration
> file is created by the build system, but I cannot find it. And how could I
> start the OSGi shell and install bundles from there?

The website is out-of-date with these changes. I'll try to get some time
and update it tomorrow.
To build and run the examples:
Run "make deploy"
This takes care of building the libraries/bundles, as well as copying the
bundles to a deploy target (the "deploy" macro used in eg target.cmake in
the examples directory).

The targets are deployed in the directory in which the deploy macro is
used, so for the examples this is in the "{build}/examples/deploy/{target}".
In the target directory there is a "bundles" directory, a
"" and a "" script.
Simple running the script (sh should be enough to start the
example. Most targets have the shell deployed by default.

The following shell commands are available:
- start/stop/update
- install/uninstall
- ps and inspect

The command names are taken from the Felix Shell (old style), but not all
are implemented completely (eg the inspect command only support "inspect
service capability" with an optional bundle id).

> Also, running "make test" segfaults when executing "array_list_test":
> I'll have to check this out, I've got a local branch with some
changes/fixes to the tests. In these branch I use CppUTest, this library
also has support for mocking, and while it is written in CPP, it works
rather well.

> Is there a reason to not use CTest, which ships with CMake?

I really dislike CTest's behaviour of only having the possibility of one
test in an executable (better said, one result).
Also since CTest is only a wrapper to starting test, and not a test
framework like CUnit etc, there is still a need for additional libraries
with assertions etc. Since CUnit etc all support test-suites (multiple test
results in one executable), I prefer those over CTest.
Another problem with CTest is reporting. With CTest it is only possible to
create some reports using the VTK "Dashboard". Using some other library
which supports the JUnit XML export makes it easier to integrate the build
with Jenkins/Hudson and other CI tools.

> Again, good work with the build system - it is much more user friendly now
> :-) I will keep playing with Celix (especially with the remote services)!

Thanks, I'm really interested to hear if you get them working. Deployment
currently isn't enough for testing Remote Services.
In the deploy directory there has to be a "rs_bundles" directory containing
the endpoints. Currently the deploy macro doesn't support deploying
additional files.

> Best,
> Sascha
> On 06/24/2012 05:18 PM, Alexander Broekhuis wrote:
>> Hi all,
>> One draw-back I noticed so far, if a sub-project is disabled, the
>>> dependencies aren't. So these have to be disabled via ccmake/cmake-gui.
>>>  I've updated the usage of the build options so that a separate property
>> is
>> used for dependencies. This way the build options aren't touched. So when
>> a
>> sub project is disabled, the dependencies are not build.

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message