[genivi-dlt] Bug, or at least inconsistency between DLT, CommonAPI runtimes (C++, D-Bus, ...) and some other GENIVI programs
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  includes:
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:
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  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?
Lead Architect, GENIVI Alliance
Infotainment, Volvo Car Corporation
More information about the genivi-diagnostic-log-and-trace