Hi Micah,
Le 26/11/2019 à 05:52, Micah Kornfield a écrit : > > After going through this exercise I put together a list of pros and cons > below. > > I would like to hear from other devs: > 1. Their opinions on setting this up as an alternative system (I'm willing > to invest some more time in it). > 2. What people think the minimum bar for merging a PR like this should be? My question would be: what happens after the PR is merged? Are developers supposed to keep the Bazel setup working in addition to CMake? Or is there a dedicated maintainer (you? :-)) to fix regressions when they happen? > Pros: > 1. Being able to run "bazel test python/..." and having compilation of all > python dependencies just work is a nice experience. > 2. Because of the granular compilation units, it can improve developer > velocity. Unit tests can depend only on the sub-components they are meant > to test. They don't need to compile and relink arrow.so. > 3. The built-in documentation it provides about visibility and > relationships between components is nice (its uncovered some "interesting > dependencies"). I didn't make heavy use of it, but its concept of > "visibility" makes things more explicit about what external consumers > should be depending on, and what inter-project components should depend on > (e.g. explicitly limit the scope of vendored code). > 4. Extensions are essentially python, which might be easier to work with > then CMake Those sound nice. > Cons: > 1. Bazel is opinionated on C++ layout. In particular it requires some > workarounds to deal with circular .h/.cc dependencies. The two main ways > of doing this are either increasing the size of compilable units [4] to > span all dependencies in the cycle, or creating separate > header/implementation targets, I've used both strategies in the PR. One > could argue that it would be nice to reduce circular dependencies in > general. Can you give an example of circular dependency? Can this be solved by having more "type_fwd.h" headers for forward declarations of opaque types? (also, generally, it would be desirable to use more of these, since our compile times have become egregious as of late - I'm currently considering replacing my 8-core desktop CPU with a beefier one :-/) > 4. It is more verbose to configure then CMake (each compilation unit needs > to be spelled out with dependencies). This sounds really like a bummer. Do you have to spell those out by hand? Or is there some tool that infers dependencies and generates the declarations for you? Regards Antoine.
