summaryrefslogtreecommitdiff
path: root/test cases/d/11 dub
AgeCommit message (Collapse)Author
2025-03-05dependencies/dub: First try to describe local projectAndrei Horodniceanu
The current approach of determining dub dependencies is by specifying a name and, optionally, a version. Dub will then be called to generate a json summary of the package and code in meson will parse that and extract relevant information. This can be insufficient because dub packages can provide multiple configurations for multiple use-cases, examples include providing a configuration for an executable and a configuration for a library. As a practical example, the dub package itself provides an application configuration and multiple library configurations, the json description of dub will, by default, be for the application configuration which will make dub as a library unusable in meson. This can be solved without modifying the meson build interface by having dub describe the entire local project and collecting dependencies information from that. This way dub will generate information based on the project's 'dub.json' file, which is free to require dependencies in any way accepted by dub, by specifying configurations, by modifying compilation flags etc. This is all transparent to meson as dub's main purpose is to provide a path to the library file generated by the dependency in addition to other command-line arguments for the compiler. This change will, however, require that projects that want to build with meson also provided a 'dub.json' file in which dependency information is recorded. Failure to do so will not break existing projects that didn't use a 'dub.json', but they will be limited to what the previous implementation offered. Projects that already have a 'dub.json' should be fine, so long as the file is valid and the information in it matches the one in 'meson.build'. For example for a 'dependency()' call in 'meson.build' that dependency must exist in 'dub.json', otherwise the call will now fail when it worked previously. Using a 'dub.json' also has as a consequence that the version of the dependencies that are found are the ones specified in 'dub.selections.json', which can be helpful for projects that already provide a 'dub.json' in addition to 'meson.build' to de-duplicate code. In terms of other code changes: - multiple version requirements for a dub dependency now work, though they can only be used when a 'dub.json' is present in which case the version of dependencies is already pinned by 'dub.selections.json' - the 'd/11 dub' test case has been changed to auto-generate the 'dub.json' config outside of the source directory, as the auto-generated file triggers warning when parsed by dub, which upsets the new code as the warnings interfere with the legitimate output. Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
2025-01-27allow to compare multiple version with version_compareCharles Brunet
2024-08-06reactivate dub testsRemi Thebault
Closes: https://github.com/mesonbuild/meson/pull/12143
2023-05-18Check dub version (#11794)Remi Thebault
* DubDependency._check_dub returns the version * check for compatible Dub version Dub versions starting at 1.32 have a new cache structure into which Meson doesn't know where to find compatible artifacts * skipping D tests involving Dub * refactor _check_dub makes mypy happier * make linters happy * localize some logic
2022-03-03ignore dub.json in test "d/11 dub"Remi Thebault
2018-06-17test cases: add test case for dubFFY00