Hello everyone, this is a follow up to my email from last week.
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.
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? 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.
- 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.
- (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.
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.)
Anyway, I'd love to hear eveyone's thoughts on this and any input you
have.
Cheers,
Jacob Garber
[1] https://github.com/weinhold/ham
