-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cover change with gtest unittests, clean up cmake script and code includes #106
Conversation
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.
Please use deterministic waiting and point me to some unittests.
@chenqin Can we use exponential backoff to ease congestion? Unlike random waiting, it will have deterministic behavior. |
removed random with expoential back off plus rank %10 to avoid ddos tracker |
working on googletest to support unittests |
@chenqin You can consider using gtest main: https://github.com/dmlc/xgboost/blob/master/tests/cpp/test_main.cc |
done |
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.
Will give a proper review tomorrow, one thing though, try find_package first then download gtest ...
I tried to use find_package along with exteranl project which doesn't ends well. |
@chenqin Let me try. |
Also, why is it necessary to download gtest? Can we assume that the developer can install gtest test somewhere? CMake accepts a parameter called |
Clean up CMake scripts. will work on a bit cleanup
@trivialfis let's get this in to unblock xgb CMake house cleaning |
done with cleanup, xgboost now build with rabit |
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.
we should avoid mixing things together, especially "cleanup/refactoring" and "new feature adding"
and the other thing I don't understand is. the description says "clear unused environment variables, accept those parameters as arguments" why it contains so many CMake file changes
removed from this pr, let's do back off in separate pr |
fixed, remvoed code change touch sleep, this pr focus on make it buildable with xgboost project and adding googletest backed unit tests |
@@ -0,0 +1,20 @@ | |||
# code copied from https://crascit.com/2015/07/25/cmake-gtest/ |
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.
Doesn't seem necessary anymore. I'm OK for keeping it here for the convenience of others.
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.
@trivialfis I added this because this was the easiest way to install Google Test on Windows platform. Sorry, I forgot that this PR is in Rabit. I added something like this in dmlc-core, and it's quite convenient. I suggest we keep it.
|
||
option(DMLC_ROOT "Specify root of external dmlc core.") | ||
# by default point to xgboost/dmlc-core | ||
set(DMLC_ROOT ${CMAKE_CURRENT_LIST_DIR}/../dmlc-core) |
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 spent so much effort on rabit I assume you don't want to make it XGBoost exclusive right? Since last time I check rabit is only using some headers from dmlc-core
, there's no linkage involved. So technically rabit can use dmlc-core in system path, say /usr/
or /home/chenqin/.local/
or any other directories that follow the bin/include/lib/lib64
pattern without any problem, and you can set above path as DMLC_ROOT
for your convenience. With this, you can simply throw an error if DMLC_ROOT is not specified.
In the future (not for this PR), I may add this to rabit as dmlc-core
has very good support for CMake target.
if (NOT DMLC_ROOT)
find_package(dmlc)
target_link_libraries(rabit dmlc::dmlc) # This line also handles include directory.
endif (NOT DMLC_ROOT)
ENDIF(R_LIB OR MINGW OR WIN32) | ||
|
||
if(RABIT_BUILD_MPI) | ||
find_package(MPI REQUIRED) | ||
if (NOT MPI_CXX_FOUND) | ||
message(FATAL_ERROR "CXX Interface for MPI is required for building MPI backend.") |
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 wrote this line, but do we actually want to support MPI backend? I thought it's a proof of concept for the paper. And now that the MPI CXX interface is deprecated, there will be some more works for bring it up. @chenqin What do you think?
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.
We might discuss this in another thread how to support MPI runtime. The rationale is there are lots of similar frameworks highly optimized such as facebook/gloo that just do MPI optimization. None of which offers failed single worker recover. But I don't have clear picture who is using rabit other than distributed XGBoost.
Other than the line making rabit XGBoost exclusive, LGTM. Since this PR is a whole with dmlc/xgboost#4876 , will merge them together. |
@chenqin Merged. You can focus on the jvm-package PR. ;-) |
And, a big thanks! |
* Clean up CMake scripts and related include paths. * Add unittests.
* Clean up CMake scripts and related include paths. * Add unittests.
This PR do two things
@trivialfis @hcho3