Choose build system for C API example code

[dminor]

In #552 we're adding a basic test for the C API using a Makefile. That's fine for now, but I think we should discuss options for building the C example code that we will eventually be adding as we flesh out the FFI. Some requirements I can think of off-hand:

• Cross-platform support (e.g. capable of generating msvc build files)
• Easy to integrate into our CI
• Readability of syntax

Given the wide variety of C build systems in use, it seems unlikely that whatever we chose will be used by a majority of consumers of our C API. For that reason, I think we should prioritize ease of use (for us) and readability (for others).

[sffc]

Bazel is easy to read and write, but I've heard that it is a bit heavy. If I were starting a C++ project, I would seriously consider Bazel, but it might not be the right tool for what we need here.

CMake is another option I've used. It's pretty simple and widely supported. I don't like that it creates a lot of junk files in your build directory, though (particularly annoying if you do in-source builds).

Then of course there's Autotools, the traditional GNU build system (./configure, make, make install). However, as far as I'm aware, it doesn't support Windows, so we would need to maintain separate Windows build files. (This is what ICU4C does.)

Any other options?

[filmil]

FWIW gn/ninja and scons are some lighter weight options. Not sure what it means for bazel to be "heavy"? It's rather efficient, but you need someone who knows it well to maintain it, especially if you want to fiddle with the toolchain, as one might want to in case of icu4x.

…

On Wed, Mar 17, 2021 at 6:13 PM Shane F. Carr ***@***.***> wrote: Bazel <https://bazel.build/> is easy to read and write, but I've heard that it is a bit heavy. If I were starting a C++ project, I would seriously consider Bazel, but it might not be the right tool for what we need here. CMake <https://cmake.org/> is another option I've used. It's pretty simple and widely supported. I don't like that it creates a lot of junk files in your build directory, though (particularly annoying if you do in-source builds). Then of course there's Autotools <https://www.gnu.org/software/automake/manual/html_node/Autotools-Introduction.html>, the traditional GNU build system (./configure, make, make install). However, as far as I'm aware, it doesn't support Windows, so we would need to maintain separate Windows build files. (This is what ICU4C does.) Any other options? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#557 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4GMEWBDTK2IRYLP5QF23TEFHSLANCNFSM4ZKQ2YXA> .

[sffc]

There's also gyp, used in Node.js modules (and elsewhere)

[sffc]

Not sure what it means for bazel to be "heavy"?

I meant "heavy" in the sense of being designed for larger projects and not very customizable (Ruby on Rails vs Sinatra).

[filmil]

On Wed, Mar 17, 2021 at 7:41 PM Shane F. Carr ***@***.***> wrote: Not sure what it means for bazel to be "heavy"? I meant "heavy" in the sense of being designed for larger projects and not very customizable (Ruby on Rails vs Sinatra).

Yes, that makes sense. FWIW I use bazel for some personal things, and have found that, as long as you don't need to write your own build rules, bazel is great. Especially a big time saver for correct and for incremental builds versus practically anything else out there. And since it keeps its artifacts away from the source tree, it's especially efficient if you use the source code from a network disk for example. Otherwise, if you need to roll your own build rules, there's quite a bit of upfront investment needed to understand how to write the build rules and to write them. It's doable, but arguably not everyone's cup of tea. I suppose in that respect it's designed for larger projects, as your upfront investment is a smaller percentage of the overall effort. In the case of icu4x, I suppose you could reuse the C and C++ build rules, and even the rust toolchain. Not sure how much work would be needed to weave the `cxx` tool in etc. And there's the part where bazel is still not well supported by IDEs, which some folks may care about. F

[dminor]

In my past life at Mozilla I spent a good chunk of time on third party library integrations into the Firefox build system. In this context, I've worked with autoconf, gyp, CMake, gn and Meson. In Firefox, we need to find a way of extracting information from these tools for use in our internal build system, which isn't a typical use case.

• autoconf: Windows support would require msys as far as I know. Using configure.in is pretty opaque compared to newer systems, so I don't think this ends up being easy for us to use or readable for others.
• gyp: I think the readability / usability is good, and the fact that it is a Python package makes integrating it nice from the point of view of integrating it into other build systems. This was used for building Chromium in the past, but isn't any longer, and other projects seem to be moving away from it, which makes we wonder if this is a good long term choice from a maintainability perspective.
• CMake: I don't really like the syntax. I wrote a Python parser for it once, and the grammar is a lot messier than the documentation would lead you to believe. I don't think it is as readable or easy to use as some of the other alternatives. It's a binary tool rather than something like a Python package.
• gn: I think this has good readability and tool can generate json files as well as other build configurations, which makes it easy to get information out of. Like CMake, this is a separate binary that has to be built for each platform. There doesn't seem to be any guarantees about the stability of the syntax, I've noticed when doing third party library updates that use gn that you have to carefully match gn revision to the version of the library you're using. I think that reduces the usability for consumers of icu4x.
• Meson: I haven't worked with this as much as the other alternatives in my list, which is maybe why I like it more. I think the syntax is tidy, it is installable as a Python, and it looks good from the easy of use / readability perspective, here's an example from dav1d: https://github.com/videolan/dav1d/blob/master/src/meson.build.

Of the five options I mentioned, I think Meson looks the most promising.

I haven't worked with scons before, I guess my only concern is how well it is being maintained since it is an older system.

I haven't worked with bazel before, that might be a good option as well. I think our use case here is building example and likely unit test code, so I don't think we need anything too complicated. There's a good chance that bazel will work out of the box without having to write rules, but maybe it is also overkill for our purposes.

[sffc]

2021-04-22:

• CMake and Meson have package ecosystems, which could be useful for consumers
• We probably want to use the same build system for both C and C++
• We want something fairly basic; one key feature is to support cargo features
• CMake and Meson are the finalists; we will now defer to the thing the team understands best