Add wrap files for xtensor-0.21.5 #3
Conversation
|
Why not go straight to 0.21.10? |
0.21.5 is the version our projects use right now, we don't currently have the time to update it |
|
Since it's actively being used, I'll accept that logic and merge old stuff anyway. :) |
| @@ -1,19 +0,0 @@ | |||
| Copyright (c) 2019 The Meson development team | |||
|
|
|||
| Permission is hereby granted, free of charge, to any person obtaining a copy | |||
There was a problem hiding this comment.
Why are you removing this? Are these license terms not suitable for you? The review policy requires this file to exist.
There was a problem hiding this comment.
Looking at existing repos, I only saw this file in master
|
|
||
| source_url=https://github.com/xtensor-stack/xtensor/archive/0.21.5.zip | ||
| source_filename=xtensor-0.21.5.zip | ||
| source_hash=f08aca41dc89128524dec04c82b590d9e0f1e923311e82bab9f024c99e7bb73a |
There was a problem hiding this comment.
Needs to add https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
Upstream provides https://github.com/xtensor-stack/xtensor/blob/master/xtensor.pc.in so users should be able to dependency('xtensor') and the [provide] section tells meson how to find that dependency without using fallbacks.
|
|
||
| json_dep = dependency('nlohmann_json', | ||
| version:'>=3.1.1', | ||
| fallback : ['nlohmann_json', 'nlohmann_json_dep'], |
There was a problem hiding this comment.
Fallback should not be necessary if the wrapdb is used, because of https://github.com/mesonbuild/nlohmann_json/blob/15f5c53d5fd354469fb4f801da1030ba1106161c/upstream.wrap#L9-L10
|
|
||
| xtl_dep = dependency('xtl', | ||
| version:['>=0.6.12', '<1.0.0'], | ||
| fallback : ['xtl', 'xtl_dep'], |
There was a problem hiding this comment.
Likewise here, if mesonbuild/quantstack-xtl#1 includes a provide section, you should not need an explicit fallback.
| dependencies: [xtl_dep, json_dep, xsimd_dep], | ||
| compile_args: xtensor_cpp_arg) | ||
| else | ||
| xtensor_dep = dependency('', required: false) # aka "not found" |
There was a problem hiding this comment.
I'm not sure I comprehend what's going on here. Shouldn't you just make every single required dependency be, well, required, and have the subproject fail if it cannot, in fact, be successfully configured to produce the subproject's entire reason for existing?
Am I missing something?
|
Will think about it and try again later |
No description provided.