Imagine build system concept in preparation for choosing one #13
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here (e.g. What to do if you already signed the CLAIndividual signers
Corporate signers
|
andrewkeller
force-pushed
the
abk/buildsystem-concept/dev
branch
from
ad2bca4 to
5a62e13
Compare
|
CLAs look good, thanks! |
andrewkeller
force-pushed
the
abk/buildsystem-concept/dev
branch
from
5a62e13 to
64f4baf
Compare
| **Fully internal dependencies:** (ABK) Built an ad-hoc package manager (thin wrapper on top of `git clone`) into the project's configure stage so that the project can compile on any computer for any platform (within reason). This includes required 3rd party libraries, required 3rd party tools, you name it. Setting up a developer machine no longer requires any special work past SSH keys, a working compiler and such. | ||
|
|
||
|
|
||
| Bad experiences to avoid |
There was a problem hiding this comment.
I really like this section -- but I think there's a few more I could add. At a high level:
- Installing to a system location is hard.
- Embedding project in another project is also hard. Given for example a user would like to add the library to an existing project, doing this currently is super-hard.
There was a problem hiding this comment.
What characteristics do you see as being conducive to embedding inside another project?
In my organization, we have cpp-netlib pre-compiled by hand, and then committed in our package manager. The downside is that when we upgrade boost, we also need to recompile cpp-netlib. We don't upgrade boost often, so it's not a big deal.
What sort of interface do you imagine between cpp-netlib and other projects? Compile first and interface the compiled results with a dependent project, or interface cpp-netlib's source with a dependent project, and both are built at the same time?
| * Is maintainable by contributors given a reasonable learning curve | ||
|
|
||
|
|
||
| Good experiences to retain |
There was a problem hiding this comment.
I think one experience we might want to support is meeting the users where they are. If users are already using a particular package manager, it would be good for us to support them there.
In particular, if CMake is the overwhelming majority, we should at least support CMake. If Bazel is next in the list, we should have some support for it too. Whether we test and/or keep both in-sync is another question, but I think we can support more than one if we're clear about what the priorities are and who will be owning which ones we're supporting.
There was a problem hiding this comment.
Sounds like you think a survey is a good idea. I'll put one together.
| Definitions | ||
| ----------- | ||
|
|
||
| **Contributor:** Who is a contributor? Is there some base-level knowledge we can expect? |
There was a problem hiding this comment.
Contributor is someone who is sending a pull request.
Maintainer is a set of people that have had a track record to contribution, has volunteered to help with the project maintenance (tagging releases, updating the website, managing infrastructure, etc.).
Code Owner is a person who has responsibility for a sub-part of the overall project, and has approval rights to merge changes from non-code-owner contributors.
| | [Buck](https://en.wikipedia.org/wiki/Buck_(software)) | Facebook's internal build system | | Native integration with Xcode and IntelliJ | Native integration in only Xcode and IntelliJ | ||
| | [BuildAMation](https://en.wikipedia.org/wiki/BuildAMation) | | A modular build system using C#-like syntax | ||
| | [Buildr](https://en.wikipedia.org/wiki/Apache_Buildr) | | A Ruby-based competitor to Ant. | | | Intended primarily for Java projects | ||
| | [CMake](https://en.wikipedia.org/wiki/CMake) | | A cross-platform, modular wrapper around Make |
There was a problem hiding this comment.
My preference is this (CMake) would be the primary supported build system.
There was a problem hiding this comment.
FWIW, I agree. I don't have a preference of a secondary build system.
| | [A-A-P](https://en.wikipedia.org/wiki/A-A-P) | | Python-based package manager written by the author of vim. | Augmentable via scripting (python), supports uploading and downloading files | Not designed for building software | ||
| | [Ant](https://en.wikipedia.org/wiki/Apache_Ant) | "Another Neat Tool" | Java+XML-based build system | Widely used, straight-forward, relatively easy to read if you don't know Ant. | Build specification file is not as powerful as other options here; extensions required if you want to improve things.<br />Non-Java languages feel second-class<br />Ant extensions are developed using a different SDK than the main build specification file.<br /> | ||
| | [Autoconf](https://en.wikipedia.org/wiki/Autoconf) & [Automake](https://en.wikipedia.org/wiki/Automake) | auto wrappers on top of make | Automates the creation of Makefiles for C-based projects | Widely used | Complexity, difficult to debug | ||
| | [Bazel](https://en.wikipedia.org/wiki/Bazel_(software)) | Anagram of Blaze, Google's internal build system | Java-based Build system using Skylark (flavor of Python)-based configuration files for describing the build | Parallel by default, supported by Google, (computer) language-agnostic. Repeatable, scalable builds<br />Xcode support: bypasses Xcode to an extent; builds various Apple components manually |
There was a problem hiding this comment.
My preference is this would be a secondary system to support.
| | [Buildr](https://en.wikipedia.org/wiki/Apache_Buildr) | | A Ruby-based competitor to Ant. | | | Intended primarily for Java projects | ||
| | [CMake](https://en.wikipedia.org/wiki/CMake) | | A cross-platform, modular wrapper around Make | ||
| | [Gradle](https://en.wikipedia.org/wiki/Gradle) | | | | Intended primarily for Java, Groovy, and Scala | ||
| | [GYP](https://en.wikipedia.org/wiki/GYP_(software)) | Written by Google; used by Chrome and NodeJS | Native IDE project file generator. Used by the V8 Javascript engine, Google's web browser (Chrome), Dart (programming language), Node.js, WebRTC Telegram, and Electron. |
There was a problem hiding this comment.
GYP is now deprecated (I think) in favour of GN -- (link) which personally is tied with Bazel support as ranked in my head.
|
Putting this to sleep because I'm not making progress fast enough. I'll re-open if I change my mind. |
Existing work in progress for some thoughts on the build system.
This document is not ready to merge because it is missing too much information. I'm hoping that either Dean or Glyn may be open to contributing some thoughts. Help in any area is appreciated, but my current focus is the "good experiences" and "bad experiences" sections.
After this document becomes nicely fleshed out, I want to move forward with choosing a system. My instinct says to pick 2 or 3 to prototype, and then choose what feels best based on the prototype. I'm not sure exactly what happens to this PR; whether it should be merged, rewritten, or closed; we can discuss that later.
I've been waffling back and forth about whether or not to conduct a public survey to help guide this, and I've decided that that's likely not worth the time at this point. Based on prior experience, this project is small enough that a full rewrite of the entire build system is cheap enough that the experience gained from making wrong choices is more valuable than spending more time to make better choices up-front. That said, that doesn't mean that we shouldn't put our heads together and at least try. 😄
Because I want the concept document to only contain information that's more or less complete, it doesn't include unsubstantiated personal opinions. However, in case you're curious, here's my unsubstantiated personal opinions: