First of all, thanks for deciding to contribute to gRPC!

To answer your questions:
- When it comes to building on linux, using the Makefile is currently our 
primary way to build gRPC. cmake support is not experimental, but it has 
more importance on other platforms (like Windows), where you can't really 
use Makefile to build (on linux, cmake can be useful if you're 
crosscompiling for a different plaform)
- It is possible that our Makefile and CMakeLists.txt are not fully in sync 
in terms of compilations options - like the problem you found. Most of the 
times, this is not intended and the builds should be as similar as is 
reasonably possible (as these are basically just two ways of building the 
same thing). Because Makefile 
is currently our primary way of building on Linux, usually its compilation 
options for linux will be a bit more fine-tuned. In this case, you're 
welcome to create a PR that adds the -fno-exceptions to our cmake linux 
build as well.
- In the future, bazel will become the primary way to build gRPC (at least 
that's the plan), but we're not quite there yet.
- we know there are some flaws to our current cmake solution (see issue 
tracker) and we are working on fixing them, but most of them are windows 
related - as cmake is the primary way of building gRPC on Windows.

Hope this helps,
Jan



On Sunday, November 12, 2017 at 11:19:40 PM UTC+1, Tomasz Mikolajczyk wrote:
>
> Hi,
>
> At the beginning I would like to admit that grpc is a very nice RPC 
> solution. I'm looking for some areas when I could contribute to that 
> project.
>
> I've found various issues in the  implementation of DynamicThreadPool 
> class (grpc/src/cpp/server/dynamic_thread_pool.*) and I've prepared a new 
> straightforward and intuitive (IMHO!) implementation of that class + unit 
> tests.
> I compiled grpc with cmake (archlinux, gcc 7.2) and all was fine. 
> Following documentation about running unit tests I've executed:
>
> $ python2 ./tools/run_tests/run_tests.py -l c++ 
>
> And only then I noticed that unit tests build uses *-fno-exceptions* flag 
> in opposite to cmake build where that flag is not used (so exceptions are 
> allowed).
> Most of the issues found in the DynamicThreadPool concern the case when 
> exceptions are enabled. But still there are issues even when the exceptions 
> are disabled (for instance in case when memory allocation fails). 
>
> Why different compiler flags are used? Should cmake build be considered as 
> an experimental feature of grpc?
>
> /Tomek
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/d3dc84fa-2f20-485c-b263-cee9ae97ecf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to