[genivi-dlt] dlt-daemon commits since v2.16.0

Stephen Lawrence stephen.lawrence at renesas.com
Wed Jul 19 11:16:56 EDT 2017

Hi Christoph,

Thanks for the quick reply.

> -----Original Message-----
> From: Lipka, Christoph (ADITG/ESA) [mailto:clipka at de.adit-jv.com]
> Sent: 19 July 2017 06:42
> To: Stephen Lawrence <stephen.lawrence at renesas.com>; REE
> rniemeyer at DE.ADIT-JV.COM <rniemeyer at DE.ADIT-JV.COM>
> Cc: genivi-diagnostic-log-and-trace at lists.genivi.org; Joh, Yong-Il (Tolkien)
> <Yong-Il.Joh at windriver.com>
> Subject: AW: dlt-daemon commits since v2.16.0
> Hi Steve,
> There might be the possibility to release a 2.17 version of DLT. It is already 10
> Month ago that we released the latest version. When would you need the
> new version for the new release? If you have to take a decision immediately,
> it is fine to take HEAD.

Baseline O-0.2 was planned for release at the start of week 33. However in today's
BIT call we agreed pushing it back to week 34, to allow for some components to
be finalised and for holidays. 

There is no hard deadline but of course Tolkien (the Yocto Baseline maintainer)
needs time to finalise and test. So week 32 would be a good guideline. Tolkien
can use HEAD as a dev starting point and switch to a named tag when its available.

The BIT maintains a Baseline roadmap for each compliance cycle showing the planned 
versions for each release (red depicts a change since the last release). It's scope is to
show what's planned and to gather input. I've marked up dlt-daemon for update [1]
in O-0.2 - specifics TBA.

[1] https://collab.genivi.org/wiki/display/genivi/Yocto+GENIVI+Baseline+-+Orion+Roadmap

> A side question to you: DLT git currently contains a copy of Gtest framework
> for unit tests. I actually don’t like it at all (e.g.  wayland-ivi-extension just
> mention that Gtest is a pre-requisite to be installed before tests can be
> executed). So I want to remove the hard copy. Is there anything I have to
> consider from your point of view? I guess, we have to update the bitbake
> recipe of DLT to depend on Gtest, if Unit-tests are enabled by default.

Thanks for asking and sounds like a sensible idea. It would bring dlt in line
with the other components that use it.

The BIT recently finished updating our Integration Guidelines [2]. The intention
is to summarise the main points the BIT needs when integrating components.
It's not exhaustive and somewhat aimed at people asking the BIT to do the integration,
but of course the thought process applies when doing the work yourself.

[2] https://collab.genivi.org/wiki/display/genivi/BIT+Integration+Guidelines

Sounds like you have already given it good thought. Yes, build and runtime 
dependencies are key, to avoid reports of random build  failures from members 
or in the Genivi CI.

Quick recap of the baseline project for orientation on the structure - apologies,
if this is already clear. The Genivi Yocto Baseline combines meta-ivi and Poky to 
create a Genivi compliant build of the Poky Reference Distribution.
The Yocto meta data to create it can be found in the meta-ivi project in meta-ivi/meta-ivi [3],
whilst the dlt-daemon recipes can be found in the recipes-extended folder [4].

[3] https://github.com/GENIVI/meta-ivi/tree/13.0/meta-ivi
[4] https://github.com/GENIVI/meta-ivi/tree/13.0/meta-ivi/recipes-extended/dlt-daemon

The project has a separate meta-ivi-test layer, links: git [5] doc [6], which when added to
the Yocto layers pulls in any extras needed to run component unit tests. Happily dlt is one
of the components supported.

Whether the tests are built by default is up the component devs, i.e. meta-ivi executes a standard
build. The ivi-extension team include some useful utilities by default for example.

Looking at the dlt recipes it seems currently meta-ivi does not build them by default as the 
meta-ivi-test dlt recipe bbappend adds turning on the tests in CMAKE [7]. So you would add the gtest
dependencies to the bbappend [7]. If you want to include them by default, i.e. in any meta-ivi build,
then we would need to move the contents from the bbappend to the dlt bb recipe.

[5] https://github.com/GENIVI/meta-ivi/tree/13.0/meta-ivi-test
[6] https://at.projects.genivi.org/wiki/display/PROJ/Testing+GENIVI+software+in+meta-ivi
[7] https://github.com/GENIVI/meta-ivi/blob/13.0/meta-ivi-test/recipes-extended/dlt-daemon/dlt-daemon_%25.bbappend#L10

A long winded way of saying yes add gtest to the bbappend, but I just wanted to give some context :)

It's a straight forward change. Search meta-ivi for gtest to see how it's been done for other components. 
We could do it for you, but to be honest, whilst we realise that maintainers are often time constrained by their 
other work, we are really trying to encourage teams to feel part of the baseline team. To push updates, 
check integration and improve testing. The only hard requirement for the baseline is for it to be compliant. 
Everything else is a discussion about making it useful.

You seem to be thinking about the recipes, so if you are happy doing the work we would be happy for 
you to do it and to send a pull request to meta-ivi. Is that ok? Of course we can help and answer questions as needed.



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