-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[workspace] Build libtiff_internal from source #20331
Conversation
@drake-jenkins-bot linux-jammy-unprovisioned-gcc-bazel-experimental-release please |
Deprecate libtiff from the host OS and remove it from setup prereqs.
+@zachfang for feature review of the TIFF configuration, please. (Specifically, I mean the settings of +@rpoyner-tri for feature review of the build system stuff, please -- and also for platform review per schedule (tomorrow). |
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.
Reviewed 13 of 15 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: LGTM missing from assignee zachfang
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.
From my understanding, the motivation to build internally is to carve out the files/dependencies we don't need so we have a smaller footprint?
Reviewed 13 of 15 files at r1, 2 of 2 files at r2.
Reviewable status: 1 unresolved discussion
tools/workspace/libtiff_internal/repository.bzl
line 9 at r2 (raw file):
name = name, # N.B. Upstream is https://gitlab.com/libtiff/libtiff but this github # mirror seems to be kept up to date.
BTW. Is this because we prefer a GitHub source to Gitlab?
Code quote:
# N.B. Upstream is https://gitlab.com/libtiff/libtiff but this github
# mirror seems to be kept up to date.
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.
From my understanding, the motivation to build internally is to carve out the files/dependencies we don't need so we have a smaller footprint?
There are several reasons. That's one of them, but there are more also:
(2) Have the normal builds and wheel builds use the same tiff build system, to reduce the possibility that wheels are broken and we don't notice it quickly enough.
(3) Per #17231, ensure that we don't impose any particular version of libtiff on our users, in case they want a different one.
(4) When debugging, gdb will have line numbers & local variables & etc for libtiff in case we need to step into it. Ditto for ASan, etc.
(5) We can fix bugs in libtiff without waiting for anyone else to make new binaries for us.
Reviewable status:
complete! all discussions resolved, LGTM from assignees rpoyner-tri(platform),zachfang
tools/workspace/libtiff_internal/repository.bzl
line 9 at r2 (raw file):
Previously, zachfang wrote…
BTW. Is this because we prefer a GitHub source to Gitlab?
Yes. We have repository rule sugar ("github_archive") for downloading code from github, keeping a mirror of it, and noticing when a new release has been posted so that we can upgrade. We don't have that infrastructure built up for gitlab.
Thanks for the clarifications! |
Deprecate libtiff from the host OS and remove it from setup prereqs.
Deprecate libtiff from the host OS and remove it from setup prereqs.
Deprecate libtiff from the host OS and remove it from setup prereqs.
Towards #17231.
This change is![Reviewable](https://camo.githubusercontent.com/1541c4039185914e83657d3683ec25920c672c6c5c7ab4240ee7bff601adec0b/68747470733a2f2f72657669657761626c652e696f2f7265766965775f627574746f6e2e737667)