-
Notifications
You must be signed in to change notification settings - Fork 76
Conversation
Factor out into an opencensus_lib() function.
On case insensitive systems like Windows.
Two comments from @coryan that weren't resolved on the commit:
|
|
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.
Generally it looks good, some suggestions that you can ignore if they make no sense.
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
|
||
# add_subdirectory(grpc) TODO |
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.
Instead of using grpc
as a subdirectory consider using it via externalproject_add
like you do for Abseil. That way you do not get their targets in your namespace, and you would be testing a configuration that more closely resembles what you get via find_package()
.
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 agree.
But this is examples/grpc/
which is a hello world client + server.
I haven't gotten as far as adding the grpc integration yet. It will probably happen in a followup PR.
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
|
||
if(BUILD_TESTING) |
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.
Why not use externalproject_add()
for googletest 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.
I thought I was. If BUILD_TESTING is enabled, I do the usual dance starting on L19 with configure_file
, which uses cmake/googletest.CMakeLists.txt
which has the externalproject_add()
call.
It works with more CMake generators.
Hi, This is great, thank you for working on this! :) I have experimented with adding opencensus-cpp to vcpkg and building it. Currently only static opencensus-cpp configurations are supported. I then use vcpkg's version of gtest and abseil, both of which are included with find_package. I have made some changes:
I would like to:
How do you feel about this? Which changes are you willing to merge? :) |
Shouldn't that be
👍 |
Ah, you're right, of course, thanks :) I'm reading up on modern cmake to be able to contribute here, and I overlooked this function. I think that the distinction between PRIVATE and PUBLIC library link dependencies from each target is needed for this to make sense, though. (I can do this if there is interest, but I want to know which changes are acceptable to you first - see previous reply/message) |
Awesome!
This is great, opencensus-cpp needs to support
I'd definitely like Benchmark support (I think there's a TODO for it). Is there an ExternalProject version of this for people who don't use vcpkg?
I think part of this is done, at least with respect to which libraries we expose in the ::namespace, right?
I don't know enough about CMake yet to be able to make an informed decision here, let's discuss it.
This sounds great, and I'm willing to consider all of it. I'm going to have some questions about some of the changes. If I merge this PR soon, would you be willing to send PRs for the stuff above? |
Great, I'll send PRs for the changes when this is merged, and we can discuss each change separately (and in more detail) :) |
I'm wondering if using object libraries for some of the targets/components would be more appopriate? There are quite a lot of libraries (.lib) generated on build. What do you think? ref. https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/Object-Library |
@meastp @g-easy should we move this discussion to a separate bug?
If you folks decide to use object libraries remember that position-indepedent code is not enabled by default for them: https://cmake.org/cmake/help/v3.13/prop_tgt/POSITION_INDEPENDENT_CODE.html You have to explicitly set the property if you are building them into shared objects. My recommendation is that you make the first round of changes you proposed, and do the object library changes (if @g-easy approves) afterwards. |
Sure, I'm just wondering if there is another way to structure the targets that do not result in so many library files (especially for shared library builds). I'm not opposed to delaying that discussion 'till after the rest of the changes. If there are better ways to achieve this goal / other best practices that should be followed, I'm eager to learn about them. :) |
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.
Ship it.
This is addressing issue #86
Rolling my changes up as a PR to make reviews easier.