[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
Mon Jan 25 07:14:37 EST 2016


Lutz, and all

> -----Original Message-----
> From: genivi-diagnostic-log-and-trace-bounces at lists.genivi.org [mailto:genivi-diagnostic-log-and-trace-bounces at lists.genivi.org] On Behalf Of Helwing, Lutz
> Sent: den 25 januari 2016 10:56
> To: genivi-diagnostic-log-and-trace at lists.genivi.org
> Subject: Re: [genivi-dlt] Bug, or at least inconsistency between DLT, CommonAPI runtimes (C++, D-Bus, ...) and some other GENIVI programs
> 
> Hi Gunnar,
> 
> thanks for pointing out this issue.
> 
> The main problem is that it was wrongly written in the manual. 

Oh, OK.  I guess I had seen that before but now I only double checked 
at the HEAD commit, in which you have changed this now to #include <dlt.h>

> We have
> fixed this with commit 9e101ff434230a95fb8f4fd33dc48f4970496d1c. The
> patch for this was sent to this list Nov 4th 2015 with subject "DLT user
> manual and package config file are inconsistent with include directory".

My apologies for not reading the list archives properly before posting.
But I would still raise the question how to handle the many projects
that followed the documented convention.

> 
> Like you said now we have the problem that other users of the library 
> have used the wrong convention thus all of them would have to change 
> which is not very satisfying.
> 
> Personally maybe following your suggestion to allow both conventions 
> would be the best way to go?

Yeah, I actually prefer #include <dlt/dlt.h>, maybe mostly because I am
used to seeing it now, and that was the previous standard.  

I'm a little surprised you decided to change this and claim that the other
was incocrrect - after all there is nothing really wrong with the convention
the manual asked for. 

I included a few more mailing lists in my original mail because input 
from those other projects would help but as I wrote, I can find it 
in many (or maybe all) GENIVI components that use DLT today.

If dlt/dlt.h has been a documented convention for quite some time (years?)
in the manual, personally I would have proposed to keep it and make sure 
it compiles correctly in all cases.

But if DLT project itself decides to include *both* possibilities and 
recommend <dlt.h> in the manual from now on, that's OK too I guess.

- Gunnar

> 
> Please discuss!
> 
> Kind regards,
> Lutz
> 
> 
> On 23/01/16 01:47, Andersson, Gunnar wrote:
>> 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
>> .pc.in
>> [2] http://git.projects.genivi.org/?p=dlt-daemon.git;a=blob;f=doc/dlt_user_m
>> anual.txt
>>
>>
>> -- 
>> Gunnar Andersson
>> Lead Architect, GENIVI Alliance
>> Infotainment, Volvo Car Corporation
>> _______________________________________________
>> genivi-diagnostic-log-and-trace mailing list
>> genivi-diagnostic-log-and-trace at lists.genivi.org
>> https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace
> _______________________________________________
> genivi-diagnostic-log-and-trace mailing list
> genivi-diagnostic-log-and-trace at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace
> -----Original Message-----
> From: genivi-diagnostic-log-and-trace-bounces at lists.genivi.org [mailto:genivi-diagnostic-log-and-trace-bounces at lists.genivi.org] On Behalf Of Helwing, Lutz
> Sent: den 25 januari 2016 10:56
> To: genivi-diagnostic-log-and-trace at lists.genivi.org
> Subject: Re: [genivi-dlt] Bug, or at least inconsistency between DLT, CommonAPI runtimes (C++, D-Bus, ...) and some other GENIVI programs
> 
> Hi Gunnar,
> 
> thanks for pointing out this issue.
> 
> The main problem is that it was wrongly written in the manual. We have 
> fixed this with commit 9e101ff434230a95fb8f4fd33dc48f4970496d1c. The 
> patch for this was sent to this list Nov 4th 2015 with subject "DLT user 
> manual and package config file are inconsistent with include directory".
> 
> Like you said now we have the problem that other users of the library 
> have used the wrong convention thus all of them would have to change 
> which is not very satisfying.
> 
> Personally maybe following your suggestion to allow both conventions 
> would be the best way to go?
> 
> Please discuss!
> 
> Kind regards,
> Lutz
> 
> 
> On 23/01/16 01:47, Andersson, Gunnar wrote:
>> 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
>> .pc.in
>> [2] http://git.projects.genivi.org/?p=dlt-daemon.git;a=blob;f=doc/dlt_user_m
>> anual.txt
>>
>>
>> -- 
>> Gunnar Andersson
>> Lead Architect, GENIVI Alliance
>> Infotainment, Volvo Car Corporation
>> _______________________________________________
>> genivi-diagnostic-log-and-trace mailing list
>> genivi-diagnostic-log-and-trace at lists.genivi.org
>> https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace
> _______________________________________________
> genivi-diagnostic-log-and-trace mailing list
> genivi-diagnostic-log-and-trace at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace
> -----Original Message-----
> From: genivi-diagnostic-log-and-trace-bounces at lists.genivi.org [mailto:genivi-diagnostic-log-and-trace-bounces at lists.genivi.org] On Behalf Of Helwing, Lutz
> Sent: den 25 januari 2016 10:56
> To: genivi-diagnostic-log-and-trace at lists.genivi.org
> Subject: Re: [genivi-dlt] Bug, or at least inconsistency between DLT, CommonAPI runtimes (C++, D-Bus, ...) and some other GENIVI programs
> 
> Hi Gunnar,
> 
> thanks for pointing out this issue.
> 
> The main problem is that it was wrongly written in the manual. We have 
> fixed this with commit 9e101ff434230a95fb8f4fd33dc48f4970496d1c. The 
> patch for this was sent to this list Nov 4th 2015 with subject "DLT user 
> manual and package config file are inconsistent with include directory".
> 
> Like you said now we have the problem that other users of the library 
> have used the wrong convention thus all of them would have to change 
> which is not very satisfying.
> 
> Personally maybe following your suggestion to allow both conventions 
> would be the best way to go?
> 
> Please discuss!
> 
> Kind regards,
> Lutz
> 
> 
> On 23/01/16 01:47, Andersson, Gunnar wrote:
>> 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
>> .pc.in
>> [2] http://git.projects.genivi.org/?p=dlt-daemon.git;a=blob;f=doc/dlt_user_m
>> anual.txt
>>
>>
>> -- 
>> Gunnar Andersson
>> Lead Architect, GENIVI Alliance
>> Infotainment, Volvo Car Corporation
>> _______________________________________________
>> genivi-diagnostic-log-and-trace mailing list
>> genivi-diagnostic-log-and-trace at lists.genivi.org
>> https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace
> _______________________________________________
> genivi-diagnostic-log-and-trace mailing list
> genivi-diagnostic-log-and-trace at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace
>



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