Re: [Gimp-developer] help compiling babl

On 08/12/2019 03:38 PM, Ken Moffat via gimp-developer-list wrote:
On Mon, Aug 12, 2019 at 02:33:42PM -0400, Elle Stone wrote:
On 08/12/2019 01:38 PM, Alexandre Prokoudine via gimp-developer-list wrote:

You should be using the Meson build system now.

In case it helps anyone, here are the lines I've been using with meson to
build babl:

cd $SRC_DIR/babl
git status
rm -r build
git checkout build
cd build
CFLAGS="-march=native -O3 -ffast-math -ftree-vectorize -pipe"
CXXFLAGS="${CFLAGS}" meson --prefix=$PREFIX ..
ninja install

Here are some questions about meson:

1. Any suggestions to modify my lines?

Hi Ken, and thanks much! for the very helpful information.

Adding '-Dbuildtype=release' to a meson package will turn off debug
assertions, if any (e.g. mesa) and (usually) use -O3 (ISTR that at
least pango uses -O2 for a release build).

2. Do the CFLAGS lines actually do anything when using meson?

Do a verbose build using 'ninja -v' to see what flags and defines
are used.  I usually do separate steps for 'ninja' and 'ninja
install', but whatever works for you.  Verbose builds will produce a
_lot_ more output, teeing it to a log so you can read it afterwards
helps (but I'm sure you know that).

3. How do I tell meson to use "something" equivalent to the following "make"

./ --prefix=$PREFIX --enable-avx2=false --enable-mmx=no
--enable-sse=no --enable-sse2=no --enable-sse3=no --enable-sse4_1=no
--enable-f16c=no --enable-altivec=no --disable-docs

I very much doubt you are on ppc/powerpc, so altivec cannot be used.

In general, meson uses defines (-Dsomething=value, rather like
cmake) for things which are not covered by --prefix= --sysconfdir=.
To see the options for a particular package, look in the
meson_options.txt file.  That might have an option to disable docs,
or it might even be automatic if the deps are missing.

With -march=native I would tend to let gcc sort out sse and similar
options.  I'm assuming you are on x86_64.

Regarding my "make" options for babl, I disabled anything to do with CPU code because at one point the only thing that code in babl did was make the TRC transforms faster, and I was building babl for my "CCE" version of GIMP, which has no TRC transforms. So I just disabled any and all options related to the CPU (and for good measure ripped the relevant code out of the CCE version of babl).

I guess I should check to see what the babl CPU code does today. But if the code is hard-coded to the sRGB TRC, it still won't work with the somewhat modified version of GIMP I build for actual editing (as opposed to the versions I build for keeping up with and testing the default GIMP code).

The gcc manual gives some options (for X86) about what you can put
in CFLAGS|CXXFLAGS, see the  -mfpath= section.
(That is for 9.2, probably the only big change from 9.1 is adding
znver2).  And more generally, the -f options are linked from

Docs for the latest point release of each gcc version are at if you are using an earlier major

OTOH, if you have the (lots of) time needed to try playing with
these options, and scripts which you can run using 'time' (several
runs for each different build) then perhaps tuning out some of these
things might be worthwhile.  I spent a lot of time in the past couple
of months doing whole-system builds with different flags (mostly for
slight hardening) and ended up concluding there was just too much
variation between runs to get much meaningful data on timing.  And I
didn't have any runtime scripts for gimp-related actions.

I wasn't actually trying to optimize this or that using timings or anything sophisticated, just relying on some flags that were posted to the developer's list a long time ago in response to the general question "how to make GIMP go faster". That was back maybe around 2015 or so - there was other advice also, I wonder how much is still pertinent after all this time.

I have no idea whether these flags actually did or still do make GIMP go faster or not. But given the source of the recommendations - someone who seems to know what they are doing - I was and still am inclined to keep using the flags. Though given the many versions of gcc that have come and gone in the meantime, maybe the flags no longer make any sense. Updated general advice on cflags is very welcome! If it matters, my CPU is an Intel Core i7-4790K.


Ken, again, thank you so much! That meson stuff was/is very puzzling. Next time I build babl I'll try to put your pointers to good use.


Color management and free/libre photography

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]