mesonbuild / meson Goto Github PK

It would be handy to be able to mark a target as build_always which rebuilds it regardless of dependencies.

A typical use case is generating version header files from version control.

• Should we use the PHONY target as a dependency?
• How should we set Ninja's restat argument?

It would be nice if we could make it work always without users needing to specify extra arguments in their custom target definitions.

When attempting to run tests with Ninja, it will refuse with ninja: no work to do. if the tests have been run once already. Running ninja test should always run all tests.

for example, gobject-introspection-1.0.pc:

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
bindir=/usr/bin
datarootdir=${prefix}/share
datadir=/usr/share
includedir=/usr/include

g_ir_scanner=${bindir}/g-ir-scanner
g_ir_compiler=${bindir}/g-ir-compiler
g_ir_generate=${bindir}/g-ir-generate
gidatadir=${datadir}/gobject-introspection-1.0
girdir=${datadir}/gir-1.0
typelibdir=${libdir}/girepository-1.0

Cflags: -I${includedir}/gobject-introspection-1.0 
Requires: glib-2.0 gobject-2.0
Requires.private: gmodule-2.0 libffi
Libs: -L${libdir} -lgirepository-1.0
Libs.private: 

Name: gobject-introspection
Description: GObject Introspection
Version: 1.43.3

And if I want to properly install gir packages I need to know typelibdir, girdir. I think other pc files can contain such things.

we want to create new file called macros.meson in /usr/lib/rpm/macros.d/ when installing meson into system to easy providing meson functions for RPM packagers.

it should look like:

%__meson /usr/bin/meson

%meson \
  CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
  CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
  FFLAGS="${FFLAGS:-%optflags%{?_fmoddir: -I%_fmoddir}}" ; export FFLAGS ; \
  FCFLAGS="${FCFLAGS:-%optflags%{?_fmoddir: -I%_fmoddir}}" ; export FCFLAGS ; \
  %{?__global_ldflags:LDFLAGS="${LDFLAGS:-%__global_ldflags}" ; export LDFLAGS ;} \
  %__meson \\\
        --prefix=%{_prefix} \\\
        --buildtype=plain

Then in RPM specs packagers can use

%build
pushd rpmbuilddir
    %meson ..
popd

Instead of custom crap.

I found a problem with the boost framework implementation. I suggest to change the boost linkexe test-case to exhibit the problem:

#include<boost/thread.hpp>

boost::recursive_mutex mut;

struct callable {
    void operator()() {
        boost::recursive_mutex::scoped_lock l(mut);
    };
};

int main(int argc, char **argv) {
    callable x;
    boost::thread thr(x);
    thr.join();
    return 0;
}

With this code I get an undefined reference to symbol 'pthread_mutexattr_settype' link error. This may be resolved by appending the -lpthread linker flag. cmake seems to do this automatically, presumably when linking with the boost_thread library. So that is what I suggest (for not knowing any better option).

When using a meson.build in a subdirectory, install_headers and install_man (I couldn't get install_data to do anything) use the wrong source path when running ninja install, relative to the root of the project not the directory in which the meson.build is found. Interestingly, defining an executable as installable works fine.

bash-4.3# ../../../../meson.py ..
The Meson build system
Version: 0.23.0-research
Source dir: /root/slave/runtests/build/test cases/objc/2 nsstring
Build dir: /root/slave/runtests/build/test cases/objc/2 nsstring/build
Build type: native build
Project name: nsstring
Native objc compiler: cc (gcc 4.9.2)
Dependency GnuStep found: YES
Build targets in project: 1
bash-4.3# ninja-build -v
[1/2] cc '-Wall' '-Wpedantic' '-Winvalid-pch' '-g' '-Istringprog.dir' '-I../' '-I.' '-MMD' '-MQ' stringprog.dir/stringprog.m.o '-MF' 'stringprog.dir/stringprog.m.o.d' -o stringprog.dir/stringprog.m.o -c ../stringprog.m
[2/2] cc   -o stringprog stringprog.dir/stringprog.m.o  
FAILED: cc   -o stringprog stringprog.dir/stringprog.m.o  
stringprog.dir/stringprog.m.o: In function `main':
/root/slave/runtests/build/test cases/objc/2 nsstring/build/../stringprog.m:5: undefined reference to `objc_get_class'
/root/slave/runtests/build/test cases/objc/2 nsstring/build/../stringprog.m:5: undefined reference to `objc_msg_lookup'
/root/slave/runtests/build/test cases/objc/2 nsstring/build/../stringprog.m:6: undefined reference to `objc_msg_lookup'
/root/slave/runtests/build/test cases/objc/2 nsstring/build/../stringprog.m:7: undefined reference to `objc_msg_lookup'
stringprog.dir/stringprog.m.o: In function `__objc_gnu_init':
/root/slave/runtests/build/test cases/objc/2 nsstring/build/../stringprog.m:9: undefined reference to `__objc_exec_class'
stringprog.dir/stringprog.m.o:(.data+0x80): undefined reference to `__objc_class_name_NSString'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

but when I'm doing cc -lgnustep-base -lobjc ../stringprog.m -o out no linker error and it works as expected

Hello,
I' ve got the project structure - src and include directories and additionally build directory for Meson. I generate all the library files within the meson.build in src directory, install headers in meson.build in include directory and get this all together with root meson.build. When including headers, on Windows (MinGW) I can write 'install_headers('header1.h', 'header2.h', (other options))', but to get the same setup to work on Linux I must use version 'install_headers('include/header1.h', 'include/header2.h', (other options))'. I think it should be more consistent, because in this case I have to write two different build flows for both platforms.

A common requirement is to create a source file that has the release number or revision control tag as a string. So something like this:

const char *vcs_tag = "1.0.0-8e8bg2e";

This tag needs to be updated on every build.

Maybe we should have a command to help generating them semiautomatically. Something like

src = vcs_info(
input : 'versiontag.c.in',
output : 'versiontag.c',
fallback : '1.0')

Meson would then check in the background which vcs the system is using (git, hg, bzr, svn at least?), grab the revision and write the file. If the revision number has not changed, it needs to not touch the output file so Ninja's restat kicks in and does not rebuild if there are no other changes.

meson.build:

project('proj', 'c')
subdir('data')

data/meson.build:

install_data(sources : 'durka.manager',
             install_dir : 'share/telepathy/managers')
install_data(sources : 'org.freedesktop.Telepathy.ConnectionManager.durka.service',
             install_dir : 'share/dbus-1/services')

meson ..:

Meson encountered an error in file data/meson.build, line 1, column 0:
Data function must have at least one argument: the subdirectory.

https://github.com/jpakkane/meson/wiki/Dependencies doesnt hold an example for multiple dependencies.

https://github.com/jpakkane/meson/blob/master/dependencies.py#L420

self.libdir = '/usr/lib'

this will not work on Fedora, because library on x86_64 will be in /usr/lib64. I think we need to use func_find_library() from interpreter.py to get lib location

It would be very useful to have a full reference of every function and parameter in Meson. As an example, right now I'm trying to find a list of languages to pass to project(), but I think the easiest thing to do it just look at the tests and examples (which should never be the best documentation available!)

The subdir option is one of the most useful ones for install_headers!

The Meson build system
Version: 0.23.0-research
Source dir: /builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/test cases/common/72 build always
Build dir: /builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/work area
Build type: native build
Project name: run always
Native c compiler: ccache cc (gcc 5.0.0)
Program version_gen.py found: YES (/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/test cases/common/72 build always/version_gen.py)
Build targets in project: 2
[1/4] Compiling c object versionprinter.dir/main.c.o
[2/4] 'Generating Version string with a custom command.'
FAILED: '/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/test cases/common/72 build always/version_gen.py' '../test cases/common/72 build always/version.c.in' 'version.c' '1.0.0'
Traceback (most recent call last):
  File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/test cases/common/72 build always/version_gen.py", line 29, in <module>
    generate(infile, outfile, fallback)
  File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/test cases/common/72 build always/version_gen.py", line 9, in generate
    p = subprocess.Popen(['git', 'describe'], cwd=workdir, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "/usr/lib64/python3.4/subprocess.py", line 858, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.4/subprocess.py", line 1456, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'git'
ninja: build stopped: subcommand failed.

I think we need to search for git binary.

I'd like to be able to do the following: have a var/www subdirectory with a bunch of files and subsubdirectories in my sources tree and install that either (A) on my system, i.e. copy the contents of var/www into /var/www (with the prefix set to /usr for all the standard suff); or install it (B) into a $(DESTDIR)/var/www directory for having dpkg-build take care of it later.

My problem is now that (as far as can tell):

• (A) is not possible, since my subdir will allways be prefixed in ninjabackend.py:476
• (B) is not possible, since DESTDIR is not used for subdirs in meson_install.py:35ff
• even if (A) worked, the install target would remove everything from /var/www which would be 'not cool'

I could start hacking and fix all 3 issues (for the ninja nackend) but wanted to check first whether I've overlooked something obvious again.

I want to have something like make dist in meson which will make tarball with sources

It would be of great benefit if Meson supported something similar to GNU Automake's nobase option for installing files (see http://www.gnu.org/software/automake/manual/html_node/Alternative.html).

Keyword arguments unsupported by the respective function should raise an error during parsing, not be silently ignored. A case where this would have made a big difference is the change from include_dirs to include_directories - existing code would fail during building after the Meson upgrade with no clear indication why.

I tried the test case "common/13 pch" on windows with ninja & msvc and get the following error when I run ninja:

meson.py src build
...
cd build
ninja
[3/3] Linking target prog.exe
FAILED: cmd /c link /OUT:prog.exe prog.dir\prog.c.obj "/nologo"
prog.c.obj : error LNK2011: precompiled object not linked in; image may not run
prog.exe : fatal error LNK1120: 1 unresolved externals
ninja: build stopped: subcommand failed.

The problem can be fixed by manually adding the pch object file to the list of objects:

exe = executable('prog', 'prog.c',
c_pch : ['pch/prog_pch.c', 'pch/prog.h'],
objects : '../build/prog_pch.obj')

Meson should automatically add that file.

Why we're installing meson to /usr/share/meson instead of /usr/lib/python3.4/meson?

Main problem is that symlinks from /usr/bin/ to /usr/share/meson/ is not good.

Second problem is that I can't use meson internals (e.g. introspect) from other python progs.

One of the things about build systems that really annoys me is that one has to manually list every header file (with their full paths!) and specify their destination directory (with full paths!). It would be really useful to have some way of reducing the configuration required to cover 99.9% of cases, which is where the subdirectory containing the headers in the source mirrors how it should be installed.

One possible solution is to have an install_headers_dir option, which installs all headers matching a customizable pattern.

Deprecated since version 2.7: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

https://docs.python.org/2/library/optparse.html

Hey,

In environment.py, we have this:

gnulike_buildtype_linker_args = {'plain' : [],
'debug' : [],
'debugoptimized' : [],
'release' : ['-Wl,-O1'],
}

This appears to be the linker flags used by OSX by default. Release builds do not work by default because -O1 is not supported by Apple's crappy ld program (and GNU ld doesn't work on OSX). I believe (but haven't looked into it) that this is also causing some tests to fail currently on OSX. :(

BTW: This is an awesome project, I think it has great potential and it's SOOOOOO much easier to work with than cmake.

I'm trying to get automatically detect custom targets (like GObject introspection) targets to add them to rpm filelists, but I don't want to introspect target.get_custom_install_dir() and generate girepository variable again because duplicating code.

I think we want to add empty variable in custom target holder and set it automatically or force in code of our modules (don't know how better) to modname.CapitalizedFunction or something like this.

Certain methods, in particular get_exe_suffix(), get_shared_lib_suffix() and get_*dir(), can be very useful to use in meson.build. For example, when using install_subdirs to install a header hierarchy it would be ideal to not hardcode 'include' as the destination, instead using something like environment.get_includedir(). I don't know if the meson object is the best place for these methods, or if a new environment object should be created.

It's seems that meson has no support for .app bundles

when we're packaging software we want to install it to %{buildroot}/%{_prefix}/.... and we can't set prefix to %{buildroot}/%{_prefix}/, because it can break auto-config files and etc.

P.S. %{buildroot} in RPM == $(DESTDIR) in automake

I am attempting to migrate an existing project from CMake to Meson. The project uses Qt4. I tried a quick copy-paste of the Qt5 dependency code but discovered a wrinkle: I am on OSX, and installed Qt4 from the .dmg installer. This means pkg-config doesn't know about it. A brief inspection of the relevant CMake stuff suggests they query qmake for config information. Is this something you would consider adding to Meson?

This is the same problem as noted in #5, just for the install script. If a symlink already exists Python does not attempt to overwrite it

conf_data = configuration_data()
tp_durka_exec = prefix + '/' + libexecdir + '/telepathy-durka'
conf_data.set('TELEPATHY_DURKA_EXEC', tp_durka_exec)
configure_file(input : 'org.freedesktop.Telepathy.ConnectionManager.durka.service.in',
               output : 'org.freedesktop.Telepathy.ConnectionManager.durka.service',
               configuration : conf_data)

install_data(sources : 'org.freedesktop.Telepathy.ConnectionManager.durka.service',
             install_dir : dbusservicesdir)

I have this meson.build in one of subdirs. I'm getting error on install step.

FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tito/rpmbuild-telepathy-durkaIFCQz_/BUILD/telepathy-durka-git-0.15f464e/data/org.freedesktop.Telepathy.ConnectionManager.durka.service'

I've tried to do something like service = configure_file(...blah...) and use it to install, but looks like configure_file() doesn't return anything.

Hello,
I had to separate Meson build flow for Windows and Linux. For that, I had to use the build.name() function from the build object that is not documented anywhere. Please add the documentation for this object so that people do not have to search through test cases to find the solution like I had.

How would I include the value of an environment variable in either my meson.build or meson_options.txt files? Is that even possible?

E.g.
option('someoption', type : 'string', value : ${SANDBOX})

Hello,

I' ve got the project structure - src and include directories and additionally build directory for Meson. I generate all the library files within the meson.build in src directory, install headers in meson.build in include directory and get this all together with root meson.build. When I try to build and install the versioned shared libraries, installed symbolic links point to src/target.so.x.x.x instead of plain target.so.x.x.x - this breaks the entire library installation. Any ideas?

It would be good if headers() could support storing the list of headers in a variable, much like build targets with sources: ...

In many cases writing meson.build is a very tedious process, involving lots of duplicated and near-identical lines. It would be very useful to have support for defining methods, which can wrap multiple calls into a single call with argument passing, like CMake supports with functions. For example:

test('foo', executable('foo', 'test/foo.cpp', include_directories: inc, dependencies: test_lib))
test('bar', executable('bar', 'test/bar.cpp', include_directories: inc, dependencies: test_lib))
test('foobar', executable('foobar', 'test/foobar.cpp', include_directories: inc, dependencies: test_lib))

could become:

method('run_test', 'test', {
    test($test, executable($test, 'test/'$test'.cpp', include_directories: inc, dependencies: test_lib))
})

run_test('foo')
run_test('bar')
run_test('foobar')

or even:

method('run_tests', 'test_array' {
    foreach($test_array, 'test', {
        test($test, executable($test, 'test/'$test'.cpp', include_directories: inc, dependencies: test_lib))
    })
})

run_tests(['foo', 'bar', 'foobar'])

I'd be happy to help implement this, but my Python skills are rather sub-standard (read: non-existent).

I am creating a project in wxWidgets and I want to use Meson to compile it. wxWidgets uses its own "*-config" tool called wx-config (or sometimes wx-config-versionnumber for older library version, but it appears to be handled by newer wx-config as well with the --version=... option). It is slightly extended custom pkg-config tool and has similar options (like -cflags, -cxxflags, -libs). Unfortunately, this means they do not use pkg-config at all (and they are not planning to, as I searched through the discussion about it). While I will probably find a workaround for this project, it would be nice to have wx-config support in Meson' s dependency module.

I' ve got the project structure - src and include directories and additionally build directory for Meson. I generate all the library files within the meson.build in src directory, install headers in meson.build in include directory and get this all together with root meson.build. When I try to define the external dependencies or even the dependencies I built within different library project earlier with Meson, where on Linux they work perfectly, on Windows MinGW find_library cannot detect the .a static library files I installed earlier into the /lib directory (in MSYS) and dependency cannot even find the MSYS version of pkg-config. I think this should be fixed somehow.

I've created a meson.build file with

boost_dep = dependency('boost', modules : ['thread', 'system', 'unit_test_framework'])

When executing, I get the following message:

Meson encountered an error in file meson.build, line 3, column 0: Requested Boost module "unit_test_framework" not found.

However if I execute my cmake file with

find_package(Boost COMPONENTS unit_test_framework thread system REQUIRED)

the build does work.

This is obviously unexpected behaviour and hinders me from using meson for an own project. Or am I doing something wrong?

Meson looks like a great possible replacement for CMake and other build systems. I would like to encourage you to continue working on it. If I were a Python developer, I would definitely provide pull requests. Perhaps I can help by providing usage testing and feedback? I have a lot of experience with build systems -- I've been programming professionally a very long time. :-)

My current environment looks like this. I am having some difficulty figuring out how to make Meson work with it. Production software is installed in a tree based at prefix. By default, the working copy of our source repository is checked out into the src directory.

prefix/
|-- bin
|-- etc
|-- include
|-- lib
|-- logs
|-- share
`-- src

The source tree has a wide variety of apps and libraries, organized within various related subdirectories.

src
|-- .git
|-- app1
|-- app2
|-- subsystem1
|   |-- comp1
|   |-- comp2
|   `-- subsyslib
|-- lib
`-- share

Most commonly, a compile needs to include headers from 4 places: source directory, prefix/include, /usr/include and /usr/local/include. E.g.

clang++ -I. -I${PREFIX}/include -I/usr/include -I/usr/local/include

I have not figured out how to make this happen. How do I configure this?

Similarly, a link usually needs to use libraries from 3 places: prefix/lib, /usr/lib and /usr/local/lib. E.g.

clang++ -L${PREFIX}/lib -L/usr/lib -L/usr/local/lib

Same question -- how do I make that happen?

I really like that you do not allow in-source builds. That is one of the biggest problems with CMake; if one accidentally runs cmake in a source directory, there is no way to avoid cluttering the directory with CMake files (and sometimes overwriting any custom Makefile located there).

Installing RPM macros to /home/brain/rpmbuild/BUILDROOT/meson-0.22.0-7.20150321gita5f30e7.fc23.x86_64/usr/lib/rpm/macros.d.
Traceback (most recent call last):
  File "./install_meson.py", line 112, in <module>
    shutil.copyfile('macros.meson', outfilename)
  File "/usr/lib64/python3.4/shutil.py", line 108, in copyfile
    with open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: '/home/brain/rpmbuild/BUILDROOT/meson-0.22.0-7.20150321gita5f30e7.fc23.x86_64/usr/lib/rpm/macros.d/macros.meson'

We need to do mkdir I think and have install option in OptionParser instead of check if path exists

To complement the 'install' target, there could also be an 'uninstall' target that reverts the changes. Alternatively (or alongside?), allow the meson_install.py to overwrite any existing files

I have the following simple meson build file on windows and the visual studio 2013 toolchain:

project('wintest', 'cpp')
lib = shared_library('hello', 'hello.cpp')
prog = executable('prog', 'prog.cpp', link_with : lib, link_args : 'user32.lib')

Executing "meson . obj" yields:

[...]
File "C:\work\meson\ninjabackend.py", line 1242, in generate_link
commands += linker.get_soname_args(target.name, abspath, soversion)
TypeError: get_soname_args() takes 3 positional arguments but 4 were given

I fixed this by adding the "soversion" parameter to the function "get_soname_args"
in the "CCompiler" class:

def get_soname_args(self, shlib_name, path, soversion):
return []

When I run ninja I get the following output:

[2/5] Compiling cpp object hello.dir\hello.cpp.obj
FAILED: cl "/nologo" "/showIncludes" "/W3" "/MDd" "/Zi" "/Ob0" "/Od" "/RTC1" "/L
D" "-Ihello.dir" /Fohello.dir\hello.cpp.obj /c ..\hello.cpp
..\hello.cpp : fatal error C1041: cannot open program database 'c:\work\meson\my
test\obj\vc120.pdb'; if multiple CL.EXE write to the same .PDB file, please use
/FS

I suggest adding "/FS" to the default C/C++ flags for parallel builds on Visual Studio 2013 and above.

Then when I run ninja a second time it shows:

LINK : warning LNK4044: unrecognized option '/LD'; ignored
LINK : warning LNK4044: unrecognized option '/Wl,-rpath,C:\work\meson\mytest\obj
"'; ignored

The option "/LD" is a compiler flag and shouldn't be passed to the linker.

Obviously the second warning shows a gcc compiler flags that isn't handled by the visual studio compiler.
I fixed this by adding the following code to the "VisualStudioCCompiler" class:

def build_rpath_args(self, build_dir, rpath_paths, install_rpath):
return []

I hope this helps.

I think I can implement subj, but I need to know is it needed, what we're expecting from this. Some thoughts:

• we can aggregate all dependency() and add to .spec file via BuildRequires: pkgconfig(XXX)
• we can use vcs_tag() to get version-release
• we can use project() to get Name:

I think this would be useful to allow developers properly package RPM or DEB or something.

Probably I can add just new rpm module and add generate_spec() function which will create new spec with needed info.

What do you think?

I've tried to use pre-compiled header for my project, but failed.

Digging into the test cases/common/14 cpp pch and try to build it, I got the following error

$ clang --version
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ ninja
[2/3] Compiling cpp object prog.dir/prog.cc.o
FAILED: c++ '-Wall' '-Winvalid-pch' '-g' '-Iprog.dir' '-Iprog.dir' '-include' 'prog.hh' '-MMD' '-MQ' 'prog.dir/prog.cc.o' '-MF' 'prog.dir/prog.cc.o.d' -o prog.dir/prog.cc.o -c ../prog.cc
In file included from <built-in>:175:
<command line>:1:10: fatal error: 'prog.hh' file not found
#include "prog.hh"
         ^
1 error generated.
ninja: build stopped: subcommand failed.

It seems that '-include' 'prog.hh' should be '-include' 'pch/prog.hh'.