Investigate and change build systems

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50863

• Created at 2020-01-29 03:02:53 by firstyear (@Firstyear)
• Assigned to nobody

---

Issue Description

Due to the recent change to move dscontainer from sbin -> libexec, this has created a packaging problem at suse - we don't have libexec.

Now, to make this more difficult, it looks like our configure.ac has libexec, but it goes to /usr/lib/dirsrv for the ds_selinux helper scripts, and setup.py is hardcoding /usr/libexec/dirsrv/ into it's process.

Really, I feel like we are starting to see some cracks in our tooling here. Autotools may be fine for C programs and some of the templating we do for files, but it's really frustrating to extend. The whole process to work out "how to make rust work inside of autotools" has been a multi-year effort, and now looking at setup.py it's pretty clear that we have a lot of inflexibility there too.

While I am able to work around this in the suse spec for now, I believe we really need to "do some house keeping" and fix this. We are very likely beyond the capabilities of what autotools can do and provide.

I think we should look at the following options, which both are already available on suse/rhel:

• https://mesonbuild.com/
• https://cmake.org/

Some musts:

• Ability to enable/disable asan on cli for qe/dev work flows
• Flagging for online/offline builds to assist with cargo/npm workflows
• Minimal setup/overhead
• ease of extension
• Ability to template files from build variables (ie for defaults.inf)
• Easier processes for linking C + Rust
• Ability to coordinate python and node/npm builds.

To achieve this I think we should start work on a "parallel build" system in the same directory that we can use as developers to find and iron out issues, while continuing with downstream releases using autotools. Then we select a major version and change them out at some point.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-01-30 17:43:22

Metadata Update from @mreynolds389:

• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None
• Issue set to the milestone: FUTURE

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-05-06 16:54:28

Metadata Update from @mreynolds389:

• Issue priority set to: normal
• Issue set to the milestone: 1.4.5 (was: FUTURE)

[droideck]

@Firstyear after 2 years and your experience with SUSE building, what do you think about the issue now? Should we still pursue it and prioritize? (1.4.5 is surely a wrong milestone)

[Firstyear]

I still think we should do this. Our current autotools build is a hot mess. I started an experimental build with meson at one point, but never put it into a PR. I think there are other options now too we could use like using rust/cargo to drive all the C build parts too. But that would need agreement we are going to use rust-by-default all the time.

[eli-schwartz]

Meson has -Db_sanitize= to enable sanitizer flags as a builtin option. For offline builds... nothing should be downloading content over the network during a build anyway, other than potentially (opt-in) subproject wraps. However you can use --wrap-mode=nodownload for that.