[genivi-dlt] Bug, or at least inconsistency between DLT, CommonAPI runtimes (C++, D-Bus, ...) and some other GENIVI programs

Andersson, Gunnar gunnar.x.andersson at volvocars.com
Fri Jan 22 19:47:21 EST 2016

Here is a "bug" I found years ago in fact but soon after 
the work was kind of abandoned.
If you remember I did some native compilation of GENIVI programs 
under the small project "GMS" = GENIVI minimal system.   

Local installation again is needed to make somewhat isolated
build jobs on the Go server for example, and then this bug has 
been noticed again:

It is a little tricky to decide which project would consider 
changing and so I did not log this in a bug tracker yet but 
bring it here for discussion with the maintainers.

automotive-dlt.pc [1] includes:

Cflags: -I${includedir}/dlt

Many/most/all(?) programs - at least all the CommonAPI runtimes,
lifecycle components and persistence however use dlt/ as prefix 
for the header includes also, like this:

#include <dlt/dlt.h>

That means that if a program does #include <dlt/dlt.h>, then the 
searched path in fact becomes <include-dir>/dlt/dlt/dlt.h which 
of course doesn't exist.

Here is the twist, if I have understood it correctly - 
this bug is normally not noticed, because in a non-prefix install, the
headers will be installed in a standard place /usr/include/dlt/dlt.h

I think most compiles will have /usr/include as a default include 
search directory anyway and therefore <dlt/dlt.h> would be found 
and the compilation succeeds.
This is however just a lucky coincidence and basically hiding a bug.

So, when DLT is installed to a non-standard prefix (which is really
required to do isolated local compilation tests) then this relies 
on the pkg-config and the defined $PREFIX to find the include 
files, and the include-file is not found.

I would actually recommend and prefer the convention 
#include <dlt/dlt.h> but then the pkg-config must change.

And looking deeper, I found that the user manual for DLT [2] actually
says that you should do #include <dlt.h>, which formally means it is
the CommonAPI tooling, Lifecycle and Persistence that is buggy.

So what do you guys think, would DLT consider changing the convention
to <dlt/dlt.h> instead (and fix its pkg-config file), or would you
claim that all other projects should change?  I'd prefer
to see it resolved so that it's not necessary to patch this
to make PREFIX installs work.

Since there are now two active conventions maybe the safest
is to add both PREFIX and PREFIX/dlt to the header search path?

Best Regards
- Gunnar

[1] http://git.projects.genivi.org/?p=dlt-daemon.git;a=blob;f=automotive-dlt
[2] http://git.projects.genivi.org/?p=dlt-daemon.git;a=blob;f=doc/dlt_user_m

Gunnar Andersson
Lead Architect, GENIVI Alliance
Infotainment, Volvo Car Corporation

More information about the genivi-diagnostic-log-and-trace mailing list