Opened 13 years ago
Closed 11 years ago
#33821 closed enhancement (wontfix)
base: add a default +debug and +no_opt variant
Reported by: | seanfarley (Sean Farley) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.0.4 |
Keywords: | Cc: | nerdling (Jeremy Lavergne), nonstop.server@…, su-v, eborisch (Eric A. Borisch), mkae (Marko Käning), axet (Alexey Kuznetsov), maehne (Torsten Maehne), cnehren+macports@… | |
Port: |
Description
This patch adds a default +debug variant that will build packages with -g and, more importantly, run the dsymutil tool to keep the debugging symbols. Additionally, there is a +no_opt variant that will try to delete all -O{1,2,3} flags and add -O0. Of course, individual packages can override what +debug and +no_opt will do, but as a base default, this seems sensible to have so that a user can get debugging symbols for gdb easily without having to edit a package's Portfile.
Attachments (5)
Change History (24)
Changed 13 years ago by seanfarley (Sean Farley)
Attachment: | base-debug-no_opt.patch added |
---|
comment:1 follow-ups: 2 4 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 13 years ago by seanfarley (Sean Farley)
Replying to ryandesign@…:
I'm not certain if we want this.
Certainly, we don't want variants whose names begin with "no_" anymore. But on the other hand we don't want to add a default "opt" variant to all ports either; we'd have to rebuild all our binary packages. Could disabling optimizations simply be part of the debug variant?
Why would a normal user want a debug variant? Granted we have it in the cmake portgroup but I'm not sure why we have that either.
First, having a debug variant is vitally important for macport users, particularly those that build code on top of certain libraries. Take, for instance, PETSc. PETSc can be built on top of gcc4{4,5,6,7}, metis, parmetis, suitesparse, hypre, superlu, superlu_dist, mpich2 (or openmpi), triangle, tetgen, fftw-3, ml, sundials, mumps (which implies scalapack and blacs), hdf5-18, netcdf, libyaml, and valgrind. Adding a +debug variant to all these ports is ... tedious. But without debug symbols being built (and then stashed into a .dSYM) it would be impossible to use gdb my own code that uses PETSc. More over, I found the +debug particularly useful in building my own gfortran port so that gdb worked as expected.
I agree about the +no_opt variant. I did originally have -O0 logic in the +debug variant but that ran into problems with building mpfr. The issue is multi-faceted, unfortunately, with zero optimization. Depending on the compiler, there are different settings for which optimization to use (if nothing is specified most compilers use -O2). Using anything more than -O0 causes problems with debugging because a lot of variables are optimized out, e.g. using 'print var' in gdb causes a hit-or-miss of "variable is optimized out".
So, clearly, not every port can work with -O0 but then again it is *extremely* useful to have a +debug variant to keep the .dSYM files around. I don't know how to proceed. I'm ok with dropping the +no_opt and making each portfile write its own logic for -O0. Probably something like,
pre-configure { if {[variant_isset debug]} { configure.cflags-append -O0 ... } }
As an aside for the naming convention, would "+optimization_debug" (or +debug_opt?) have worked? Also, since this is on the subject of variants, a more dangerous idea I had was based off a suggestion on the list: wanting to compile different ports with the same compiler. For example, having a default +gcc44 ... +gcc47, +clang, +system_gcc, +llvm_gcc, etc. Thoughts? (There would be similar problems as having -O0, i.e. some ports wouldn't be able to handle it or would have a cyclic dependency)
comment:3 Changed 13 years ago by seanfarley (Sean Farley)
I've updated the patch with a new variant name (and better find command). Any thoughts on the issue?
comment:4 Changed 13 years ago by seanfarley (Sean Farley)
Replying to ryandesign@…:
I'm not certain if we want this.
Certainly, we don't want variants whose names begin with "no_" anymore. But on the other hand we don't want to add a default "opt" variant to all ports either; we'd have to rebuild all our binary packages. Could disabling optimizations simply be part of the debug variant?
Why would a normal user want a debug variant? Granted we have it in the cmake portgroup but I'm not sure why we have that either.
Are there any more comments on this patch?
comment:5 follow-up: 6 Changed 13 years ago by nerdling (Jeremy Lavergne)
Cc: | snc@… added |
---|
Having a debug variant available would be handy for people developing directly against said library. Unfortunately, this isn't the typical user and certainly not a majority—the ability to edit the Portfile to include "-g -O0" in the configure.args should be sufficient, or at least has been for me.
Changed 13 years ago by seanfarley (Sean Farley)
Attachment: | base-debug-debug_opt.patch added |
---|
rename the no_opt variant to debug_opt; also use the find command more efficiently
comment:6 follow-up: 7 Changed 13 years ago by seanfarley (Sean Farley)
Replying to snc@…:
Having a debug variant available would be handy for people developing directly against said library. Unfortunately, this isn't the typical user and certainly not a majority—the ability to edit the Portfile to include "-g -O0" in the configure.args should be sufficient, or at least has been for me.
It's more than just adding "-g -O0", it's also generating the .dSYM libraries (at the very least). It is much easier to tell a user "just copy and paste 'sudo port -v install metis +debug' into your terminal" than to tell them to edit a Portfile. Forget about explaining tcl syntax as well. Editing Portfiles becomes a nightmare of maintenance, especially if you're trying to share them with your co-workers. With the newest version of this patch, I've run into no problems (this includes building gcc46, gcc47 as well as other common ports that usually give me trouble).
comment:7 follow-up: 8 Changed 13 years ago by nerdling (Jeremy Lavergne)
Replying to sean.michael.farley@…:
It is much easier to tell a user "just copy and paste 'sudo port -v install metis +debug' into your terminal" than to tell them to edit a Portfile.
I don't have the experience of a situation where I'd need the user (a non-developer) to actually debug a library from MacPorts on my behalf, so I'm wondering if that's worth the burden that Ryan pointed out in the mailing list: having more variants is going to be relatively messy for MacPorts to support.
I definitely like your patches for what they are, though.
comment:8 Changed 13 years ago by seanfarley (Sean Farley)
Replying to snc@…:
I don't have the experience of a situation where I'd need the user (a non-developer) to actually debug a library from MacPorts on my behalf, so I'm wondering if that's worth the burden that Ryan pointed out in the mailing list: having more variants is going to be relatively messy for MacPorts to support.
There are a few instances where this has come up very frequently for me. For one, using a gcc4X compiled binary in gdb leads to extremely messy debugging because the compiler itself needs to keep around its own .dSYM files. Further, it seems a case that is being very overlooked here is writing software dependent on libraries that a person doesn't maintain. PETSc is a good example of this (as I outlined in my previous comment). I've been using +debug for almost two years now and it has been a much more sane environment than before.
I definitely like your patches for what they are, though.
Thanks :-) thought at this point, I'd just be happy with getting the +debug variant accepted.
Changed 13 years ago by seanfarley (Sean Farley)
Attachment: | base-debug.patch added |
---|
combine both variants into +debug
comment:10 Changed 13 years ago by seanfarley (Sean Farley)
After talking with a colleague, I was convinced it made more sense to go back to my original plan of having just one +debug variant and dropping the +debug_opt. I've submitted a new patch to reflect this.
Changed 13 years ago by seanfarley (Sean Farley)
Attachment: | base-create-dsym.patch added |
---|
new patch based off reviews from macports-dev
Changed 13 years ago by seanfarley (Sean Farley)
Attachment: | cmake-port-group-debug.patch added |
---|
add dsym to cmake +debug variant
comment:18 Changed 11 years ago by seanfarley (Sean Farley)
Replying to cnehren+macports@…:
What's holding this up?
Some progress has finally been made on this front in r116291. I will be fixing this portgroup up based on feedback I get so that ports can start using this.
comment:19 Changed 11 years ago by seanfarley (Sean Farley)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm going to close this ticket now and suggest that the macports-dev mailing list be used to talk about how this port group should be improved.
I'm not certain if we want this.
Certainly, we don't want variants whose names begin with "no_" anymore. But on the other hand we don't want to add a default "opt" variant to all ports either; we'd have to rebuild all our binary packages. Could disabling optimizations simply be part of the debug variant?
Why would a normal user want a debug variant? Granted we have it in the cmake portgroup but I'm not sure why we have that either.