[Dev] [X/Wayland] RPM Macros for conditional build with X, Wayland, both (and none!)

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Fri Dec 6 09:20:50 GMT 2013

Draft du message concernant les macros RPM pour X / Wayland.

Merci d'avance pour la review. Je posterai demain matin.


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)

Later in some spec file, it"s also used to define wayland specific 
options, like:
    %if %{without x}

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}
   BuildRequires ...

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 
- 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.


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
     ... (add x build option)
     # NO! not being on wayland doesn't
     # mean we're on X

The following pattern or other variants could be used in replacement:
  %if %{with wayland}
  %if %{with x}


  %if %{with x}
     %if %{with wayland}
      ... (X+wayland)
      ... (X alone)
     %if %{with wayland}
      ... (pure wayland)
      ... (framebuffer = no X, no wayland)

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).


Stéphane Desneux
Intel OTC - Vannes/FR

More information about the Dev mailing list