building Chromium's base directory for use in multiple binaries (was "Re: [cros-dev] debug vs. release builds")
Daniel Erat
files from Chromium's base/ directory. A subset of files from the
directory are compiled into a single package containing a static
library which gets linked into the various binaries that need it. The
library is always compiled without NDEBUG being defined, which seems
non-ideal. I would like to change this; we'd benefit from continuing
to include debug code in developers' builds, but don't want released
code to crash on DCHECKs, spew logs in response to DLOG(INFO), etc.
While it's straightforward to add per-package control of whether
NDEBUG is defined when building Chromium OS packages, I am concerned
that packages will often define NDEBUG before #including headers from
the base/ directory, only to later link against a libbase static
library that has been compiled without NDEBUG, or vice versa. Are my
fears well-founded? What's the right way (if any) to compile a single
copy of the base directory for use in multiple binaries that may have
different desires, debugging-wise?
* :-(
(My questions in the conversation quoted below were written before I
realized the full extent of the problem described above.)
On Mon, Jul 19, 2010 at 7:25 AM, Will Drewry <w...@chromium.org> wrote:
> @derat: A --debug or --usedebug flag sounds good to me. That
> semantics like --mode=opt|dbg (just in case we want to add make.conf
> tweaks or anything special for certain builds type? Maybe that is
> better left in overlays anyhow.)
>
> @kmixter: Yup -- I don't think all of our ebuilds for chrome-os
> specific stuffset IUSE=splitdebug and do anything at install, but
> since i haven't poked around them all recently, maybe I'm just wrong
> :)
>
> cheers!
> will
>
> On Fri, Jul 16, 2010 at 8:22 PM, Ken Mixter <kmi...@google.com> wrote:
>> Sorry, a little off thread, but FWIW - we use FEATURES=splitdebug and
>> build with debugging currently for developers and releases. See your
>> $SYSROOT/usr/lib/debug directory for a gig of debug information. (Now
>> making it easy to use it is another thing - see crosbug.com/4887 for
>> some ideas on that.)
>>
>> On Fri, Jul 16, 2010 at 5:08 PM, Daniel Erat <de...@chromium.org> wrote:
>>> Does a "usedebug" or similar flag in build_packages, defaulting to
>>> true, sound like the right way to expose this? I'd prefer that the
>>> debugging code is turned on by default; it's certainly helped me find
>>> tons of bugs in my own code. :-P
>>>
>>> On Fri, Jul 16, 2010 at 12:03 PM, Will Drewry <w...@chromium.org> wrote:
>>>> That sounds good to me!
>>>>
>>>> I believe the gentoo/portage standard is USE=debug to enable
>>>> assertions, etc (e.g., _not_ define -DNDEBUG). Perhaps we need to
>>>> roll through all our packages and make sure they do IUSE=debug
>>>> properly. Then setup a builder to do debug builds and otherwise they
>>>> are 'release'.
>>>>
>>>> (It'd be nice if we could also support USE=splitdebug too.)
>>>>
>>>> On Fri, Jul 16, 2010 at 1:46 PM, Daniel Erat <de...@chromium.org> wrote:
>>>>> We have many programs that link against libchrome, our repackaging of
>>>>> a bunch of files from Chrome's base/ directory into a single library.
>>>>> As far as I can tell, we don't define NDEBUG when compiling libchrome;
>>>>> as a result, we'll get code that's slower, logs a bunch of debugging
>>>>> information, and runs DCHECK()s. This is useful for developers'
>>>>> day-to-day builds but probably undesirable for everything else. Do we
>>>>> have anything similar to Chrome's concept of "debug" vs. "release"
>>>>> builds? What's the right way to expose this -- a FEATURES=release
>>>>> flag, off by default, that defines NDEBUG? (Note that we'll probably
>>>>> need to have buildbots that do both types of builds; putting
>>>>> non-optional code in a DCHECK() is a common source of problems.)
>>>>>
>>>>> --
>>>>> Chromium OS Developers mailing list: chromiu...@chromium.org
>>>>> View archives, change email options, or unsubscribe:
>>>>> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>>>>>
>>>>
>>>
>>> --
>>> Chromium OS Developers mailing list: chromiu...@chromium.org
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>>>
>>
>
Daniel Erat
then having packages link in the appropriate version depending on
whether they're defining NDEBUG or not. Seems reasonable enough,
although there's probably no way to automatically use the right
version (a package's dependencies are specified in its ebuild file,
but #defines are added at a lower level, in its SConstruct or Makefile
or whatever).