Opened 9 years ago

Closed 7 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)

base-debug-no_opt.patch (3.8 KB) - added by seanfarley (Sean Farley) 9 years ago.
base-debug-debug_opt.patch (4.0 KB) - added by seanfarley (Sean Farley) 9 years ago.
rename the no_opt variant to debug_opt; also use the find command more efficiently
base-debug.patch (3.4 KB) - added by seanfarley (Sean Farley) 9 years ago.
combine both variants into +debug
base-create-dsym.patch (6.0 KB) - added by seanfarley (Sean Farley) 9 years ago.
new patch based off reviews from macports-dev
cmake-port-group-debug.patch (1010 bytes) - added by seanfarley (Sean Farley) 9 years ago.
add dsym to cmake +debug variant

Download all attachments as: .zip

Change History (24)

Changed 9 years ago by seanfarley (Sean Farley)

Attachment: base-debug-no_opt.patch added

comment:1 Changed 9 years ago by ryandesign (Ryan Schmidt)

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.

comment:2 in reply to:  1 Changed 9 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 9 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 in reply to:  1 Changed 9 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 Changed 9 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 9 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 in reply to:  5 ; Changed 9 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 in reply to:  6 ; Changed 9 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 in reply to:  7 Changed 9 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.

comment:9 Changed 9 years ago by nonstop.server@…

Cc: nonstop.server@… added

Cc Me!

Changed 9 years ago by seanfarley (Sean Farley)

Attachment: base-debug.patch added

combine both variants into +debug

comment:10 Changed 9 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.

comment:11 Changed 9 years ago by su-v

Cc: suv-sf@… added

Cc Me!

Changed 9 years ago by seanfarley (Sean Farley)

Attachment: base-create-dsym.patch added

new patch based off reviews from macports-dev

Changed 9 years ago by seanfarley (Sean Farley)

add dsym to cmake +debug variant

comment:12 Changed 8 years ago by eborisch (Eric A. Borisch)

Cc: eborisch@… added

Cc Me!

comment:13 Changed 8 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:14 Changed 7 years ago by axet (Alexey Kuznetsov)

Cc: ak@… added

Cc Me!

comment:15 Changed 7 years ago by maehne (Torsten Maehne)

Cc: Torsten.Maehne@… added

Cc Me!

comment:16 Changed 7 years ago by cnehren+macports@…

What's holding this up?

comment:17 Changed 7 years ago by cnehren+macports@…

Cc: cnehren+macports@… added

Cc Me!

comment:18 in reply to:  16 Changed 7 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 7 years ago by seanfarley (Sean Farley)

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.