Re: NDEBUG when building packages?
On Fri, Jun 7, 2013 at 7:35 PM, Hendrik Sattler p...@hendrik-sattler.de wrote:
Mathieu Malaterre ma...@debian.org schrieb:
On Sat, Feb 23, 2013 at 11:09 AM, Vincent Cheng
vincentc1...@gmail.com wrote:
On Sat, Feb 23, 2013 at 1:39 AM, Mathieu Malaterre ma...@debian.org
wrote:
On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery r...@debian.org
wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Mathieu Malaterre writes (Re: NDEBUG when building packages?):
In that case, this should really be clarified. A lot of
debian/cmake
packages are actually doing:
-DCMAKE_BUILD_TYPE:STRING=Release
within there debian/rules files. This settings by default
compiles
with: `-O3 -DNDEBUG`
OMG WTF BBQ
Certainly -DNDEBUG should never be used unless upstream explicitly
say
that it's intended to be supported, and usually not even then.
Also, -O3 is generally considered rather iffy. It's not very
well-tested
and in various versions of GCC it tended to make the code slower,
not
faster (usually because it unrolled loops too far and blew the CPU
cache).
It's also had various code generation bugs from time to time.
I wouldn't use -O3 without benchmarking of that specific code to
confirm
that it really improves matters.
Seems like everyone agreed. I'll report a bug to lintian package to
have it check for this string in d/rules:
http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease
We should also suggest that packages use
-DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think
that this would be a sensible default for packages using debhelper's
cmake integration. Sounds like another wishlist bug for debhelper...
cmake from sid makes it even harder. RelWithDebInfo now contains
-DNDEBUG ... I have to source-upload all my packages :(
$ grep NDEBUG ChangeLog.manual
Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it.
The solution (backward compat) is now:
Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to
Debug (and hope -DNDEBUG does not creep in ever)
2cts
Or just define CMAKE_C_FLAGS properly and don't rely on the default values.
It's not that hard, actually.
CMAKE_C_FLAGS gets popullated with whatever is set from ${CFLAGS}. So
this is the right behavior, there is not need to change anything to
that value.
However CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE} get appended to the
compilation line. Therefore we are back to what I previously stated:
Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to
Debug (and hope -DNDEBUG does not creep in ever)
2cts
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CA+7wUsy+no=4whzekb9x_xf93ojitm7eczahp7smbpsjww3...@mail.gmail.com
Re: NDEBUG when building packages?
On Sat, Feb 23, 2013 at 11:09 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sat, Feb 23, 2013 at 1:39 AM, Mathieu Malaterre ma...@debian.org wrote: On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery r...@debian.org wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Mathieu Malaterre writes (Re: NDEBUG when building packages?): In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` OMG WTF BBQ Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. Also, -O3 is generally considered rather iffy. It's not very well-tested and in various versions of GCC it tended to make the code slower, not faster (usually because it unrolled loops too far and blew the CPU cache). It's also had various code generation bugs from time to time. I wouldn't use -O3 without benchmarking of that specific code to confirm that it really improves matters. Seems like everyone agreed. I'll report a bug to lintian package to have it check for this string in d/rules: http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... cmake from sid makes it even harder. RelWithDebInfo now contains -DNDEBUG ... I have to source-upload all my packages :( $ grep NDEBUG ChangeLog.manual Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it. The solution (backward compat) is now: Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to Debug (and hope -DNDEBUG does not creep in ever) 2cts -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUsx-La707opCh_HrcrAjUQw7DdAkTAa4HXov8Vfp=mx...@mail.gmail.com
Re: NDEBUG when building packages?
On Fri, Jun 07, 2013 at 11:54:49AM +0200, Mathieu Malaterre wrote: cmake from sid makes it even harder. RelWithDebInfo now contains -DNDEBUG ... I have to source-upload all my packages :( $ grep NDEBUG ChangeLog.manual Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it. The solution (backward compat) is now: Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to Debug (and hope -DNDEBUG does not creep in ever) While we're at it, could you please let me know what is the best practice for package builds that generate debug symbol packages? Ideally, I would hapve to rebuild the whole package TWICE, once with -O0 -g, and the other time with -O2, right? Currently, I don't bother with this, since the the debug library with -O2 is still useful, other than the odd optimized out messages. In addition, I don't want to add an additional burden to the buildds for this, since the package is probably never used on architectures other than i386/amd64. Thanks. Kumar -- mar...@bdsi.com (no longer valid - where are you now, Martin?) -- from /usr/src/linux/drivers/cdrom/mcd.c -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130607113421.ga14...@bluemoon.alumni.iitm.ac.in
Re: NDEBUG when building packages?
On 06/07/2013 07:34 AM, Kumar Appaiah wrote: While we're at it, could you please let me know what is the best practice for package builds that generate debug symbol packages? Ideally, I would hapve to rebuild the whole package TWICE, once with -O0 -g, and the other time with -O2, right? Having debug symbols not matching the runtime would cause a great deal of trouble. If you're expecting a lot of debugging, try the new -Og switch. One build pass and let dh_strip create the debug symbols package for you. Unless you're not using dh, in which case your build system is probably already broken and needs to get fixed first. -- Stephen M. Webb stephen.w...@bregmasoft.ca signature.asc Description: OpenPGP digital signature
Re: NDEBUG when building packages?
Quoting Stephen M. Webb (2013-06-07 14:29:52) On 06/07/2013 07:34 AM, Kumar Appaiah wrote: While we're at it, could you please let me know what is the best practice for package builds that generate debug symbol packages? Ideally, I would hapve to rebuild the whole package TWICE, once with -O0 -g, and the other time with -O2, right? Having debug symbols not matching the runtime would cause a great deal of trouble. If you're expecting a lot of debugging, try the new -Og switch. One build pass and let dh_strip create the debug symbols package for you. Unless you're not using dh, in which case your build system is probably already broken and needs to get fixed first. Fud! Please support your dh is a silver bullet meme with some concrete references. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: NDEBUG when building packages?
Mathieu Malaterre ma...@debian.org schrieb: On Sat, Feb 23, 2013 at 11:09 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sat, Feb 23, 2013 at 1:39 AM, Mathieu Malaterre ma...@debian.org wrote: On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery r...@debian.org wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Mathieu Malaterre writes (Re: NDEBUG when building packages?): In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` OMG WTF BBQ Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. Also, -O3 is generally considered rather iffy. It's not very well-tested and in various versions of GCC it tended to make the code slower, not faster (usually because it unrolled loops too far and blew the CPU cache). It's also had various code generation bugs from time to time. I wouldn't use -O3 without benchmarking of that specific code to confirm that it really improves matters. Seems like everyone agreed. I'll report a bug to lintian package to have it check for this string in d/rules: http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... cmake from sid makes it even harder. RelWithDebInfo now contains -DNDEBUG ... I have to source-upload all my packages :( $ grep NDEBUG ChangeLog.manual Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it. The solution (backward compat) is now: Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to Debug (and hope -DNDEBUG does not creep in ever) 2cts Or just define CMAKE_C_FLAGS properly and don't rely on the default values. It's not that hard, actually. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4965467d-46cf-4b56-979c-480b84403...@email.android.com
Re: NDEBUG when building packages?
Jonas Smedegaard d...@jones.dk writes: Quoting Stephen M. Webb (2013-06-07 14:29:52) Having debug symbols not matching the runtime would cause a great deal of trouble. If you're expecting a lot of debugging, try the new -Og switch. One build pass and let dh_strip create the debug symbols package for you. Unless you're not using dh, in which case your build system is probably already broken and needs to get fixed first. Fud! Please support your dh is a silver bullet meme with some concrete references. I'm pretty sure Stephen just meant debhelper where he said dh. No need to get excited. :) CDBS of course also uses debhelper, and hence has the same capability. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sj0tbwqj@windlord.stanford.edu
Re: NDEBUG when building packages?
Quoting Russ Allbery (2013-06-07 20:29:24) Jonas Smedegaard d...@jones.dk writes: Quoting Stephen M. Webb (2013-06-07 14:29:52) Having debug symbols not matching the runtime would cause a great deal of trouble. If you're expecting a lot of debugging, try the new -Og switch. One build pass and let dh_strip create the debug symbols package for you. Unless you're not using dh, in which case your build system is probably already broken and needs to get fixed first. Fud! Please support your dh is a silver bullet meme with some concrete references. I'm pretty sure Stephen just meant debhelper where he said dh. No need to get excited. :) CDBS of course also uses debhelper, and hence has the same capability. Hmm, right - point taken. I read it as if you're not leaving it to dh sequencer to stitch things automagically together... but that sure isn't what is quoted above, nor the only possible interpretation, so I'll lean back in my couch and think of nicer alternatives :-) ...and for the record, CDBS only *optionally* uses debhelper, leaving plenty of room for shooting oneself in the foot if that's desired. ;-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: NDEBUG when building packages?
On Fri, Jun 07, 2013 at 07:34:21AM -0400, Kumar Appaiah wrote: On Fri, Jun 07, 2013 at 11:54:49AM +0200, Mathieu Malaterre wrote: cmake from sid makes it even harder. RelWithDebInfo now contains -DNDEBUG ... I have to source-upload all my packages :( $ grep NDEBUG ChangeLog.manual Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it. The solution (backward compat) is now: Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to Debug (and hope -DNDEBUG does not creep in ever) While we're at it, could you please let me know what is the best practice for package builds that generate debug symbol packages? Ideally, I would hapve to rebuild the whole package TWICE, once with -O0 -g, and the other time with -O2, right? Currently, I don't bother with this, since the the debug library with -O2 is still useful, other than the odd optimized out messages. As I understand it, with dwarf 4 you should see less problems trying to debug optimised programs. Dwarf 4 is enabled by default in gcc 4.8 and supported by gdb 7.5. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130607211252.ga8...@roeckx.be
Re: NDEBUG when building packages?
On Fri, Jun 07, 2013 at 08:29:52AM -0400, Stephen M. Webb wrote: Having debug symbols not matching the runtime would cause a great deal of trouble. If you're expecting a lot of debugging, try the new -Og switch. One build pass and let dh_strip create the debug symbols package for you. Unless you're not using dh, in which case your build system is probably already broken and needs to get fixed first. I see your point. I already use dh_strip, but I think I'll stick with -O2. Kumar -- Whoa...I did a 'zcat /vmlinuz /dev/audio' and I think I heard God... -- mikecd on #Linux -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130608050446.gb...@bluemoon.alumni.iitm.ac.in
Re: NDEBUG when building packages?
On Fri, Jun 07, 2013 at 11:12:52PM +0200, Kurt Roeckx wrote: Currently, I don't bother with this, since the the debug library with -O2 is still useful, other than the odd optimized out messages. As I understand it, with dwarf 4 you should see less problems trying to debug optimised programs. Dwarf 4 is enabled by default in gcc 4.8 and supported by gdb 7.5. Thanks. This is useful to know! Kumar -- It's computer hardware, of course it's worth having g -- Espy on #Debian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130608050352.ga...@bluemoon.alumni.iitm.ac.in
Re: NDEBUG when building packages?
On 23/02/13 17:41, Hendrik Sattler wrote: Am Samstag, 23. Februar 2013, 16:39:22 schrieb Lisandro Damián Nicanor Pérez Meyer: On Sat 23 Feb 2013 12:33:58 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 12:18:30 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió: [snip] We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... IIRC, the cmake integration already does that. Not checked though. It doesn't. Will ask Modestas to see if there is a reaosn for it. Pino pointed me out that RelWithDebInfo is CMake's default. So if CMakeLists.txt doesn't override it, it's there. That's news for everyone using CMake. A simple CMake test shows: [100%] Building C object CMakeFiles/test.dir/test.c.o /usr/bin/gcc-o CMakeFiles/test.dir/test.c.o -c /home/hendrik/tmp/cmake test/test.c So RelWithDebInfo is _NOT_ the default setting. The default setting on Linux is an empty CMAKE_BUILD_TYPE variable. However, combined with automatically evaluated CPPFLAGS/CFLAGS/CXXFLAGS/..., the result may be the same. Also testing in Lintian for the -DCMAKE_BUILD_TYPE=RELEASE is plain wrong, as it may be configured using other -D settings. Not using -DNDEBUG for CFLAGS is new to me, though. To put it in context, reSIProcate = 1.7 offered these different compilation styles: --with-compile-type=... What compile profile will you use? (Now debug) Valid values are: [debug, nodebug, opt, gopt, prof, small] Choosing one of (nodebug, opt, ...) would automatically add NDEBUG to CPPFLAGS, so people using all those previous versions in production never got hit by an assert(). As of v1.8.0, there is autotools configure, and that doesn't mess with NDEBUG unless you explicitly add it to CPPFLAGS. When I implemented this, I made a very lightweight configure.ac, I didn't try to replicate all of the legacy behavior of the earlier build script. So people are starting to experience some assert()s that they never noticed before. In the end, upstream is able to diagnose and fix them - but it provides a useful case study. There are more than a few autotools based packages that do explicitly set NDEBUG from within configure or Makefile, it might be interesting to rebuild the whole archive with some kind of cpp wrapper that detects such flags that lintian might have missed - are there any other useful things we could test with such an exercise? === DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) CFLAGS = ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS_RELEASE = -O0 -g -DNDEBUG $(CFLAGS) CFLAGS_DEBUG = -O0 -g $(CFLAGS) else CFLAGS_RELEASE = -O2 -g -DNDEBUG $(CFLAGS) CFLAGS_DEBUG = -O2 -g $(CFLAGS) endif BUILD_TYPE = Release ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) BUILD_TYPE = Debug endif BUILD_FLAGS = -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=$(BUILD_TYPE) \ -DCMAKE_C_FLAGS_RELEASE=$(CFLAGS_RELEASE) -DCMAKE_C_FLAGS_DEBUG=$(CFLAGS_DEBUG) \ -DCMAKE_SKIP_RPATH=ON ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) BUILD_FLAGS += -DCMAKE_SYSTEM_NAME=$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS) \ -DCMAKE_SYSTEM_PROCESSOR=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU) \ -DCMAKE_C_COMPILER=$(DEB_BUILD_GNU_TYPE)-gcc endif BUILD_FLAGS += -DCMAKE_INSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH) === HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512a6cd3.8030...@pocock.com.au
Re: NDEBUG when building packages?
* Ian Jackson: Mathieu Malaterre writes (Re: NDEBUG when building packages?): On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Daniel Pocock writes (NDEBUG when building packages?): I notice some upstreams hack NDEBUG into their Makefile, while others leave it at the discretion of the user Is there any distribution policy for this? Should I be adding something into debian/rules to set -DNDEBUG when I prepare a package for release? -DNDEBUG is (normally) EBW. http://en.wikipedia.org/wiki/EBW ? Evil, Bad and Wrong. So it's not everbody wins? Oh. Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. I've seen some cases where -DNDEBUG pampers over crashers due to invalid asserts. On the other hand, there is a lot of code out there which performs actions with side effects inside the assert. Not overriding upstream's default is probably a good idea, but as was pointed out, this is a bit murky with CMake projects. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uc5qu6k@mid.deneb.enyo.de
Re: NDEBUG when building packages?
On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery r...@debian.org wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Mathieu Malaterre writes (Re: NDEBUG when building packages?): In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` OMG WTF BBQ Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. Also, -O3 is generally considered rather iffy. It's not very well-tested and in various versions of GCC it tended to make the code slower, not faster (usually because it unrolled loops too far and blew the CPU cache). It's also had various code generation bugs from time to time. I wouldn't use -O3 without benchmarking of that specific code to confirm that it really improves matters. Seems like everyone agreed. I'll report a bug to lintian package to have it check for this string in d/rules: http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease Thanks, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUswHYHypftg0zJ1s638Sy=2LJmrUBy5g3Gz9669eHE=k...@mail.gmail.com
Re: NDEBUG when building packages?
On Sat, Feb 23, 2013 at 1:39 AM, Mathieu Malaterre ma...@debian.org wrote: On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery r...@debian.org wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Mathieu Malaterre writes (Re: NDEBUG when building packages?): In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` OMG WTF BBQ Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. Also, -O3 is generally considered rather iffy. It's not very well-tested and in various versions of GCC it tended to make the code slower, not faster (usually because it unrolled loops too far and blew the CPU cache). It's also had various code generation bugs from time to time. I wouldn't use -O3 without benchmarking of that specific code to confirm that it really improves matters. Seems like everyone agreed. I'll report a bug to lintian package to have it check for this string in d/rules: http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... Regards, Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBqy0VUA+ZRWEJZxMucpdTQcN0=co+ayuznaecz_jm...@mail.gmail.com
Re: NDEBUG when building packages?
On Sat, Feb 23, 2013 at 02:09:39AM -0800, Vincent Cheng wrote: We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... Yes please. -- WBR, wRAR signature.asc Description: Digital signature
Re: NDEBUG when building packages?
On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió: [snip] We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... IIRC, the cmake integration already does that. Not checked though. -- Los promotores del software privativo demonizan algo tan básico y ético como el hecho de compartir imponiendo términos como el de 'pirata'. Equiparan ayudar al prójimo con atacar barcos. Cuando me preguntan qué pienso de la piratería musical e informática digo que atacar barcos es muy malo y, que yo sepa, los piratas no usan computadoras.” Richard Stallman, 05/11/2008, anexo de la Cámara de Diputados, Argentina Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: NDEBUG when building packages?
On Sat 23 Feb 2013 12:18:30 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió: [snip] We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... IIRC, the cmake integration already does that. Not checked though. It doesn't. Will ask Modestas to see if there is a reaosn for it. -- Passwords are like underwear. You shouldn’t leave them out where people can see them. You should change them regularly. And you shouldn’t loan them out to strangers. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: NDEBUG when building packages?
On Sat 23 Feb 2013 12:33:58 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 12:18:30 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió: [snip] We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... IIRC, the cmake integration already does that. Not checked though. It doesn't. Will ask Modestas to see if there is a reaosn for it. Pino pointed me out that RelWithDebInfo is CMake's default. So if CMakeLists.txt doesn't override it, it's there. Kinds regards, Lisandro. -- Antiguo proverbio del Viejo Machi: Prefiero que mi cerebro esté en la cresta de la ola, y mi PC un paso atrás sirviéndolo y no tener mi PC en el 'estado del arte' y mi cerebro un paso atrás asistiéndola. http://www.grulic.org.ar/lurker/message/20090507.020516.ffda0441.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: NDEBUG when building packages?
Am Samstag, 23. Februar 2013, 16:39:22 schrieb Lisandro Damián Nicanor Pérez Meyer: On Sat 23 Feb 2013 12:33:58 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 12:18:30 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió: [snip] We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... IIRC, the cmake integration already does that. Not checked though. It doesn't. Will ask Modestas to see if there is a reaosn for it. Pino pointed me out that RelWithDebInfo is CMake's default. So if CMakeLists.txt doesn't override it, it's there. That's news for everyone using CMake. A simple CMake test shows: [100%] Building C object CMakeFiles/test.dir/test.c.o /usr/bin/gcc-o CMakeFiles/test.dir/test.c.o -c /home/hendrik/tmp/cmake test/test.c So RelWithDebInfo is _NOT_ the default setting. The default setting on Linux is an empty CMAKE_BUILD_TYPE variable. However, combined with automatically evaluated CPPFLAGS/CFLAGS/CXXFLAGS/..., the result may be the same. Also testing in Lintian for the -DCMAKE_BUILD_TYPE=RELEASE is plain wrong, as it may be configured using other -D settings. Not using -DNDEBUG for CFLAGS is new to me, though. === DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) CFLAGS = ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS_RELEASE = -O0 -g -DNDEBUG $(CFLAGS) CFLAGS_DEBUG = -O0 -g $(CFLAGS) else CFLAGS_RELEASE = -O2 -g -DNDEBUG $(CFLAGS) CFLAGS_DEBUG = -O2 -g $(CFLAGS) endif BUILD_TYPE = Release ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) BUILD_TYPE = Debug endif BUILD_FLAGS = -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=$(BUILD_TYPE) \ -DCMAKE_C_FLAGS_RELEASE=$(CFLAGS_RELEASE) -DCMAKE_C_FLAGS_DEBUG=$(CFLAGS_DEBUG) \ -DCMAKE_SKIP_RPATH=ON ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) BUILD_FLAGS += -DCMAKE_SYSTEM_NAME=$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS) \ -DCMAKE_SYSTEM_PROCESSOR=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU) \ -DCMAKE_C_COMPILER=$(DEB_BUILD_GNU_TYPE)-gcc endif BUILD_FLAGS += -DCMAKE_INSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH) === HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201302231741.50338.p...@hendrik-sattler.de
Re: NDEBUG when building packages?
On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Daniel Pocock writes (NDEBUG when building packages?): I notice some upstreams hack NDEBUG into their Makefile, while others leave it at the discretion of the user Is there any distribution policy for this? Should I be adding something into debian/rules to set -DNDEBUG when I prepare a package for release? -DNDEBUG is (normally) EBW. http://en.wikipedia.org/wiki/EBW ? Unless your packages are weird in some way, you shouldn't set it. Even if upstream specify it it can be right to remove it. In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` 2cts -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+7wusypgyth9thhokhxak-bf2gv1mdoxx8hzc-qjix9srf...@mail.gmail.com
Re: NDEBUG when building packages?
Mathieu Malaterre ma...@debian.org wrote: On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Daniel Pocock writes (NDEBUG when building packages?): I notice some upstreams hack NDEBUG into their Makefile, while others leave it at the discretion of the user Is there any distribution policy for this? Should I be adding something into debian/rules to set -DNDEBUG when I prepare a package for release? -DNDEBUG is (normally) EBW. http://en.wikipedia.org/wiki/EBW ? My understanding is that he means Evil Bad Wrong Some people argue that assert itself is just as bad Unless your packages are weird in some way, you shouldn't set it. Even if upstream specify it it can be right to remove it. In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` Changing this would, in the short term, cause many new crashes to be observed. In the long term, the feedback about such issues (assuming the assert stderr output is captured by the users and reported upstream) could lead to an improvement in quality and the resolution/prevention of more obscure issues. +1 to ban NDEBUG in jessie -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0725397c-d31f-4c55-8d8a-ccf0f6454...@email.android.com
Re: NDEBUG when building packages?
Mathieu Malaterre writes (Re: NDEBUG when building packages?): On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Daniel Pocock writes (NDEBUG when building packages?): I notice some upstreams hack NDEBUG into their Makefile, while others leave it at the discretion of the user Is there any distribution policy for this? Should I be adding something into debian/rules to set -DNDEBUG when I prepare a package for release? -DNDEBUG is (normally) EBW. http://en.wikipedia.org/wiki/EBW ? Evil, Bad and Wrong. Unless your packages are weird in some way, you shouldn't set it. Even if upstream specify it it can be right to remove it. In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` OMG WTF BBQ Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. Pretty much the only reason to use it is if it is necessary to disable time-consuming checks, but most upstreams are more sensible than to throw the assert() baby out with the expensive consistency check bathwater. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20775.38178.57144.518...@chiark.greenend.org.uk
Re: NDEBUG when building packages?
Ian Jackson ijack...@chiark.greenend.org.uk writes: Mathieu Malaterre writes (Re: NDEBUG when building packages?): In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` OMG WTF BBQ Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. Also, -O3 is generally considered rather iffy. It's not very well-tested and in various versions of GCC it tended to make the code slower, not faster (usually because it unrolled loops too far and blew the CPU cache). It's also had various code generation bugs from time to time. I wouldn't use -O3 without benchmarking of that specific code to confirm that it really improves matters. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwuw9imi@windlord.stanford.edu
Re: NDEBUG when building packages?
Daniel Pocock writes (NDEBUG when building packages?): I notice some upstreams hack NDEBUG into their Makefile, while others leave it at the discretion of the user Is there any distribution policy for this? Should I be adding something into debian/rules to set -DNDEBUG when I prepare a package for release? -DNDEBUG is (normally) EBW. Unless your packages are weird in some way, you shouldn't set it. Even if upstream specify it it can be right to remove it. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20771.43161.813488.58...@chiark.greenend.org.uk
NDEBUG when building packages?
I notice some upstreams hack NDEBUG into their Makefile, while others leave it at the discretion of the user Is there any distribution policy for this? Should I be adding something into debian/rules to set -DNDEBUG when I prepare a package for release? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5113fe77.8010...@pocock.com.au
