Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
NDEBUG when building packages?
205 views
Skip to first unread message
Daniel Pocock
Feb 7, 2013, 2:30:02 PM2/7/13
to
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5113FE77...@pocock.com.au
Ian Jackson
Feb 19, 2013, 11:40:02 AM2/19/13
to
Daniel Pocock writes ("NDEBUG when building packages?"):
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20771.43161....@chiark.greenend.org.uk
> 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.
> 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?
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mathieu Malaterre
Feb 22, 2013, 2:30:02 PM2/22/13
to
On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson
<ijac...@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 ?
<ijac...@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.
> 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.
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Pocock
Feb 22, 2013, 3:10:09 PM2/22/13
to
Mathieu Malaterre <ma...@debian.org> wrote:
>On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson
><ijac...@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
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`
>
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Jackson
Feb 22, 2013, 3:50:02 PM2/22/13
to
Mathieu Malaterre writes ("Re: NDEBUG when building packages?"):
> > 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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20775.38178....@chiark.greenend.org.uk
> On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson
> <ijac...@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.
> <ijac...@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`
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Feb 22, 2013, 4:00:02 PM2/22/13
to
Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
> Mathieu Malaterre writes ("Re: NDEBUG when building packages?"):
> 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
>> 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.
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mathieu Malaterre
Feb 23, 2013, 4:50:01 AM2/23/13
to
On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery <r...@debian.org> wrote:
> Ian Jackson <ijac...@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
> Ian Jackson <ijac...@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.
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Cheng
Feb 23, 2013, 5:20:01 AM2/23/13
to
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 <ijac...@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
> On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery <r...@debian.org> wrote:
>> Ian Jackson <ijac...@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
-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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrey Rahmatullin
Feb 23, 2013, 5:40:01 AM2/23/13
to
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.
> 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...
--
WBR, wRAR
Lisandro Damián Nicanor Pérez Meyer
Feb 23, 2013, 10:30:01 AM2/23/13
to
On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió:
[snip]
--
"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/
[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.
> -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...
--
"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/
Lisandro Damián Nicanor Pérez Meyer
Feb 23, 2013, 10:40:01 AM2/23/13
to
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.
> 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.
--
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
Feb 23, 2013, 10:40:02 AM2/23/13
to
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
> 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.
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
Hendrik Sattler
Feb 23, 2013, 12:10:01 PM2/23/13
to
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:
> 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.
[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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Pocock
Feb 24, 2013, 2:50:02 PM2/24/13
to
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ￜ:
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?
Archive: http://lists.debian.org/512A6CD3...@pocock.com.au
> 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
>>>>
>>>>> 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.
>
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?
Florian Weimer
Feb 24, 2013, 4:30:03 PM2/24/13
to
* Ian Jackson:
> Mathieu Malaterre writes ("Re: NDEBUG when building packages?"):
>> On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson
>> <ijac...@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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/871uc5q...@mid.deneb.enyo.de
> Mathieu Malaterre writes ("Re: NDEBUG when building packages?"):
>> On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson
>> <ijac...@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.
> Certainly -DNDEBUG should never be used unless upstream explicitly say
> that it's intended to be supported, and usually not even then.
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mathieu Malaterre
Jun 7, 2013, 6:00:02 AM6/7/13
to
-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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kumar Appaiah
Jun 7, 2013, 8:00:02 AM6/7/13
to
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
> 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)
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stephen M. Webb
Jun 7, 2013, 8:40:01 AM6/7/13
to
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
>
> 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?
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 <stephe...@bregmasoft.ca>
Jonas Smedegaard
Jun 7, 2013, 9:30:03 AM6/7/13
to
Quoting Stephen M. Webb (2013-06-07 14:29:52)
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
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
Hendrik Sattler
Jun 7, 2013, 2:10:02 PM6/7/13
to
Mathieu Malaterre <ma...@debian.org> schrieb:
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Jun 7, 2013, 2:30:02 PM6/7/13
to
>> 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
>> 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.
need to get excited. :) CDBS of course also uses debhelper, and hence
has the same capability.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87sj0tb...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonas Smedegaard
Jun 7, 2013, 3:50:01 PM6/7/13
to
Quoting Russ Allbery (2013-06-07 20:29:24)
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 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
> > 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.
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. ;-)
Kurt Roeckx
Jun 7, 2013, 5:20:02 PM6/7/13
to
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
> 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.
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kumar Appaiah
Jun 8, 2013, 1:30:01 AM6/8/13
to
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.
> 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.
Kumar
--
Whoa...I did a 'zcat /vmlinuz > /dev/audio' and I think I heard God...
-- mikecd on #Linux
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kumar Appaiah
Jun 8, 2013, 1:30:02 AM6/8/13
to
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!
> > 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.
Kumar
--
It's computer hardware, of course it's worth having <g>
-- Espy on #Debian
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mathieu Malaterre
Jun 8, 2013, 5:10:01 AM6/8/13
to
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CA+7wUsy+no=4wHZEKB9X_XF93OJiTM...@mail.gmail.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages