mesonbuild / meson Goto Github PK
View Code? Open in Web Editor NEWThe Meson Build System
Home Page: http://mesonbuild.com
License: Apache License 2.0
The Meson Build System
Home Page: http://mesonbuild.com
License: Apache License 2.0
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.
$ ./mesonintrospect.py --targets /home/brain/git/GNOME/gnome-keysign/build
Traceback (most recent call last):
File "./mesonintrospect.py", line 160, in <module>
list_targets(coredata, builddata)
File "./mesonintrospect.py", line 47, in list_targets
t['filename'] = os.path.join(target.subdir, target.get_filename())
File "/usr/lib64/python3.4/posixpath.py", line 79, in join
if b.startswith(sep):
AttributeError: 'list' object has no attribute 'startswith'
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 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.
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?
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):
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
Traceback (most recent call last):
File "./meson.py", line 184, in <module>
app.generate()
File "./meson.py", line 135, in generate
intr.run()
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 762, in run
self.evaluate_codeblock(self.ast)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 784, in evaluate_codeblock
raise e
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 778, in evaluate_codeblock
self.evaluate_statement(cur)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 826, in evaluate_statement
return self.evaluate_if(cur)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 1578, in evaluate_if
self.evaluate_codeblock(node.elseblock)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 784, in evaluate_codeblock
raise e
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 778, in evaluate_codeblock
self.evaluate_statement(cur)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 818, in evaluate_statement
return self.assignment(cur)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 1460, in assignment
value = self.evaluate_statement(node.value)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 816, in evaluate_statement
return self.function_call(cur)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 1442, in function_call
return self.funcs[func_name](node, posargs, kwargs)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/interpreter.py", line 1122, in func_dependency
dep = dependencies.find_external_dependency(name, kwargs)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/dependencies.py", line 802, in find_external_dependency
dep = packages[name](kwargs)
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/dependencies.py", line 672, in __init__
self.detect()
File "/builddir/build/BUILD/meson-c6dbf98a055bb0fe1d36fc9f4f757b67ca613f01/dependencies.py", line 677, in detect
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: 'gnustep-config'
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'
.
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.
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.
I think I can implement subj, but I need to know is it needed, what we're expecting from this. Some thoughts:
dependency()
and add to .spec
file via BuildRequires: pkgconfig(XXX)
vcs_tag()
to get version-releaseproject()
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?
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.
It would be good if headers()
could support storing the list of headers in a variable, much like build targets with sources: ...
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.
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
https://github.com/jpakkane/meson/wiki/Dependencies doesnt hold an example for multiple dependencies.
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!)
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?
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.
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.
It would be nice if we could make it work always without users needing to specify extra arguments in their custom target definitions.
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).
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.
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.
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.
Deprecated since version 2.7: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.
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.
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
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
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.
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.
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.
/usr/include/wx-2.8/wx/string.h:692:3: note: conversion of argument 1 would be ill-formed:
../test cases/frameworks/9 wxwidgets/wxprog.cpp:25:36: error: invalid conversion from 'const char*' to 'wxChar {aka wchar_t}' [-fpermissive]
menuBar->Append(menuFile, "&File");
^
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).
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.
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
test cases/common/45 alignment
stdout
---
The Meson build system
Version: 0.23.0-research
Source dir: /builddir/build/BUILD/meson-a084a8ec3ec12e91c3897dc6b805636be6d36527/test cases/common/45 alignment
Build dir: /builddir/build/BUILD/meson-a084a8ec3ec12e91c3897dc6b805636be6d36527/work area
Build type: native build
Project name: alignment
Native c compiler: ccache cc (gcc 5.0.0)
Checking for alignment of "char": 1
Checking for size of "void*": 4
Checking for alignment of "double": 8
Meson encountered an error in file meson.build, line 23, column 2:
Error encountered: Alignment of double misdetected.
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.
---
test cases/frameworks/4 qt5
stdout
---
The Meson build system
Version: 0.23.0-research
Source dir: /builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/test cases/frameworks/4 qt5
Build dir: /builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/work area
Build type: native build
Project name: qt5 build test
Native cpp compiler: ccache c++ (gcc 5.0.0)
Found pkg-config: /usr/bin/pkg-config (0.28)
Dependency Qt5Widgets found: YES 5.4.0
Dependency Qt5 tools:
---
stderr
---
Traceback (most recent call last):
File "./meson.py", line 184, in <module>
app.generate()
File "./meson.py", line 135, in generate
intr.run()
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 762, in run
self.evaluate_codeblock(self.ast)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 784, in evaluate_codeblock
raise e
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 778, in evaluate_codeblock
self.evaluate_statement(cur)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 818, in evaluate_statement
return self.assignment(cur)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 1460, in assignment
value = self.evaluate_statement(node.value)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 816, in evaluate_statement
return self.function_call(cur)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 1442, in function_call
return self.funcs[func_name](node, posargs, kwargs)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/interpreter.py", line 1122, in func_dependency
dep = dependencies.find_external_dependency(name, kwargs)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/dependencies.py", line 818, in find_external_dependency
dep = packages[name](kwargs)
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/dependencies.py", line 556, in __init__
self.find_exes()
File "/builddir/build/BUILD/meson-d5329489a15c6759941a228035d68e962deed21c/dependencies.py", line 577, in find_exes
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: 'moc'
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).
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.
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.
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
The subdir
option is one of the most useful ones for install_headers
!
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'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?
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).
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.
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})
It's seems that meson has no support for .app bundles
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.