-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Separate dependencies for configurable installation #2523
Conversation
Instead of adding patches fixing your own mistakes, squash multiple patches in one patch and force push to your branch to update the PR. |
/cc @Nerei |
if(USE_LMDB) | ||
caffe_status(" lmdb : " LMDB_FOUND THEN "Yes (ver. ${LMDB_VERSION})" ELSE "No") | ||
endif() | ||
if(USE-SNAPPY) |
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.
typo
This PR doesn't generate proper CaffeConfig.cmake. All such definitions should be propagated to client code too. |
@Nerei thanks for the many helpful suggestions. Working on this. |
@Nerei the forward declaration of cv::Mat would not be helpful since cv:Mat will not be available at runtime? |
@eelstork Agree. If user try to call opencv dependent method, it will get link errors. Well this is all up to code organization. In general, It's preferable to hide as much as possible Regarding commit c5ebe85, I think it should be reverted. Such config should be included into each header (otherwise that defines are always undefined) but it is not generated by Make. I put my comment above and then disproved it. |
@Nerei please have a look at the generated CaffeConfig.cmake; if this is not appropriate, I welcome suggestions to improve it. |
Pending further feedback, standing by. |
Please squash the patches, it's difficult to review right now. |
Fine with CaffeConfig.cmake |
@eelstork Can you rebase and squash? |
@shelhamer @bhack @flx42 @eelstork |
@shelhamer @keenbrowne ready for review/merge. |
USE_HDF5 := 1 # {IO-flag} | ||
USE_OPENCV := 1 # {IO-flag} | ||
USE_SNAPPY := 1 # {IO-flag} | ||
|
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.
The trailing comments (# {IO-flag}) might cause problems for value evaluation.
@eelstork Have you tested if with this new modularity can build with androd-cmake: https://github.com/taka-no-me/android-cmake/blob/master/README.md? |
@sh1r0 This add also apk generation capabilties: https://github.com/Discordia/android-cmake |
Removed trailing comments in makefile.config. Thanks to @sh1r0 for the suggestion. |
@bhack No, I haven't; nor do I know whether it was possible before? Although we hope that removing the dependencies will help porting Caffe to other platforms, I believe that compatibility with a specific platform/config should be addressed separately. |
@eelstork Yes of course. I've asked only if somebody tested it with this modularization to know now if could be any other modularization that could improve the process with android NDK. |
@jeffdonahue @shelhamer What do you think of the related #2619? |
@shelhamer and @jeffdonahue thanks for these suggestions, I have made changes accordingly (see relevant commits); squash? |
@shelhamer Thanks! Before letting go, I suggest we drop the option to explicitly enable/disable snappy. This is because caffe does not directly depend on Snappy, instead, it is LevelDB that requires it. Where build scripts relied on associate flag, USE_LEVELDB would be used instead. Intending to push a commit to illustrate proposed solution. |
@shelhamer @jeffdonahue @bhack @Nerei, opinions about 58f017e ? |
@shelhamer - updated; squashed. |
@shelhamer Anything missing to get this merged? |
@eelstork I took another look -- sorry for the last minute comments. Otherwise looks good for merge to me. |
OpenCV, LMDB, LevelDB and Snappy are made optional via switches (USE_OPENCV, USE_LMDB, USE_LEVELDB) available for Make and CMake builds. Since Snappy is a LevelDB dependency, its use is determined by USE_LEVELDB. HDF5 is left bundled because it is used for serializing weights and solverstates.
@jeffdonahue updated. I would suggest leaving 2349c6d as a separate commit. |
Thanks @eelstork! |
Separate dependencies for configurable installation
@jeffdonahue Can you take a look at related #2619? |
@mtngld thanks for pointing this out. @jeffdonahue thoughts on making all IO on by default for backwards compatibility? The Makefile.config / CMake can then explicitly disable dependencies as desired. That seems reasonable to me. |
Oops, I didn't realize this changed the default to no IO dependencies. Yes, I agree the default should be to have them all enabled as before. |
Currently it is not possible to disable leveldb and lmdb (at least on Windows) which would be useful to use Caffe for deployment only. |
@danst18 I believe that disabling LevelDB and LMDB is possible on Windows (via CMake), granted that building caffe on Windows does require tweaks. What motivates your comment? |
@eelstork I mean when both of them are disabled at the same time. In db.cpp I get an error saying that GetDB should return a value. If I remove db.h and db.cpp then I have to add guards to other parts of the code where they are referenced, for example in data_reader.cpp |
@danst18 sorry for the late reply. I submitted a fix for this. Thank you for reporting the issue. |
Addresses #1738.
The PR benefited earlier attempts by @cypof (#2402) and @kloudkl (#1074).
Options provided include USE_OPENCV, USE_LMDB, USE_LEVELDB, USE_HDF5, USE_SNAPPY, with both make and CMake flags available.
This allows selecting which IO libraries to build with. Wherever possible functions that would behave incorrectly as a result of disabling a library are excluded before runtime.
Added two items to the test matrix:
- WITH_CUDA=false WITH_CMAKE=false WITH_IO=false
- WITH_CUDA=false WITH_CMAKE=true WITH_IO=false
Without bloating the test matrix, it is essential to have at least one of these, otherwise correct separation of these dependencies would be unmaintainable.