evl: Problems while trying to build up a debianization

evl: Problems while trying to build up a debianization

[Florian Bezdeka]

Hi Philippe,

we're starting with some very first steps regarding EVL here. The idea
was to enable the xenomai-images project to generate images with EVL as
well.

Currently we're failing because there is some confusion about the UAPI
installation here.

The meson build and install steps of libevl refer to some headers
coming from the (sources) of linux-evl. 

We're trying to integrate this meson based build into a debianization.
As libevl depends on some headers delivered by the kernel "package" we
would model that as a build dependency. libevl would depend on linux-
evl-headers.

Right now we're failing inside the setup-uapi.sh script because the
sources of linux-evl are not available. We were not able to set -Duapi
correctly.

To my understanding the dance with include/ inside the meson build
directory is necessary to limit the number of "special" include paths.
Is that correct?

Another issue we came across is the installation of the UAPI headers by
the libevl install step. Why is that necessary at all? The only
component that should depend on that headers is libevl itself. No?

Any idea how we could fix that up without breaking your local build
process?

Best regards,
Florian


-- 
Siemens AG, Technology
Linux Expert Center

Re: evl: Problems while trying to build up a debianization

[Philippe Gerum]

Florian Bezdeka <florian.bezdeka@siemens.com> writes:

> Hi Philippe,
>
> we're starting with some very first steps regarding EVL here. The idea
> was to enable the xenomai-images project to generate images with EVL as
> well.
>
> Currently we're failing because there is some confusion about the UAPI
> installation here.
>
> The meson build and install steps of libevl refer to some headers
> coming from the (sources) of linux-evl. 
>
> We're trying to integrate this meson based build into a debianization.
> As libevl depends on some headers delivered by the kernel "package" we
> would model that as a build dependency. libevl would depend on linux-
> evl-headers.
>
> Right now we're failing inside the setup-uapi.sh script because the
> sources of linux-evl are not available. We were not able to set -Duapi
> correctly.
>
> To my understanding the dance with include/ inside the meson build
> directory is necessary to limit the number of "special" include paths.
> Is that correct?
>

Correct.

> Another issue we came across is the installation of the UAPI headers by
> the libevl install step. Why is that necessary at all? The only
> component that should depend on that headers is libevl itself. No?
>

Actually, many user-facing headers from include/evl do pull bits from
inner uapi/ headers, so we need the later. However, installing the
kernel uapi/ files as part of the libevl artefacts is a relic from the
Dark Ages, when the target toolchain would not have a copy of those. In
this day and age, we build proper toolchains which do include a copy of
the exported uapi/ headers.

IOW, I agree that libevl should not be exporting the uapi/, this is
some kernel-headers package's business which some toolchain builder
would use.

> Any idea how we could fix that up without breaking your local build
> process?
>

In fact, I'm the one who needs to fix his own process here. So, I bit
the bullet eventually, fixing the way the EVL uapi/ files are referred
to by the kernel code, aligning libevl on the sanitized result.

As a by-product, CONFIG_UAPI_HEADER_TEST is now happy with the EVL uapi/
headers, which is good news for preparing a kernel-headers
package. Meanwhile, libevl does not copy the uapi/ anymore during the
installation process. I'll fix my meta layers to get them properly from
a linux-evl-headers package on my end.

Referring to a local custom copy of the kernel headers via the -Duapi
option still makes sense in maintainer mode (only), when rebuilding a
toolchain to include an updated set of exported kernel headers would be
overkill. Said differently, when working on changes involving the uapi/
on the kernel side, I don't want to have to bootstrap bitbake, so I'd
rather pull the uapi/ headers in place directly from the development
kernel tree. That is the rational for keeping this option basically.

All of the v5.10.y, v6.1.y and v6.6 EVL kernel branches have been
updated accordingly. The associated libevl changes are available from
the -next branch. I think the debianization should be easier. Let me
know if I can help in fixing other rough edge(s).

-- 
Philippe.