>
> I don't get how this is a cycle. It only means Bazel is too limited to
> distinguish between a header dependency and a C++ module?
Agreed, this isn't a true cycle, but bazel is opinionated about this (i.e.
forces workarounds). In the example I highlighted it might have been
cleaner to take
Le 27/11/2019 à 06:16, Micah Kornfield a écrit :
>
>> 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?
>
> I think the type_fwd.h might contribute to the problem. The solution would
> be more gr
Hi Antoine,
> 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?
In the short term, I would be will to be a dedicated m
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
As previously discussed [1], I took on the effort the effort of trying to
come up with a demo for using bazel as a build system for C++/Python. The
results [2] are a little bit of a mixed bag.
I was able to construct an example that runs on my Mac that can compile and
run most of the tests in "sr
