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 debug configuration to build system #142
Conversation
a8d9d84
to
5877b9d
Compare
5877b9d
to
cdd1e3b
Compare
d53b379
to
02f7a38
Compare
02f7a38
to
fc9e950
Compare
After realizing that specifying copts via the build command line switch like so: |
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.
Thanks for adding changes. Just a few small comments from me.
a05bc65
to
7a6ce0e
Compare
Looks good to me. As the PR author, I can't approve this. @barter-simsum, you may be able to approve it and merge it. If not, we'll need to wait on approval for @philipcmonk or someone else in @urbit/runtime. |
7a6ce0e
to
4a6efc8
Compare
One last change. As @hosted-fornet suggested in #174, removing the |
Will have to wait on @philipcmonk to approve. Last pusher to the branch can't approve. |
What is the flow for (1) CPU_DEBUG+MEMORY_DEBUG but also -O3 (for CI because it's fast) and (2) -O0 -g but no CPU_DEBUG+MEMORY_DEBUG (for debugging on live ships because you can't use those macros on ships created by binaries without those macros)? |
(1) is easy. (2) That's a good point about the loom/binary incompatibility. We should probably avoid defining debug macros with this behavior in the bazel rule and require that they be provided explicitly. Though for something like the With those changes, the command to build (2) would be
|
@philipcmonk with the changes introduced in 2763de2, binary/loom compatibility breaking macros will have to be explicitly included for all build targets if they're desired
|
2763de2
to
4b8ab9b
Compare
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.
Looks good!
Not ready to merge yet. Discovered somewhat strange behavior with bazel when a
Observe in the output below that urbitdbg was built with both optimizations provided
If all we want to do is ensure third party dependencies are built with |
(cherry picked from commit 5a09a74)
I think a well-rounded solution is to explicitly specify the optimization level via the |
265215a
to
24cd39b
Compare
@mcevoypeter I want that but slightly modified. I believe we should have a separate vere debug build target called something like It should specify full debug symbols It should also specify defines that don't break binary/loom compatibility but do add additional debug assertions, etc, e.g. the Maybe at some point we could also link in a profiler like gperftools to the debug target. Since we're producing static binaries, this is necessary -- unless you can easily produce a dynamically linked executable.
I can add these changes in a bit. |
What's the advantage to having a separate debug target as compared to doing all of what you mentioned via |
@mcevoypeter Linking in a profiler would be a big reason. We don't want that in the release binary. |
I agree that essentially everything else could be implemented without a new target. Though I don't think |
Agreed, but unless we have plans on doing that now or in the near future, I think we should do everything via
Good call. I just pushed a commit that addresses this. |
So now, the different cases mentioned by @philipcmonk look like :
Also, remember users can specify often-used command line options in |
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.
but unless we have plans on doing that now or in the near future, I think we should do everything via --copt
Agree. I have some work in progress to add gperftools, but it's not ready yet. Will be easy enough to make the debug config changes if those are added.
Approved.
Description
Resolves #83.
Testing
$ bazel build :urbitdbg
When running the resulting binary under
gdb
, no arguments are optimized out, as expected with an optimization level of-O0
(set by the debug configuration).