I'll add I don't think we will actually be switching anytime soon. bazel
does have some advantages at least over our current CMake system in terms
of developer productivity (users can target smaller components with unit
tests which avoid re linking). I've started on a prototype and hope to
have s
On Sun, Oct 20, 2019 at 12:22 PM Maarten Ballintijn wrote:
>
> Dev's
>
> I would request to be as conservative as possible in choosing (keeping) a
> build system.
>
> For developers, packagers and even end-users for some languages the build
> system is just
> another dependency. Even if cmake is
Dev's
I would request to be as conservative as possible in choosing (keeping) a build
system.
For developers, packagers and even end-users for some languages the build
system is just
another dependency. Even if cmake is not ideal, it has become quite ubiquitous
which is a huge plus.
Maybe it
>
> Perhaps meson is also worth exploring?
It could be, if someone else wants to take a look we can, compare what
things look at in each. Recently, Bazel build rules seem like they would be
useful for some work projects I've been dealing with, so I plan on focusing
my exploration there.
On Wed,
Perhaps meson is also worth exploring?
Le 15/10/2019 à 23:06, Micah Kornfield a écrit :
Hi Wes,
I agree on both accounts that it won't be a done in the short term, and it
makes sense to tackle in incrementally. Like I said I don't have much
bandwidth at the moment but might be able to re-arr
Hi Wes,
I agree on both accounts that it won't be a done in the short term, and it
makes sense to tackle in incrementally. Like I said I don't have much
bandwidth at the moment but might be able to re-arrange a few things on my
plate. I think some people have asked on the mailing list how they mi
hi Micah,
Definitely Bazel is worth exploring, but we must be realistic about
the amount of energy (several hundred hours or more) that's been
invested in the build system we have now. So a new build system will
be a large endeavor, but hopefully can make things simpler.
Aside from the requiremen
>
>
> This might be taking the thread on more of a tangent, but maybe we should
start collecting requirements for the C++ build system in general and see
if there might be better solution that can address some of these concerns?
In particular, Bazel at least on the surface seems like it might be a
Yes, we could express dependencies in a Python script and have it
generate a CMake module of if/else chains in cmake_modules (which we
would check in git to avoid having people depend on a Python install,
perhaps).
Still, that is an additional maintenance burden.
Regards
Antoine.
Le 10/10/20
I guess one question we should first discuss is: who is the C++ build
system for?
The users who are most sensitive to benchmark-driven decision making
will generally be consuming the project through pre-built binaries,
like our Python or R packages. If C++ developers build the project
from source
There's always the route of vendoring some library and not exposing
external CMake options. This would achieve the goal of
compile-out-of-the-box and enable important feature in the basic
build. We also simplify dependencies requirements (benefits CI or
developer). The downside is following securit
FWIW for perspective, we ended up just using our own Cmake file to build arrow,
we needed a minimal subset of functionality on a tight size budget and it was
easier doing that than configuring all the flags.
https://github.com/finos/perspective/blob/master/cmake/arrow/CMakeLists.txt
Tim Paine
Hi all,
I'm a bit concerned that we're planning to add many additional build
options in the quest to have a core zero-dependency build in C++.
See for example https://issues.apache.org/jira/browse/ARROW-6633 or
https://issues.apache.org/jira/browse/ARROW-6612.
The problem is that this is creati
13 matches
Mail list logo
