Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choose build system for C API example code #557

Open
dminor opened this issue Mar 17, 2021 · 9 comments
Open

Choose build system for C API example code #557

dminor opened this issue Mar 17, 2021 · 9 comments
Assignees
Labels
A-ffi Area: FFI, WebAssembly, Transpilation C-ffi-infra Component: Diplomat, horizontal FFI C-test-infra Component: Integration test infrastructure S-medium Size: Less than a week (larger bug fix or enhancement) T-core Type: Required functionality

Comments

@dminor
Copy link
Contributor

dminor commented Mar 17, 2021

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).

@dminor dminor added A-ffi Area: FFI, WebAssembly, Transpilation discuss Discuss at a future ICU4X-SC meeting labels Mar 17, 2021
@sffc
Copy link
Member

sffc commented Mar 18, 2021

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
Copy link
Contributor

filmil commented Mar 18, 2021 via email

@sffc
Copy link
Member

sffc commented Mar 18, 2021

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

@sffc
Copy link
Member

sffc commented Mar 18, 2021

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
Copy link
Contributor

filmil commented Mar 18, 2021 via email

@dminor
Copy link
Contributor Author

dminor commented Mar 18, 2021

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
Copy link
Member

sffc commented Apr 22, 2021

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

@sffc sffc added C-meta Component: Relating to ICU4X as a whole S-medium Size: Less than a week (larger bug fix or enhancement) T-core Type: Required functionality and removed discuss Discuss at a future ICU4X-SC meeting labels Apr 22, 2021
@sffc sffc added this to the ICU4X 0.3 milestone Apr 22, 2021
@sffc sffc self-assigned this Apr 22, 2021
@sffc sffc modified the milestones: ICU4X 0.3, 2021 Q2-m3 May 13, 2021
@sffc sffc added C-ffi-infra Component: Diplomat, horizontal FFI and removed C-meta Component: Relating to ICU4X as a whole labels Jun 16, 2021
@sffc sffc modified the milestones: 2021 Q3-m1, 2021 Q3 0.4 Sprint A Aug 11, 2021
@sffc
Copy link
Member

sffc commented Sep 13, 2021

I'm not going to have time for this in the current quarter. We don't have an urgent need at the current time, although we will need to address this problem at some point soon.

@sffc sffc modified the milestones: 2021 Q3 0.4 Sprint B, ICU4X 0.5 Sep 13, 2021
@sffc
Copy link
Member

sffc commented Jan 27, 2022

The short-term deliverable here is that we want our C/C++ examples to be runnable on Windows. We could have more broader build system support; see #1338.

@sffc sffc added the C-test-infra Component: Integration test infrastructure label Jan 27, 2022
@sffc sffc added the backlog label Jan 27, 2022
@sffc sffc assigned gnrunge and unassigned sffc Jan 27, 2022
@sffc sffc modified the milestones: ICU4X 0.5, ICU4X 0.6 Jan 27, 2022
@sffc sffc removed this from the ICU4X 0.6 milestone May 25, 2022
@sffc sffc added this to the Backlog milestone Dec 22, 2022
@sffc sffc removed the backlog label Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ffi Area: FFI, WebAssembly, Transpilation C-ffi-infra Component: Diplomat, horizontal FFI C-test-infra Component: Integration test infrastructure S-medium Size: Less than a week (larger bug fix or enhancement) T-core Type: Required functionality
Projects
None yet
Development

No branches or pull requests

4 participants