| Age | Commit message (Collapse) | Author |
|
See https://forums.opensuse.org/t/cant-find-libboost-system-devel-dependency/188865.
|
|
Build hotdoc from the git repository to work around the build failures
resulting from C99 incompatibilities. The issues are already fixed,
but the fix has not made it into a release yet.
Signed-off-by: Michał Górny <mgorny@quansight.com>
|
|
See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/BJO756KHSCBPDMXVGFMGPHPUMW4PZK6T/#SLVEVFEFOCT3R5RCSVZPQN3GZSZYAEXL.
Use sdl2-compat-devel instead. I did try 'pkgconfig(sdl2)' but it failed
with some resolver error I didn't probe further.
|
|
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>
|
|
I can't find the equivalent of opensuse's "last rites" for package
removal but gtk-sharp3-complete appears gone from Factory and I can't find
any reference except for one mentioning it failing to build [0].
Drop it from the list of packages to install to fix the image build.
[0] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/TXFU2U5N3IMN3QA7VRDFLDC5M7NPKFVP/
Signed-off-by: Sam James <sam@gentoo.org>
|
|
These packages are required to test `qml_module` from qt
|
|
The D stdlib function std.process.spawnProcessPosix suffers from a bug
that causes any program that calls it to OOM if the nofile ulimit is
large.
This doesn't affect CI currently but trying to run or build the
containers locally will most likely crash when calling dub as docker
defaults to something like 1073741816 for both the hard limit and soft
limit. Lowering the soft limit is enough to make dub behave.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
|
|
`test_meson_installed` fails without setuptools:
```
$ /usr/bin/python3 run_meson_command_tests.py -v
Meson build system 1.5.99 Command Tests
test_meson_exe_windows (__main__.CommandTests.test_meson_exe_windows) ... skipped 'NOT IMPLEMENTED'
test_meson_installed (__main__.CommandTests.test_meson_installed) ... Traceback (most recent call last):
File "/meson/setup.py", line 12, in <module>
from setuptools import setup
ModuleNotFoundError: No module named 'setuptools'
ERROR
```
|
|
Like in a5211a15207a2e6e30e213c5530a5d1bf5c2531c.
|
|
They do not appear to have 20 in their repos anymore, and no traces can
be found of it in the history, as usual. They do have 11, 17, and 21.
Last time we chose one randomly and hoped it doesn't keep changing
value. This dismally failed: 20 was upgraded to 21. It looks like 17 may
have some staying power.
|
|
They do not appear to have 15 in their repos anymore, and no traces can
be found of it in the history, as usual. They do have 11, 17, and 20, so
choose one randomly and hope it doesn't keep changing value.
|
|
|
|
Remove hard-coded framework test skip logic in skippable(), instead
annotate test.json with environments in which skip is expected.
(Mainly this is done with by testing the value of MESON_CI_JOBNAME now
set for linux jobs)
|
|
|
|
|
|
|
|
|
|
This will be used by the junit validation tests.
|
|
|
|
|
|
|
|
|
|
|
|
|