On Wed, Jun 16, 2021 at 04:59:47PM +0200, Mauro Carvalho Chehab wrote: > Em Wed, 16 Jun 2021 11:26:10 -0300 Ariel D'Alessandro escreveu: > > > Kieran, > > > > > > - Meson decided to default libdir to > > > /usr/local/lib/x86_64-linux-gnu > > > while autoconf used > > > /usr/local/lib > > > (it's likely handled by the package managers anyway) > > > > $ meson configure ../build-meson/ | grep libdir > > libdir lib/x86_64-linux-gnu Library directory > > The default isn't nice, and will likely cause troubles for the users, as > /usr/local/lib/x86_64-linux-gnu would hardly be at the ld.so.conf list of > paths for most people. So, when one would try to run a program, it will > fail. This depends on the distribution. On Debian-like distributions, to enable multi-arch support, an arch-specific directory is used. Debian adds it to ld.so.conf (for both /usr/lib and /usr/local/lib). On other distributions, /usr/lib or /usr/lib64 will be used by meson. > > As mentioned in another response. Autotools is building with `-g -O2` by > > default, that'd the equivalent meson configuration option > > --buildtype=debugoptimized. > > I can't understand the Meson's default... no optimization and no debug! > Basically something that it is useless for both developers and for > production. I wonder why they chose a crap default like that... The default is debug, so it includes debug (and no optimization). This can be overridden at the project level with default_options : ['buildtype=debugoptimized'] in the project() function. > > With this configuration the installtion > > sizes are not that different: > > > > $ du -s installation_m* > > 37068 installation_make > > 37848 installation_meson > > It sounds a lot more coherent. > > > In this case the difference is related to libtool `.la` files not being > > generated by meson and gconv/ only installed by meson. The latest is > > probably a feature being only detected by meson in this case, will check > > that out. > > It was opted to not enable gconv by default, as similar patchset - needed > to support ARIB STD B-24 charset used by Japanese digital TV - was sent to > gconv upstream (not sure if it was merged or not). On other words, the > contrib/gconv stuff is independent of v4l-utils itself: it basically > adds an extra charset to be used by gconv upstream. > > The only reason why it is present at v4l2-utils is that this charset > is present on ISDB tables on TV broadcasts in Japan. The gconv library > needs to support it, in order to convert characters from MPEG tables > to the system's charset. > > Btw, that's basically one of the reasons why we print a summary of the > options when ./configure runs. -- Regards, Laurent Pinchart