-
Notifications
You must be signed in to change notification settings - Fork 616
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
Add support for Bazel #898
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.
This all looks correct, I left some comments about possible copy/paste remnants from Seurat, and noted that it's probably a good idea to omit the header generation code.
BUILD.bazel
Outdated
) | ||
|
||
DEFINES = [ | ||
"DISABLE_GOOGLE_GLOBAL_USING_DECLARATIONS", |
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.
Is this intentional? My understanding is that this is set for the preprocessor when building OpenEXR, but that definition isn't part of OpenEXR's code.
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.
Fixed
BUILD.bazel
Outdated
":windows_x86_64": [ | ||
"NOGDI", # Don't pollute with GDI macros in windows.h. | ||
"NOMINMAX", # Don't define min/max macros in windows.h. | ||
"OS_WINDOWS=OS_WINDOWS", |
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.
Is this specific to the Seurat project?
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.
Fixed
BUILD.bazel
Outdated
"_WINDOWS", | ||
|
||
# Defaults for other headers (along with OS_WINDOWS). | ||
"COMPILER_MSVC", |
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.
Seurat?
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.
Fixed
BUILD.bazel
Outdated
"_USE_MATH_DEFINES", | ||
|
||
# Allows 'Foo&&' (e.g., move constructors). | ||
"COMPILER_HAS_RVALUEREF", |
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.
Seurat?
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.
Fixed
BUILD.bazel
Outdated
# Allows 'Foo&&' (e.g., move constructors). | ||
"COMPILER_HAS_RVALUEREF", | ||
|
||
# Doublespeak for "don't bloat namespace with incompatible winsock |
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 revise to "Improve compile times by enforcing inclusion of a minimal subset of windows.h"?
BUILD.bazel
Outdated
) | ||
|
||
cc_binary( | ||
name = "dwaLookups", |
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.
last year, we checked in the secondary generated files, so this generation step should not be necessary. Omitting is probably better to reduce the maintenance footprint.
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.
Fixed
BUILD.bazel
Outdated
) | ||
|
||
cc_binary( | ||
name = "b44ExpLogTable", |
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.
last year, we checked in the secondary generated files, so this generation step should not be necessary. Omitting is probably better to reduce the maintenance footprint.
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.
Fixed
BUILD.bazel
Outdated
) | ||
|
||
genrule( | ||
name = "dwaLookupsAutoGen", |
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.
last year, we checked in the secondary generated files, so this generation step should not be necessary. Omitting is probably better to reduce the maintenance footprint.
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.
Fixed
BUILD.bazel
Outdated
) | ||
|
||
genrule( | ||
name = "b44ExpLogTableAutoGen", |
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.
last year, we checked in the secondary generated files, so this generation step should not be necessary. Omitting is probably better to reduce the maintenance footprint.
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.
Fixed
################################################################################ | ||
# Build the IlmImf library | ||
ilm_imf_path = "OpenEXR/IlmImf/" | ||
|
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.
This assumes the old code arrangement with various libraries in IlmBase, and the source for the OpenEXR library in IlmImf, instead of src/lib/OpenEXR. Would it be better to revise the build config so it works with the current master branch?
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.
Fixed
Thank you for the contribution. We discussed this in the Technical Steering Committee meeting. Support for Bazel is a helpful service to the community, although none of the current OpenEXR maintainers have any experience with Bazel or use it regularly. We only recently settled on CMake as the official build system and retired the gnu/autotools configuration. Besides getting this PR fixed as noted above, we're concerned about the ongoing maintenance and support burden. Whenever we make changes to the build setup in the future (add/move/rename a file, etc), someone will need to change, and test, the Bazel build. Will someone in the user community who uses Bazel commit to providing support for it going forward? At the very least, before we agree to take this on we'd like to see this integrated into our CI, so that it's tested. An alternative that we discussed would be providing these files in the "Contrib" folder as example code that others can start from, but not necessarily something expected to work reliably. |
I rewrote most of the PR and did this time not base my work on seurat. The dependency tree now looks like this: A added a CI workflow that can make sure that Bazel build does work. Please review again. Here is a demo that shows you what is needed to consume OpenEXR as C++ Bazel developer:
Note: Under the hood (openexr_deps()) will fetch zlib and Imath. This nice solution will work if the PR is added to the master branch. If this stuff is moved to "Contrib" folder the above example will not work. In this case, a bit different solution is needed. I would suggest adding this PR to the master (and making the bazel build check "non-voting" = does not block changes if Bazel build breaks - only works as a type of indicator) - then let's see how this works out for the next few weeks/months. I would assume that developers who want to make use of OpenEXR and Bazel will contribute to this project. If this does not work out the Bazel files can still be moved to the "Contrib" folder. |
I am willing to support the Bazel build support of OpenEXR for a half year - after this period I can reconsider doing it for another half year - I have also some semi-automation in place on my side to support this task (details here) |
We discussed this in the steering committee meeting again and decided to accept the contribution, with @Vertexwahn's offer of support and maintenance, thank you. The CI builds are failing, for reasons that seem unrelated to your changes here, but the tests seems to have run on some outdated files. Can you merge the master branch into this and let's confirm the CI checks pass? Thanks. |
Reimplemented bazelization for OpenEXR from scratch Signed-off-by: Vertexwahn <julian.amann@tum.de>
Signed-off-by: Vertexwahn <julian.amann@tum.de>
Signed-off-by: Vertexwahn <julian.amann@tum.de>
Signed-off-by: Vertexwahn <julian.amann@tum.de>
Signed-off-by: Vertexwahn <julian.amann@tum.de>
Signed-off-by: Vertexwahn <julian.amann@tum.de>
…st) to Bazel Signed-off-by: Vertexwahn <julian.amann@tum.de>
I did a rebase - looking forward to getting this merged |
Thanks! |
This PR helps users of the Bazel build system to integrate openexr in their builds.
Supporting two build systems (CMake and Bazel) is of course more effort to maintain but helps to spread openexr.
In the worst case the Bazel build does simply not work - in the best case, someone who uses Bazel can benefit from it.
Also, other projects support CMake and Bazel side by side (e.g. Catch2, gtest, etc.)