-
Notifications
You must be signed in to change notification settings - Fork 82
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
Simplify build commands, update readme #583
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -35,13 +35,13 @@ Goal: SDK size <= 1 MB and combined resources (object detection + regression mod | |
|
||
## Quick Start (i.e., How do I make this library work?) | ||
|
||
Drishti is a [CMake](https://github.com/kitware/CMake) based project that uses the [Hunter](https://github.com/ruslo/hunter) package manager to download and build project dependencies from source as needed. Hunter contains [detailed documentation](https://docs.hunter.sh/en/latest), but a few high level notes are provided here to help orient first time users. In practice, some working knowledge of CMake may also be required. Hunter itself is written in CMake, and is installed as part of the build process from a single `HunterGate()` macro at the top of the root `CMakeLists.txt` file (typically `cmake/Hunter/HunterGate.cmake`) (you don't have to build or install it). Each CMake dependency's `find_package(FOO)` call that is paired with a `hunter_add_package(FOO CONFIG REQUIRED)` will be managed by Hunter. Additional configuration (i.e., custom version and/or CMake arguments) can be performed for each package with an optional `hunter_config(FOO VERSION 1.0.0 CMAKE_ARGS ${FOO_CMAKE_ARGS}))` call in an optional local config file that is specified in the `HunterGate()` call. In most cases, the only system requirement for building a Hunter project is a recent CMake with CURL support and a working compiler correpsonding to the operative toolchain. | ||
Drishti is a [CMake](https://github.com/kitware/CMake) based project that uses the [Hunter](https://github.com/ruslo/hunter) package manager to download and build project dependencies from source as needed. Hunter contains [detailed documentation](https://docs.hunter.sh/en/latest), but a few high level notes are provided here to help orient first time users. In practice, some working knowledge of CMake may also be required. Hunter itself is written in CMake, and is installed as part of the build process from a single `HunterGate()` macro at the top of the root `CMakeLists.txt` file (typically `cmake/Hunter/HunterGate.cmake`) (you don't have to build or install it). Each CMake dependency's `find_package(FOO)` call that is paired with a `hunter_add_package(FOO CONFIG REQUIRED)` will be managed by Hunter. Additional configuration (i.e., custom version and/or CMake arguments) can be performed for each package with an optional `hunter_config(FOO VERSION 1.0.0 CMAKE_ARGS ${FOO_CMAKE_ARGS}))` call in an optional local config file that is specified in the `HunterGate()` call. In most cases, the only system requirement for building a Hunter project is a recent CMake with CURL support and a working compiler correpsonding to the operative toolchain. Hunter will maintain all dependencies in a [versioned](https://docs.hunter.sh/en/latest/overview/customization.html) local [cache](https://docs.hunter.sh/en/latest/overview/shareable.html) by default (typically `${HOME}/.hunter`) where they can be reused in subsequent builds and shared between different projects. They can also be stored in a server side [binary cache](https://docs.hunter.sh/en/latest/overview/binaries.html). | ||
|
||
The [Travis](https://github.com/elucideye/drishti/blob/master/.travis.yml) (Linux/OSX/iOS/Android) and [Appveyor](https://github.com/elucideye/drishti/blob/master/appveyor.yml) (Windows) CI scripts in the project's root directory can serve as a reference for basic setup when building from source. To support cross platform builds and testing, the CI scripts make use of [Polly](https://github.com/ruslo/polly): a set of common CMake toolchains paired with a simple `polly.py` CMake build script. Polly is used here for convenience to generate `CMake` command line invocations -- it is not required for building Hunter projects. | ||
|
||
To reproduce the CI builds on a local host, you must install `CMake` and `Polly` and add the paths for the `cmake` and `polly.py` executables to your system's `PATH` variable. The `bin/hunter_env.{sh,cmd}` scripts (used in the CI builds) can be used to install these tools for you in your local terminal. You may want to add the `PATH` variables permanently to your `.bashrc` file (or equivalent) for future sessions. | ||
|
||
Linux/OS X: | ||
Linux/OSX: | ||
``` | ||
source bin/hunter_env.sh | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now it can be:
? By the way "Install CMake" includes not only CMake but the real build tools and compiler. So probably this page can be helpful: http://cgold.readthedocs.io/en/latest/first-step.html There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the bullet list as a high level description.
Perfect. I'll add a link appropriately in the text. |
||
``` | ||
|
@@ -51,22 +51,38 @@ Windows: | |
bin\hunter_env.cmd | ||
``` | ||
|
||
After the environment is configured, you can build for any supported `Polly` toolchain (see `polly.py --help`) using the `bin/drishti_build.{sh,cmd}` scripts. | ||
After the environment is configured, you can build for any supported `Polly` toolchain (see `polly.py --help`) with a command like this: | ||
|
||
Linux/OS X: | ||
``` | ||
TOOLCHAIN=osx-10-11-hid-sections-lto | ||
CONFIG=Release | ||
INSTALL=--install | ||
bin/drishti_build.sh "${TOOLCHAIN}" "${CONFIG}" "${INSTALL}" | ||
polly.py --toolchain ${TOOLCHAIN} --config ${CONFIG} --fwd HUNTER_CONFIGURATION_TYPES=${CONFIG} --install --verbose | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess first time user is not interested in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think |
||
``` | ||
|
||
You can override the default CMake options in the project by adding KEY=VALUE pairs to a forwarded list like this `--fwd DRISHTI_SOME_OPTION1=YES DRISHTI_SOME_OPTION2=YES`. The `--fwd HUNTER_CONFIGURATION_TYPES=${CONFIG}` option is specified above to limit the Hunter package builds to a single configuration type (typically Release) when using multi-configuration generators (Visual Studio, Xcode, etc). It is not required for standard `clang` or `gcc` builds. | ||
|
||
The configurations listed below have all been tested. In general, most C++11 toolchains should work with minimal effort. A CI comment indicates that the configuration is part of the Travis or Appveyor CI tests, so all Hunter packages will be available in the server side binary cache. | ||
|
||
Linux (Ubunty Trusty 14.04): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess we can save some space by omitting There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could go either way on this. The There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Okay, I see it now. |
||
* TOOLCHAIN=gcc-5-pic-hid-sections-lto CONFIG=Release # CI | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess |
||
* TOOLCHAIN=libcxx CONFIG=Release # w/ clang 3.8 | ||
|
||
OSX: | ||
* TOOLCHAIN=osx-10-11-hid-sections-lto CONFIG=Release # CI | ||
* TOOLCHAIN=osx-10-12-sanitize-address-hid-sections CONFIG=Release # CI | ||
* TOOLCHAIN=xcode-hid-sections CONFIG=Release # generic | ||
|
||
iOS: | ||
* TOOLCHAIN=ios-nocodesign-10-1-arm64-dep-9-0-device-libcxx-hid-sections-lto CONFIG=MinSizeRel # CI | ||
* TOOLCHAIN=ios-10-1-arm64-dep-8-0-hid-sections CONFIG=Release | ||
|
||
Android (from OSX): | ||
* TOOLCHAIN=android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections CONFIG=MinSizeRel # CI | ||
* TOOLCHAIN=android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections-lto CONFIG=MinSizeRel | ||
|
||
Windows: | ||
``` | ||
set TOOLCHAIN vs-14-2015-win64-sdk-8-1 | ||
set CONFIG Release | ||
bin\drishti_build.cmd %TOOLCHAIN% %CONFIG% | ||
``` | ||
* TOOLCHAIN=vs-14-2015-sdk-8-1 CONFIG=Release # CI | ||
* TOOLCHAIN=vs-14-2015-sdk-8-1 CONFIG=Debug # CI | ||
* TOOLCHAIN=vs-14-2015-win64-sdk-8-1 CONFIG=Release # CI | ||
* TOOLCHAIN=vs-14-2015-win64-sdk-8-1 CONFIG=Debug # CI | ||
|
||
The polly out of source build trees are located in `_builds/${TOOLCHAIN}`, the final build products (the stuff you want) are installed in `_install/${TOOLCHAIN}`, and the build logs are dumped in `_logs/${TOOLCHAIN}`. The iOS frameworks are installed in `_frameworks/${TOOLCHAIN}`. | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,7 +17,7 @@ python %POLLY_ROOT%\bin\polly.py ^ | |
--config "%1%" ^ | ||
--toolchain "%2%" ^ | ||
--test ^ | ||
--fwd HUNTER_USE_CACHE_SERVERS=NO ^ | ||
--fwd HUNTER_USE_CACHE_SERVERS=YES ^ | ||
HUNTER_DISABLE_BUILDS=NO ^ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This script was added based on issue discussions to provide an easy option for local host builds. Once cmake defaults + documentation is cleaned up I think it can be removed (along with some others). It isn't actually used right now in appveyor.yml. The appveyor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok |
||
DRISHTI_COPY_3RDPARTY_LICENSES=ON ^ | ||
DRISHTI_BUILD_TESTS=ON ^ | ||
|
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.
Not sure why user may need to know this.
Info is here:
Probably should be moved to "Quick start: Tools".
Not very informative. How it can be helpful for the first time user?
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 think that makes sense. That is probably more critical for creating a new project. I'll cut this (in line w/ preference for bare bones description that doesn't duplicate Hunter docs too much).
I'll link this. I think it is important to keep it in the "setup" notes. I believe the default Ubuntu 16.04 doesn't have CURL support, for example. (I'll incorporate feedback and update via direct README.md commit after the merge.)
In the toolchain discussion, the CI builds + cache are mentioned. I think it is important to introduce the idea of a binary cache so the user understands the pre-built packages are downloaded from a server. Maybe a little more information could help.
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 pretty sure it has. The CURL support issue (OpenSSL support to be precise) usually about manually compiled CMake.
Okay, I see. However not all of them are "stable", e.g.
xcode-hid-sections
.