On Tue, Mar 26, 2019 at 02:55:40PM -0500, Bruce Dubbs via blfs-dev wrote:
> On 3/26/19 2:35 PM, Ken Moffat via blfs-dev wrote:
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=109939#c16
> >
> > From that, the default for *mesa* is 'debugoptimized' which seems to
> > be what we are using. I've now got verbose output for my test
> > builds (ninja -v) and the default setup does not specify -DNDEBUG.
> >
> > On the current machine's setup (not building mesademos for this, I
> > think I'm enabling everything in mesa, including wayland backend):
> >
> > Build by the book, with logs not in the measurement:
> > mesa-19.0.0 1.5 GB
> > DESTDIR 611 MB
> >
> > Specifying -Dbuildtype=release:
> > mesa-19.0.0 374 MB
> > DESTDIR 91 MB
> >
[...]
> >
> > Summary: for mesa, -Dbuildtype=release looks like the way to go.
> >
> > The meson docs are at https://mesonbuild.com/Running-Meson.html and
> > my reading of that page suggests that 'debugoptimized' is not always
> > the default.
> >
> > Will look at some other meson packages later, if there is any
> > interest in this.
>
> Two thoughts. First, what happens to the installed sizes if they are
> stripped? Second, a quick check of BLFS shows 62 pakages with meson, most
> in gnome. As a side note, there are 162 mentions of cmake.
>
> -- Bruce
So far I have only looked at Mesa (it provided a break from
scrolling through the 3.5 million line diff between firefox-66.0.1
and 67.0b4 ;-)
Removing debug info (i.e. stripping) always reduces the installed
size if the debug info was built (-g). But in this case I suspect
there is also a difference from removing the assertions enabled in
debug code. I think cmake similarly removes assertion in releases.
In the case of Mesa, assertions clearly slow-down some uses. For
other packages, I have no idea if the loss of speed from using
assertions will be noticeable.
I also did not look at the difference in build times (8 cores on
this machine).
In my current main scripts I have (alphabetical order within the
script)
libdrm
libepoxy
Mesa q.v.
xorgproto (unlikely to be affected)
atk
at-spi-*
colord
fribidi
gdk-pixbuf
glib2
libgusb
pango
gexiv2
glib-networking
gsettings-desktop-schemas
gvfs
json-glib
libsoup
pygobject3
I suppose libdrm, gdk-pixbuf, glib2, pango might be interesting
packages to look at.
As an initial guess, I think I should compare (with 4 cores) :
· the book's current build
· forcing a release
· forcing a release but passing CFLAGS, CXXFLAGS of just '-g'
Does that sound sensible ? I have little experience using gdb, I'm
not entirely convinced that trying to debug a -O3 build would ever
be useful. The default in Mesa uses -O2 -g but also enables the
assertions, maybe a release with -O2 -g would be more useful ?
I also start to wonder if we ought to expand 'Notes on Building
Software' with a section about optimizations ? We used to only have
to really care about CMMI packages, with CFLAGS and CXXFLAGS - some
of those ignore the flags, and for those which accept them we assume
experienced builders will know about the obvious -O, -O2, -O3, -g.
But with (I think) both cmake and meson we perhaps need to spell out
somewhere what the typical defaults are ? (as well as maybe
specifying release builds, perhaps with notes about what that
actually does).
ĸen
--
It is said that there are two great unsolved problems in computer
science: naming, cache invalidation, and off-by-one errors.
-- Ben Bullock
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
