Comments (5)
The whole threading issue with compilers and systems is complicated (as one would expect). I really want to have a good solution for the general case but unfortunately don't have all the knowledge, especially on the Windows side of things.
In the mean time I'll do a fix for this particular case soon, because it really should work automatically.
from meson.
Perhaps it doesn't make sense to use the dependency()
construct to define a testing framework? It might be better to have an additional parameter to the test()
construct, a framework
parameter? Then that parameter would bring in the required dependencies, which may be more than one (like here: Boost testing framework requires unit_test_framework
, system
and pthreads
).
IMHO it makes sense for dependency()
to require explicit declaration of all libraries required - it shouldn't do automatic dependency evaluation.
from meson.
I agree with Jussi: this should work automatically. Especially since the dependency on pthreads is an implementation detail (and platform specific). If there were proper (upstream) pkg-config support for boost, it would also list -lpthreads in its --libs list (at least, I would expect it to. see also https://svn.boost.org/trac/boost/ticket/1094)
If someone wonders why an explicit -pthread is necessary when using the boost::mutex but not when using boost::thread, even though the implementation of the latter is also clearly dependent on libpthread. Here is some background: https://wiki.debian.org/ToolChain/DSOLinking.
Also: this issue has nothing to do with 'testing'. I simply modified the existing test to have a quick and easy example to reproduce the issue. Having said that, there might be other boost libs than boost_thread that have #include-based dependencies on external libs.
from meson.
The boost test case now works for me, but my own project does not configure anymore. I get the following python exception:
Traceback (most recent call last):
File "/home/axel/bin/meson.py", line 184, in <module>
app.generate()
File "/home/axel/bin/meson.py", line 147, in generate
g.generate()
File "/home/axel/contrib/meson.git/ninjabackend.py", line 132, in generate
[self.generate_target(t, outfile) for t in self.build.get_targets().values()]
File "/home/axel/contrib/meson.git/ninjabackend.py", line 132, in <listcomp>
[self.generate_target(t, outfile) for t in self.build.get_targets().values()]
File "/home/axel/contrib/meson.git/ninjabackend.py", line 263, in generate_target
elem = self.generate_link(target, outfile, outname, sorted(obj_list), linker, pch_objects)
File "/home/axel/contrib/meson.git/ninjabackend.py", line 1293, in generate_link
commands += linker.thread_link_flags()
AttributeError: 'ArLinker' object has no attribute 'thread_link_flags'
from meson.
I pushed a fix.
from meson.
Related Issues (20)
- Windows: meson doesnt detect gcc despite being available in PATH on MSVC dev console HOT 2
- Cannot cross-compile on macOS, "Unable to detect linker for compiler `cpp -Wl,--version -fuse-ld=ld`" HOT 4
- [Java] compiling java code is VERY slow HOT 4
- Check stdout/stderr from test run HOT 4
- utf-8 decode error when loading hdf5 dependency HOT 6
- Using str objects for d_import_dirs leads to an unhandled python exception
- build_by_default isnt respected when install is true during compilation HOT 1
- fs.copyfile() does not allow relative destination directories HOT 2
- compiler.find_library() always fails with a Fortran compiler and prefer_static=true HOT 2
- rust: Unable to use subproject to make use of pest_derive create HOT 6
- cmake: Subproject does not use native-compilation for targets HOT 2
- Option --genvslite correctly generates project that can be open but compiles nothing HOT 1
- C++: Nested wrap library is imported, but not included. HOT 1
- Specifying clang-cl as a compiler prevents linking with link.exe
- Meson incorrectly detects MinGW environment when running under MSYS2 HOT 3
- Missing warning on use of `meson.add_dist_script()` with `meson_version: '>=0.40'`
- implicit_include_directories equivalent for cmake projects
- Undocumented or non-existing way to provide `program_names` with a method = cmake wrap. HOT 2
- Meson error under windows10 HOT 3
- Copy a file to the build directory at configure time without warnings HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meson.