Include inih via wrap about cloudflare-ddns HOT 10 CLOSED

Thanks for the info! I've made the switch :)

I've noticed an issue with the inih wrap though, as it references a "inireader_dep" dependency that doesn't exist. It's called "INIReader_dep". I think it should be fixed in https://github.com/mesonbuild/wrapdb/blob/master/subprojects/inih.wrap

from cloudflare-ddns.

Thanks for pointing it out. I haven't used wraps in a while though, how do they handle projects that do not use Meson (like curl and simdjson)?

I believe that I originally chose not to use wraps because I couldn't get them to work with the curl subproject, so I preferred to keep things consistent and only use git submodules (yeah they require git, but Meson can init them when needed just like wraps and that's handy).

If wraps work with simdjson and curl too I'd be happy to switch :)

from cloudflare-ddns.

Thanks for pointing it out. I haven't used wraps in a while though, how do they handle projects that do not use Meson (like curl and simdjson)?

For those you would still have to use git submodules.

I believe that I originally chose not to use wraps because I couldn't get them to work with the curl subproject, so I preferred to keep things consistent and only use git submodules (yeah they require git, but Meson can init them when needed just like wraps and that's handy).

Hm, I guess it's not consistent, and if that bothers you feel free to close the issue. Compared to submodules they offer some advantages when it comes to building from tarballs, as git submodules are usually not included in those (e.g. on GitHub, but also when running git archive).

from cloudflare-ddns.

You can have a wrap that is also a submodule, and in that case Meson will use git submodule update --init to try to retrieve it.

The url in the wrap file is still used in the event that you build from a tarball instead of a git checkout. Or, you can exclusively use the url in the wrap file for consistency between git and tarball builds.

The difference between cmake-type and meson-type subprojects is not important here. The former should work with wrap files just as well, the only difference being that it cannot use wrap dependency fallback (and thus cannot have a [provide] section) and must still use an explicit cmake.subproject() to run the wrap resolver.

from cloudflare-ddns.

I've noticed an issue with the inih wrap though, as it references a "inireader_dep" dependency that doesn't exist. It's called "INIReader_dep". I think it should be fixed in https://github.com/mesonbuild/wrapdb/blob/master/subprojects/inih.wrap

Thanks for catching! I opened a PR: mesonbuild/wrapdb#338

from cloudflare-ddns.

I've noticed an issue with the inih wrap though, as it references a "inireader_dep" dependency that doesn't exist. It's called "INIReader_dep". I think it should be fixed in https://github.com/mesonbuild/wrapdb/blob/master/subprojects/inih.wrap

Did you try it first? :)

from cloudflare-ddns.

Did you try it first? :)

Yep, it doesn't work. The meson.build files creates the INIReader_dep object, and the inireader = inireader_dep line in the wrap file points to an object that doesn't exist

from cloudflare-ddns.

You can fix it locally by changing inireader = inireader_dep to inireader = INIReader_dep in the wrap file if it's urgent.

from cloudflare-ddns.

There are two wrapdb PRs to fix it, the first of which tried to fix the key and the second of which tries to fix the value.

The key is fine, the value isn't.

from cloudflare-ddns.

You can fix it locally by chaing inireader = inireader_dep to inireader = INIReader_dep in the wrap file if it's urgent.

Nah that's not that big of a deal, I can always do dependency('INIReader', fallback: ['inih', 'INIReader_dep']). It was just to let you know that the wrap is partially broken :)

from cloudflare-ddns.