Draft du message concernant les macros RPM pour X / Wayland.
Merci d'avance pour la review. Je posterai demain matin.
Steph
--------------------------------------------------------------
Hello all,
Baptiste Durand and I recently reviewed some patches where the spec
files are modified to add X or wayland support conditionally.
The reviews are here:
- https://review.tizen.org/gerrit/13048 (merged)
- https://review.tizen.org/gerrit/13181 (merged)
- https://review.tizen.org/gerrit/13292
- https://review.tizen.org/gerrit/13310
- https://review.tizen.org/gerrit/13421
The common point in these patches is: to check if we're building with X,
the condition used in spec files is: '%if !%{without x}', like:
%if !%{without x}
BuildRequires: pkgconfig(x11)
BuildRequires: pkgconfig(ecore-x)
%endif
Later in some spec file, it"s also used to define wayland specific
options, like:
%if %{without x}
%build
%cmake . -DENABLE_GTK=OFF -DENABLE_WAYLAND=TRUE
%else
%build
%cmake . -DENABLE_GTK=OFF -DENABLE_WAYLAND=FALSE
%endif
For the first merged patch on mesa, it's even more strange, as a
"without x" is tested but without any instruction between %if and %else:
%if %{without x}
%else
BuildRequires ...
%endif
IMO, these patterns are not the best way to do things.
Actually, there's a '%define wayland 1' (for IVI), but AFAIK, there's no
'%define x 1' for other targets with X11 (didn't see it in Tizen:Mobile
project conf).
As you probably know, Weston can also be run with X compatibility (at
least until a recent Xorg version, as I think that xwayland support has
been removed in latest xorg server release... to be confirmed)
Finally, using only one define for conditional builds leads to false
conclusions:
- not being on X doesn't always mean with have wayland
- not being on wayland doesn't always mean with have X
- having X doesn't mean we don't have wayland
- having wayland doesn't mean we dont' have X
- etc.
Proposal
--------
To be consistent, we propose to have two optional defines in the project
config (depending on the profile):
- wayland: to check if wayland support exists (already defined and used)
- x or x11: to check if we're building for legacy X11 (not defined
anywhere actually)
As wayland is actually defined, it's only one new define to add: this
also minimizes the number of macros and the resulting combinations.
Meaning would be simple (assume 1=defined, 0=undefined):
| wayland | x | meaning
|----------------------------------------------------
| 0 | 1 | pure X11 platform (no wayland) - ex: mobile
| 1 | 0 | pure wayland platform (no X11) - ex: IVI
| 1 | 1 | wayland with X compatibility
| 0 | 0 | no X and no wayland (base system, framebuffer ?)
This would avoid a common pattern which is not precise:
%if %{with wayland}
... (add wayland build option)
# OK
%else
... (add x build option)
# NO! not being on wayland doesn't
# mean we're on X
%endif
The following pattern or other variants could be used in replacement:
%if %{with wayland}
...
%endif
%if %{with x}
...
%endif
or
%if %{with x}
%if %{with wayland}
... (X+wayland)
%else
... (X alone)
%endif
%else
%if %{with wayland}
... (pure wayland)
%else
... (framebuffer = no X, no wayland)
%end
%endif
If at some point in the future, we need to have Wayland + X (in
wayland-compatible mode) for a given profile, it'll be easy to check
'%if %{with wayland} && %{with x}' for the few packages where it's
needed (xorg-server in particular).
Regards,
Stéphane
--
Stéphane Desneux
Intel OTC - Vannes/FR
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
