From: Philippe Gerum <rpm@xenomai.org>
To: Florian Bezdeka <florian.bezdeka@siemens.com>
Cc: clara.kowalsky@siemens.com, xenomai@lists.linux.dev
Subject: Re: evl: Problems while trying to build up a debianization
Date: Sun, 05 Nov 2023 18:23:07 +0100 [thread overview]
Message-ID: <87wmuwjdqq.fsf@xenomai.org> (raw)
In-Reply-To: <4481c3ac97badd74e74849a97b049f1bb5c89fb7.camel@siemens.com>
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.
prev parent reply other threads:[~2023-11-05 17:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 14:47 evl: Problems while trying to build up a debianization Florian Bezdeka
2023-11-05 17:23 ` Philippe Gerum [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wmuwjdqq.fsf@xenomai.org \
--to=rpm@xenomai.org \
--cc=clara.kowalsky@siemens.com \
--cc=florian.bezdeka@siemens.com \
--cc=xenomai@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).