[Discussion] How should dependency management API look?

[cyanidle]

At some point we should try to create API for consuming third-party code

I am a very CMake person, but have some experience in meson. I think the best model is in meson.

Opening this as a thread for suggestions for API of deps management.

Note: this should probably be done only after targets are implemented in some way

[TomasBorquez]

I was thinking about this the other day, I guess we would need to write a simple .tar extractor to make it more generic to exctract files both in windows and linux. About the API, I'm not sure, maybe a .json to display dependencies, and cache on mate-cache.json to know if we already downloaded and extracted

[og-mrk]

I was thinking about this the other day, I guess we would need to write a simple .tar extractor to make it more generic to exctract files both in windows and linux. About the API, I'm not sure, maybe a .json to display dependencies, and cache on mate-cache.json to know if we already downloaded and extracted

Using an already made parser for json would add an extra dependency to mate.h (for example cJSON), which wouldn't be a major problem, but I think it'a a good idea to add inforced schema for how to describe a dependency in the .json, like what fields are allowed to be used, and how big each field is, and some URL validation (if the URL failed to be retrieved due to network issues or the URL is poorly formatted), all of which will be checked at runtime of the compiled build script.

Also, if we want to implement CMake-like dependency handling with URLs, we'll probably gonna use curl library for this, which also adds another dependency to mate.h

[TomasBorquez]

I was thinking about this the other day, I guess we would need to write a simple .tar extractor to make it more generic to exctract files both in windows and linux. About the API, I'm not sure, maybe a .json to display dependencies, and cache on mate-cache.json to know if we already downloaded and extracted

Using an already made parser for json would add an extra dependency to mate.h (for example cJSON), which wouldn't be a major problem, but I think it'a a good idea to add inforced schema for how to describe a dependency in the .json, like what fields are allowed to be used, and how big each field is, and some URL validation (if the URL failed to be retrieved due to network issues or the URL is poorly formatted), all of which will be checked at runtime of the compiled build script.

Also, if we want to implement CMake-like dependency handling with URLs, we'll probably gonna use curl library for this, which also adds another dependency to mate.h

Yep, schema validation is also necessary but I feel that can be written by us anyways, same with the URL parser, so we need:

• JSON Parser (can be a minimal one and we build our own abstraction)
• Schema Validator (can be written by us)
• Curl (not really sure about this)
• Tar Extractor (can be written by us)

[cyanidle]

Curl is a big dependency. We could use __has_include(<curl.h>) to detect its presence on UNIX systems / use WinAPI on Windows. But then the command-line to compile mate script start involving linking.

[cyanidle]

I also think that it is a very bad idea to delve into own full-fledged dependency management. I was talking about consuming pkg-config .pc files and maybe some kind of simple find_library(name.a/name.so/name).

Fetching archives is a very distant goal for now

[cyanidle]

Please no shitty DSL in json files! The whole point of header only build system is that everythin is written in C, no parsers except the compiler are needed!

The dependencies should be specified inside mate.c. Also itd be best to use Targets API once that part is done