-
Notifications
You must be signed in to change notification settings - Fork 182
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
Comments
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? |
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>
.
|
There's also gyp, used in Node.js modules (and elsewhere) |
I meant "heavy" in the sense of being designed for larger projects and not very customizable (Ruby on Rails vs Sinatra). |
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
|
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.
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. |
2021-04-22:
|
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. |
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. |
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:
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).
The text was updated successfully, but these errors were encountered: