[MacPorts] #33821: base: add a default +debug and +no_opt variant

MacPorts noreply at macports.org
Fri Mar 30 11:16:30 PDT 2012


#33821: base: add a default +debug and +no_opt variant
-------------------------------------------+--------------------------------
 Reporter:  sean.michael.farley@…          |       Owner:  macports-tickets@…                   
     Type:  enhancement                    |      Status:  new                                  
 Priority:  Normal                         |   Milestone:                                       
Component:  base                           |     Version:  2.0.4                                
 Keywords:                                 |        Port:                                       
-------------------------------------------+--------------------------------

Comment(by sean.michael.farley@…):

 Replying to [comment:1 ryandesign@…]:
 > I'm not certain if we want this.
 >
 > Certainly, we [wiki:PortfileRecipes#default_variants 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)

-- 
Ticket URL: <https://trac.macports.org/ticket/33821#comment:2>
MacPorts <http://www.macports.org/>
Ports system for Mac OS


More information about the macports-tickets mailing list