Questions for porting from autotools to meson

[Benjamin Redelings]

Hi,

I'm trying to port my project from autotools to meson (https://github.com/bredelings/BAli-Phy/).  I am new to meson, so if this is the wrong place for these questions please let me know.

1. My project has 58 build targets, and source files used in multiple projectes seem to get built multiple times.  One of these source files (for example) was built about 45 times (according to compile_commands.json), which makes meson slower than autotools.  Is there a "meson way" of handling multiple targets with the same sources?  I haven't found any documentation that mentions this issue, but maybe I haven't been looking long enough.  I did see the page that mentions that you can extract a build object from a target and use in in another target, but it did not seem that this was the meson way of doing things, because it requires to user to specify things that the build system already knows in a number of different places, instead of specifying it once.  Also, the docs seem to recommend that people NOT do this, except for unit tests.

2. What is the recommended way to install scripts?  Autotools has specific docs on installing scripts, but I don't see any for autotools.  Do we use install_data( )?

3. I'm building some targets with shared_module( ).  My code will dlopen( ) them.  They all get a 'lib' prepended to their name - how do I tell meson not to do this?

4. When the ninja build file changes, meson quickly prints the following, and then does nothing (or nothing visible) for about 30 sec.

[0/1] Regenerating build files.
The Meson build system
Version: 0.43.0
Source dir: /home/bredelings/Devel/bali-phy/master
Build dir: /home/bredelings/Devel/bali-phy/master/meson
Build type: native build
Project name: bali-phy
Native C++ compiler: c++ (gcc 7.2.0)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29)
Native dependency cairo found: YES 1.15.8
Dependency Boost (program_options, random, system, filesystem, chrono) found: YES 1.62
Library dl found: YES
Build targets in project: 58
Found ninja-1.8.2 at /usr/bin/ninja
[.... wait here for a long time ...]
[1/656] Compiling C++ object ...

'top' suggests that python is running the linker during part of this time - what might it be doing?

-BenRI

[Jussi Pakkanen]

On Fri, Dec 8, 2017 at 11:52 PM, Benjamin Redelings
<benjamin....@gmail.com> wrote:

> 1. My project has 58 build targets, and source files used in multiple
> projectes seem to get built multiple times. One of these source files (for
> example) was built about 45 times (according to compile_commands.json),
> which makes meson slower than autotools. Is there a "meson way" of handling
> multiple targets with the same sources? I haven't found any documentation

The usual solution is to put all common code in a static library and
link that to the targets that need it. Then it is compiled only once.

> 2. What is the recommended way to install scripts? Autotools has specific
> docs on installing scripts, but I don't see any for autotools. Do we use
> install_data( )?

Yes.

> 3. I'm building some targets with shared_module( ). My code will dlopen( )
> them. They all get a 'lib' prepended to their name - how do I tell meson
> not to do this?

name_prefix : ''

http://mesonbuild.com/Reference-manual.html#library

> Found ninja-1.8.2 at /usr/bin/ninja
> [.... wait here for a long time ...]
> [1/656] Compiling C++ object ...
>
> 'top' suggests that python is running the linker during part of this time -
> what might it be doing?

It's hard to say based on this information alone but if it is invoking
the linker it would indicate that it's running compile tests
(cpp.has_header() etc). If you are running a lot of checks using for
example Boost, then it might take a while. If not then that is may be
a bug of some sort. Please file an issue with as much additional
detail as possible.

[Benjamin Redelings]

Thanks for the help!  I really appreciate it.  Making a static lib worked well and did not increase the size of the executables, perhaps because of -Wl,--as-needed.  On a 6-core workstation, meson+ninja builds 3x faster than autotools, and 2x faster if I don't let ninja use 2 processes per core.

I have two more questions that I was wondering if people could perhaps help me out with:

4. I have an external unit test suite, and I'm not sure how to integrate this with meson.  I was able to get meson to run a test (below), but (a) it doesn't show any test output and (b) it fails because the test takes too long.  Is there an example of how to include an external test suite somewhere?

Also, I'm not sure if the code below uses the "correct" way of finding uninstalled components so that they can be used for testing the uninstalled binary.  Here 'builtins' assumes that some uninstalled *.so files are in the directory that they were built in, and I run python using 'find_program'.  But perhaps there is a better way.

python = find_program('python')
tests = join_paths(meson.source_root(),'tests')
run_tests = files('tests/run-tests.py')
baliphyexe = join_paths(meson.build_root(),'src/bali-phy')
builtins = join_paths(meson.build_root(),'src/builtins')

test('internal testsuite', python,
     args: [run_tests, baliphyexe, '--package-path=@0@:@1@'.format(builtins,meson.source_root())],
     workdir: tests)

5.  I generally build with gcc-7, but I want to run on linux systems with an older gcc.  My solution is to find the libstdc++.so file used in the build and put it in lib/<package-name>/, and then add
 -rpath $ORIGIN/../lib/<package-name>
to the link command.

On windows, I find a few gcc-specific DLLs and put them in the bin/ directory, which allows mingw builds to work with no external libraries.

Does meson have any way of finding these libraries, so I can install them into my package directories?

-BenRI

[Jussi Pakkanen]

On Tue, Dec 19, 2017 at 4:43 PM, Benjamin Redelings
<benjamin....@gmail.com> wrote:

> 4. I have an external unit test suite, and I'm not sure how to integrate
> this with meson. I was able to get meson to run a test (below), but (a) it
> doesn't show any test output and (b) it fails because the test takes too
> long. Is there an example of how to include an external test suite
> somewhere?

a) the output is captured and put in the meson-logs directory.
b) you probably want to increase the test's timeout value:

http://mesonbuild.com/Reference-manual.html#test

> python = find_program('python')

> run_tests = files('tests/run-tests.py')

Just do run_tests = find_program('tests/run-tests.py'). It does all
the magic necessary to make this work (even on Windows when Python is
not installed)

> 5. I generally build with gcc-7, but I want to run on linux systems with an
> older gcc. My solution is to find the libstdc++.so file used in the build
> and put it in lib/<package-name>/, and then add
> -rpath $ORIGIN/../lib/<package-name>
> to the link command.

If you just want to run them, then probably linking stdlibc++
statically is the simplest answer. There is a linker argument for
that, see the manpages.

> Does meson have any way of finding these libraries, so I can install them
> into my package directories?

If they are in your source tree, you can install them with install_data().