RFC: Build system change

RFC: Build system change

[Christopher J. PeBenito]

Back when refpolicy started, every system carried the policy sources and 
built its own policy locally. Given that world, *make* was the obvious 
choice — ubiquitous, lightweight, and well understood. The downside is a 
set of Makefiles that’s hard to read and even harder to maintain.

Fast‑forward to today, and no one is building full policies on‑device 
anymore. Outside of a few local modules, the main policy is built by the 
distro. With that in mind, I’d like to move the main policy build to a 
modern system (the headers‑based builds would stay on make).

I’ve been experimenting with *meson/ninja*, and so far the results look 
good. I’d appreciate feedback on two points:

 1.

    *Concerns about making this change*

 2.

    *Which build system we should adopt (I'm definitely not attached to
    meson)*

-- 
Chris PeBenito

Re: RFC: Build system change

[Russell Coker]

On Tuesday, 1 September 2026 23:42:14 AEST Christopher J. PeBenito wrote:
> Back when refpolicy started, every system carried the policy sources and
> built its own policy locally. Given that world, *make* was the obvious
> choice — ubiquitous, lightweight, and well understood. The downside is a
> set of Makefiles that’s hard to read and even harder to maintain.

My experience of working on many FOSS projects is that convoluted GNU make 
files are easier to maintain for me than all of the alternatives.  The 
alternatives change more than GNU make so I never get the level of 
understanding of them that I have of GNU make.

If the aim is "everyone should be able to work on this" then GNU make is the 
solution.  If the aim is "a few people should be able to work on this 
efficiently and it can just work for everyone else" then ninja etc may be good 
options.

> Fast‑forward to today, and no one is building full policies on‑device
> anymore. Outside of a few local modules, the main policy is built by the
> distro. With that in mind, I’d like to move the main policy build to a
> modern system (the headers‑based builds would stay on make).

By "headers builds" do you mean things like the following?

# ls -al
total 256
drwxr-xr-x. 1 root root    194 Aug 31 13:10 .
drwx------. 1 root root   2042 Sep  1 18:33 ..
-rw-r--r--. 1 root root    358 Jan 17  2022 local.fc
-rw-r--r--. 1 root root     23 Jan 19  2017 local.if
-rw-------. 1 root root  86662 Aug 18 14:17 local.pp
-rwx------. 1 root root   1396 Aug 21 16:09 local.sh
-rw-r--r--. 1 root root   1418 Jun 25 19:03 local.te
lrwxrwxrwx. 1 root root     51 Jun 18  2012 Makefile -> /usr/share/doc/
selinux-policy-dev/examples/Makefile
drwxr-xr-x. 1 root root    304 Aug 18 14:17 tmp
-rw-------. 1 root root      0 Jul 15 23:47 toadd.fc
-rw-r--r--. 1 root root     23 Jan 17  2017 toadd.if
-rw-------. 1 root root 118890 Aug 27 20:58 toadd.pp
-rw-r--r--. 1 root root   9194 Aug 27 20:58 toadd.te

>     *Which build system we should adopt (I'm definitely not attached to
>     meson)*

If the aim is "a few people should be able to work on this efficiently and it 
can just work for everyone else" then I'll be part of the "everyone else" and 
hopefully be unconcerned about which option you choose.  Anything that's 
packaged for Debian is fine by me.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: RFC: Build system change

[Christopher J. PeBenito]

On 9/1/26 10:34 PM, Russell Coker wrote:
> On Tuesday, 1 September 2026 23:42:14 AEST Christopher J. PeBenito wrote:
>> Back when refpolicy started, every system carried the policy sources and
>> built its own policy locally. Given that world, *make* was the obvious
>> choice — ubiquitous, lightweight, and well understood. The downside is a
>> set of Makefiles that’s hard to read and even harder to maintain.
> My experience of working on many FOSS projects is that convoluted GNU make
> files are easier to maintain for me than all of the alternatives.  The
> alternatives change more than GNU make so I never get the level of
> understanding of them that I have of GNU make.

Sure, in general, make is an easy bar for most. However, my experience 
with refpolicy specifically is it doesn't fit the common case. I 
authored the Makefiles and sometimes have trouble updating them. Many 
times over the years I've had to help others because they couldn't 
understand them.


> If the aim is "everyone should be able to work on this" then GNU make is the
> solution.  If the aim is "a few people should be able to work on this
> efficiently and it can just work for everyone else" then ninja etc may be good
> options.
>
>> Fast‑forward to today, and no one is building full policies on‑device
>> anymore. Outside of a few local modules, the main policy is built by the
>> distro. With that in mind, I’d like to move the main policy build to a
>> modern system (the headers‑based builds would stay on make).
> By "headers builds" do you mean things like the following?
>
> # ls -al
> total 256
> drwxr-xr-x. 1 root root    194 Aug 31 13:10 .
> drwx------. 1 root root   2042 Sep  1 18:33 ..
> -rw-r--r--. 1 root root    358 Jan 17  2022 local.fc
> -rw-r--r--. 1 root root     23 Jan 19  2017 local.if
> -rw-------. 1 root root  86662 Aug 18 14:17 local.pp
> -rwx------. 1 root root   1396 Aug 21 16:09 local.sh
> -rw-r--r--. 1 root root   1418 Jun 25 19:03 local.te
> lrwxrwxrwx. 1 root root     51 Jun 18  2012 Makefile -> /usr/share/doc/
> selinux-policy-dev/examples/Makefile
> drwxr-xr-x. 1 root root    304 Aug 18 14:17 tmp
> -rw-------. 1 root root      0 Jul 15 23:47 toadd.fc
> -rw-r--r--. 1 root root     23 Jan 17  2017 toadd.if
> -rw-------. 1 root root 118890 Aug 27 20:58 toadd.pp
> -rw-r--r--. 1 root root   9194 Aug 27 20:58 toadd.te

Yes, exactly.


>>      *Which build system we should adopt (I'm definitely not attached to
>>      meson)*
> If the aim is "a few people should be able to work on this efficiently and it
> can just work for everyone else" then I'll be part of the "everyone else" and
> hopefully be unconcerned about which option you choose.  Anything that's
> packaged for Debian is fine by me.

Another option is to keep make and then put the more complex bits into 
external scripts.


-- 
Chris PeBenito

Re: RFC: Build system change

[Russell Coker]

On Wednesday, 2 September 2026 23:53:27 AEST Christopher J. PeBenito wrote:
> > My experience of working on many FOSS projects is that convoluted GNU make
> > files are easier to maintain for me than all of the alternatives.  The
> > alternatives change more than GNU make so I never get the level of
> > understanding of them that I have of GNU make.
> 
> Sure, in general, make is an easy bar for most. However, my experience
> with refpolicy specifically is it doesn't fit the common case. I
> authored the Makefiles and sometimes have trouble updating them. Many
> times over the years I've had to help others because they couldn't
> understand them.

If you have trouble managing them even though you wrote them then it seems 
clear that they should be rewritten regardless of what others may desire.

> >>      *Which build system we should adopt (I'm definitely not attached to
> >>      meson)*
> > 
> > If the aim is "a few people should be able to work on this efficiently and
> > it can just work for everyone else" then I'll be part of the "everyone
> > else" and hopefully be unconcerned about which option you choose. 
> > Anything that's packaged for Debian is fine by me.
> 
> Another option is to keep make and then put the more complex bits into
> external scripts.

That of course just changes the issue of using a make language not everyone 
knows to using a general purpose programming language everyone knows.

Based on the way things are going I'm guessing that would be Python which is a 
language I am not good at.  But I am capable of minimal hacking in Python and 
have done so on several SE Linux related modules.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: RFC: Build system change

[Russell Coker]

On Thursday, 3 September 2026 02:08:36 AEST Russell Coker wrote:
> > Another option is to keep make and then put the more complex bits into
> > external scripts.
> 
> That of course just changes the issue of using a make language not everyone
> knows to using a general purpose programming language NOT everyone knows.

I missed the word "NOT" in my previous message.

Unless of course you use scripts written in bash.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: RFC: Build system change

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

"Christopher J. PeBenito" <pebenito@ieee.org> writes:

> Back when refpolicy started, every system carried the policy sources
> and built its own policy locally. Given that world, *make* was the
> obvious choice — ubiquitous, lightweight, and well understood. The
> downside is a set of Makefiles that’s hard to read and even harder to
> maintain.
>
> Fast‑forward to today, and no one is building full policies on‑device
> anymore. Outside of a few local modules, the main policy is built by
> the distro. With that in mind, I’d like to move the main policy build
> to a modern system (the headers‑based builds would stay on make).
>
> I’ve been experimenting with *meson/ninja*, and so far the results
> look good. I’d appreciate feedback on two points:
>
> 1.
>
>    *Concerns about making this change*


We'd lose the ability to quickly run make for a single policy being
developed before it moves into proper packaging, I think, but we could
keep simple Makefiles around for that case.

>
> 2.
>
>    *Which build system we should adopt (I'm definitely not attached to
>    meson)*

Meson is usually the nicest to deal with as a distribution maintainer.

I'm also a Meson contributor. I think Rahul was interested in adding
SELinux policy support natively into Meson too.

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: RFC: Build system change

[Russell Coker]

On Thursday, 3 September 2026 19:10:32 AEST Sam James wrote:
> We'd lose the ability to quickly run make for a single policy being
> developed before it moves into proper packaging, I think, but we could
> keep simple Makefiles around for that case.

For me to build a complete set of Debian policy packages including MCS and MLS 
on a E5-2696 v4 CPU takes around 97 seconds elapsed and 216s user CPU time.  
If I had a clock speed optimised CPU of that era it would take a bit less (a 
22 core CPU is not ideal for a mostly 1 core build process).

For most developer compile scenarios less than 100 seconds isn't something 
that is a great cost.  It takes longer than that to get yourself a caffeinated 
drink.

It's not terribly expensive to get a CPU that's twice as fast as one of those 
nowadays, particularly if you want gamer grade hardware not enterprise grade.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: RFC: Build system change

[Christopher J. PeBenito]

On 9/3/26 5:10 AM, Sam James wrote:
> "Christopher J. PeBenito" <pebenito@ieee.org> writes:
>
>> Back when refpolicy started, every system carried the policy sources
>> and built its own policy locally. Given that world, *make* was the
>> obvious choice — ubiquitous, lightweight, and well understood. The
>> downside is a set of Makefiles that’s hard to read and even harder to
>> maintain.
>>
>> Fast‑forward to today, and no one is building full policies on‑device
>> anymore. Outside of a few local modules, the main policy is built by
>> the distro. With that in mind, I’d like to move the main policy build
>> to a modern system (the headers‑based builds would stay on make).
>>
>> I’ve been experimenting with *meson/ninja*, and so far the results
>> look good. I’d appreciate feedback on two points:
>>
>> 1.
>>
>>     *Concerns about making this change*
>
> We'd lose the ability to quickly run make for a single policy being
> developed before it moves into proper packaging, I think, but we could
> keep simple Makefiles around for that case.

When you say single policy, do you mean a full build of standard/MLS/MCS 
or an individual policy module like "make modulename.pp"?


>> 2.
>>
>>     *Which build system we should adopt (I'm definitely not attached to
>>     meson)*
> Meson is usually the nicest to deal with as a distribution maintainer.
>
> I'm also a Meson contributor. I think Rahul was interested in adding
> SELinux policy support natively into Meson too.
>
Can you clarify what that means? It seems like a very specialized feature.


-- 
Chris PeBenito

Re: RFC: Build system change

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

"Christopher J. PeBenito" <pebenito@ieee.org> writes:

> On 9/3/26 5:10 AM, Sam James wrote:
>> "Christopher J. PeBenito" <pebenito@ieee.org> writes:
>>
>>> Back when refpolicy started, every system carried the policy sources
>>> and built its own policy locally. Given that world, *make* was the
>>> obvious choice — ubiquitous, lightweight, and well understood. The
>>> downside is a set of Makefiles that’s hard to read and even harder to
>>> maintain.
>>>
>>> Fast‑forward to today, and no one is building full policies on‑device
>>> anymore. Outside of a few local modules, the main policy is built by
>>> the distro. With that in mind, I’d like to move the main policy build
>>> to a modern system (the headers‑based builds would stay on make).
>>>
>>> I’ve been experimenting with *meson/ninja*, and so far the results
>>> look good. I’d appreciate feedback on two points:
>>>
>>> 1.
>>>
>>>     *Concerns about making this change*
>>
>> We'd lose the ability to quickly run make for a single policy being
>> developed before it moves into proper packaging, I think, but we could
>> keep simple Makefiles around for that case.
>
> When you say single policy, do you mean a full build of
> standard/MLS/MCS or an individual policy module like "make
> modulename.pp"?
>

Ah, sorry, I meant "make modulename.pp" when working on something new.

>
>>> 2.
>>>
>>>     *Which build system we should adopt (I'm definitely not attached to
>>>     meson)*
>> Meson is usually the nicest to deal with as a distribution maintainer.
>>
>> I'm also a Meson contributor. I think Rahul was interested in adding
>> SELinux policy support natively into Meson too.
>>
> Can you clarify what that means? It seems like a very specialized feature.

Not needing custom_targets to build policy files, so benefitting from
proper typing and native Meson objects for it. Meson already has them
for various languages and it welcomes more of them.

I think he had some specific benefits in mind but I'd have to ask him
what they were again.

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]