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:
>>> Hello,
>>>
>>> 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"
>> lines?
>>
>> ./autogen.sh --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.
> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
> (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
> .../gcc/Option-Index.html
> 
> Docs for the latest point release of each gcc version are at
> https://gcc.gnu.org/onlinedocs/ if you are using an earlier major
> version.
> 
> 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.

> ĸen
> 

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.

Best,
Elle

-- 
https://ninedegreesbelow.com
Color management and free/libre photography
_______________________________________________
gimp-developer-list mailing list
List address:    [email protected]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list