[haiku-development] Re: GSoC for Ham Build System

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 21 Mar 2019 08:30:01 +0100

On Wed, Mar 20, 2019 at 05:50:40PM -0600, Jacob Garber wrote:

Hello everyone, this is a follow up to my email from last week.

Hello again!


My name is Jacob Garber and I am a fourth year undergraduate student at
the University of Alberta. As I wrote on the mailing list, I am
interested in working on the Ham [1] build system in Haiku for this
year's GSoC. As a bit of background, I am a mathematics major and
computer science minor, and have extensive experience with C++.

The first thing I would like to ask is if in the end it might be less
effort to switch to another build system rather than maintain a
separate one. CMake was (understandably) rejected on the mailing list,
but there are other mature C/C++ build systems out there (eg. Gnome is
switching to Meson + Ninja, which was designed to be fast and
efficient). Of course, I'm not very familiar with the project
and am just throwing this out there as an idea.

You have seen the thread about CMake, then. There were a few comments
there which basically apply to any other buildsystem. It's not outright
rejection, but more a checklist. Can they support running 3 compilers
(host, gcc2, gcc4) in the same build? Can they support building said
compilers before using them? (currently done in our configure script)
Can they support xattrs and post-build targets to add resources to
executables? Can they support build profiles and easy customisation of
what gets in the final Haiku image? Can they support building just parts
of the system in debug mode?

The list goes on and on. By looking in the build/jam directory you can
see how many custom rules we have accumulated over the years, to do
various more or less complex tasks. Our buildsystem is a lot more than
just compiling a few executables, it also create disk images, builds
packages, downloads dependencies, etc.

So, if you have a roadmap for implementing all of this in another
buildsystem, that sounds reasonable. Of course it should run natively on
Haiku, which I think isn't the case for Meson yet?

If not, then I would be happy to work on Ham this summer. I've been
looking over the GSoC application, and it requires a detailed
description of goals to achieve. Of course, the ultimate goal is to use
Ham as the default build system, but I don't know what steps are needed
to make that happen. What is the current compatibility of ham with jam,
and what needs to be worked on? 

Just try it and see what happens.

Aside from that, I was reading about
the current build setup, and there are several features that I think
would be nice to develop along the way:

- multithreading. Jam is sometimes flaky with parallel builds, and this
has caused issues in the past.

Any buildsystem will have this problem if dependencies between targets
are not properly declared. Jam is also known to have a bug in a complex
corner case (one target generating multiple outputs), and we expect
switching to Ham could fix that.

- extended attributes. The current build system requires extended
attributes, which many common file systems don't support (eg. ext4,
btrfs). It would be nice to remove this requirement, or at least more
cleanly emulate xattrs in the build system.

What's wrong with the two existing emulation layers? We have one for
systems that supports limited xattrs (storing an identifier in the
xattrs, that point to a separate file holding the attribute data), and
we have one for systems that don't support xattrs at all (more fragile,
but not used for ext4 and btrfs).

You cannot remove them completely, because on Haiku you need the
buildsystem to generate executables in the native format, including
their attributes.

- (possibly) building on case-insensitive file systems. I'm not sure if
this is a limitation of jam or a property of the Haiku codebase, so
this is just to throw it out there.

Do you see a way to have the compiler differenciate #include <String.h>
from #include <string.h> on a case sensitive filesystem? Both files are
part of the BeOS API and we are not going to rename them. So this
problem is not fixable, and does not result in any way from buildsystem
limitations.


Aside from that, one thing that could be done immediately is upgrade
the existing ham codebase to C++11. Haiku supports GCC 7 and so
(correct me if I'm wrong) we could begin using features from C++11 and
even C++14. For example, the classes in src/util/Referenceable.h
implement an atomic reference counted pointer, and to reduce code
maintenance we could replace this with the shared_ptr from C++11. There
are many other instances where raw pointers are used in the codebase,
and we could replace those with other smart pointers to simplify the
code and reasoning about lifetimes. There are also many other
miscellaneous things that could be done, such as replacing enums with
enum classes, NULL with nullptr, old iterator loops with the new colon
for loops, etc. (Many of these issues can be flagged and even fixed by
the clang-tidy tool.)

Yes, sounds fine.

-- 
Adrien.

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2019