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
>
>
Reply to: