-
Notifications
You must be signed in to change notification settings - Fork 5
Fix -DHUNTER_ENABLED=0 builds #3
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3 +/- ##
=======================================
Coverage 79.54% 79.54%
=======================================
Files 34 34
Lines 3568 3568
=======================================
Hits 2838 2838
Misses 730 730 Continue to review full report at Codecov.
|
.gitignore
Outdated
@@ -1 +1,4 @@ | |||
/build | |||
DartConfiguration.tcl | |||
/CMakeFiles | |||
/CMakeCache.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For these two directories, please remove the leading slash. This pattern only matches ${SRC_ROOT}/CMakeFiles
but not ${SRC_ROOT}/build/CMakeFiles
. Usually I use mkdir build && cd build && cmake ..
to keep the build in its own directory, so it made sense to ignore the whole build directory in the source root. However, it seems like you are building in the source tree. Might as well just ignore all of the CMake generated files no matter where they are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can actually replace this entirely with this: https://github.com/github/gitignore/blob/master/CMake.gitignore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add this and any generated files you can find: https://github.com/github/gitignore/blob/master/C.gitignore.
sudo dnf install jansson-devel http-parser-devel protobuf-c-devel \ | ||
protobuf-c-compiler | ||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I haven't tested HUNTER_DISABLED=ON
in a while, so I should double-check this still works.
Codecov Report
@@ Coverage Diff @@
## master #3 +/- ##
==========================================
+ Coverage 79.2% 79.56% +0.36%
==========================================
Files 31 34 +3
Lines 3635 3572 -63
==========================================
- Hits 2879 2842 -37
+ Misses 756 730 -26
Continue to review full report at Codecov.
|
@isaachier I've dropped the gitignore commit from the series, and I think otherwise it should be fine to merge. |
Actually hold on this, needs more work first |
There were a number of case sensitivity issues in the CMake files relating to differing case between the Hunter files and the ones in cmake/ (isaachier#1) Also fixes finding of the protocol buffers support when protobuf 1.2 is present (isaachier#4)
I've removed the gitignore changes, added a fix to make it compile on protobuf-c 1.2, fixed some more issues with case in the CMake files, and rebased on top of 49513a5. It now configures fine here with |
- clang-4.0 | ||
env: | ||
- MATRIX_EVAL="CC=clang-4.0 && CXX=clang++-4.0" | ||
#DISABLED to reduce the matrix a bit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming this is for your own testing. In practice, we can add an additional matrix entry (probably one will suffice) that will test HUNTER_ENABLED=0
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is, but actually I don't see the benefit of the build matrix being so dense for all builds. Unless you're chasing a very specific compiler bug of regression it seems oddly broad. Much more useful to add an osx target at some point instead.
@@ -113,19 +113,24 @@ if(HUNTER_ENABLED) | |||
hunter_add_package(Protobuf) | |||
find_package(Protobuf ${hunter_config} REQUIRED) | |||
list(APPEND package_deps Protobuf) | |||
set(protoc_exe protobuf::protoc) | |||
else() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how do we generate the messages? How do we connect to backend at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will have seen the answer to that further down, guessing this is outdated. It's just a change in how the IDL is compiled by cmake.
message(STATUS "using protoc and protoc-gen-c") | ||
set(protoc_exe $<TARGET_FILE:protobuf::protoc>) | ||
set(protoc_plugin_arg --plugin=$<TARGET_FILE:protobuf-c::protoc-gen-c>) | ||
elseif(TARGET protobuf-c::protoc-c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can fix this issue by using protoc-c
directly. I found that I had issues doing this with the Hunter version of protoc-c
, so I used an invocation of protoc
that loaded the protoc-gen-c
plugin. If Hunter is disabled, I can try using protoc-c
directly instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I did in an earlier revision, but there turns out to be no point. protobuf-c 1.3 adds protobuf-gen-c
and is also the oldest version that supports "proto3". So in practice there's a hard requirement on 1.3 and you can just rely on doing it this way.
It's silly that Hunter doesn't expose a protobuf-c::protoc-c
target, but in this case it wouldn't help us.
Install the project library dependencies. On Debian, the following command | ||
should work. | ||
By default the client build will fetch all dependencies from the Hunter | ||
build dependency system. Only cmake must be installed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
||
On older Fedora releases, RHEL, and CentOS, protobuf-c-devel | ||
protobuf-c-compiler are too old and must be installed from source, custom | ||
packages, or a backport repository instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:) excellent!
git submodule update --init | ||
mkdir -p build | ||
cd build | ||
cmake .. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just minor suggestion: cmake -DCMAKE_BUILD_TYPE=Release ..
or Debug
.
set_target_properties(Jansson::Jansson PROPERTIES | ||
if(JANSSON_FOUND AND NOT TARGET jansson::jansson) | ||
add_library(jansson::jansson UNKNOWN IMPORTED) | ||
set_target_properties(jansson::jansson PROPERTIES |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic! The casing can be annoying, but that seems to be the correct fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very. CMake could at least offer a "hint" message of some kind. "Target Jansson::Jansson not found (but there's a jansson::jansson, did you mean that?"
|
||
if [ "${USE_HUNTER:-}" == "off" ]; then | ||
# We won't be using Hunter so we need to get opentracing's c library | ||
# installed too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would you prefer I handle this dependency to support non-Hunter builds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure yet, thinking about that. It depends a lot on whether you think apps would expect to link to opentracing-c
then load jaeger-client-c
at runtime, or if you see them linking to a jaeger-client-c
that implements the opentracing-c
APIs exposed in opentracing-c
headers.
(The build doesn't produce a shared library yet. I'll deal with that at some later stage, far from urgent.)
You've pushed opentracing-c to hunter, so I guess you see it working more like the former? The app links to opentracing-c, and it loads a tracing implementation at runtime? I haven't looked closely at this part yet, as I've just been trying to get the build to work.
No strong opinions here anyway. I anticipate I'll be treating it as a unit of opentracing-c + jaeger-client-c anyway.
make -j3 | ||
make check -j3 | ||
make install | ||
./configure --quiet --prefix="$prefix" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
* not much benefit when we're just generating request and span IDs, etc. | ||
*/ | ||
srand(time(NULL)); | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea.
Fixes #1