Design Proposal - Using Conan.io instead of Mason

[thehoneymad]

In this pull request, I am contributing a proposal for:

1. Removing usage of Mason.
2. Using conan.io to manage precompiled binary dependencies.
3. Using conan.io to manage mapbox dependencies such as earcut.cpp and geojson-vt-cpp.

[wipfli]

Typo deprec..

[thehoneymad]

Ooops, will fix. :)

[wipfli]

Thanks for this nice Design Proposal, @thehoneymad. I think it is a good idea to remove Mason. Conan seems like a good option.

[wipfli]

So there will be this conanfile with exact versions if I understand correctly. Is this a bit like an NPM package-lock.json file? And can dependabot make pull requests with updates for us?

[wipfli]

Also how is Mason or now conan related to the dependencies we have in the vendor folder with the submodules?

[ntadej]

What precompiled dependencies do we even have? Aren't all covered by submodules?

[thehoneymad]

Acknowledging comments. Will reply soon.

[thehoneymad]

So there will be this conanfile with exact versions if I understand correctly. Is this a bit like an NPM package-lock.json file? And can dependabot make pull requests with updates for us?

Yes. Conanfile asks for exact version. It does not support version ranges.

On the dependabot question, sadly both conan and vcpkg is missing dependabot. But it is a great question. How about if this proposal gets approved, we can add a task to implement it?

[wipfli]

Feel free to add the design proposal to the agenda for tomorrows mewting

[thehoneymad]

Also how is Mason or now conan related to the dependencies we have in the vendor folder with the submodules?

This is a great question. We currently use github sudmodules to pull nearly all dependencies. None of them are precompiled binaries. I will double check again.

But we are depedent on Mason who wires key dependencies for us such as Boost, RapidJSON and Mapbox dependencies.

My high level goal here is to limit the build process as much as possible to only building MapLibre Native and guarantee a confident build on nearly every commit.

Do you peeps see value in a document that explains how and from where our depdencies are wired?

[ntadej]

Also how is Mason or now conan related to the dependencies we have in the vendor folder with the submodules?

This is a great question. We currently use github sudmodules to pull nearly all dependencies. None of them are precompiled binaries. I will double check again.

But we are depedent on Mason who wires key dependencies for us such as Boost, RapidJSON and Mapbox dependencies.

My high level goal here is to limit the build process as much as possible to only building MapLibre Native and guarantee a confident build on nearly every commit.

Do you peeps see value in a document that explains how and from where our depdencies are wired?

I suspect Mason was used to bump the dependencies (or do similar automation), but we never actually call it.

I would propose this actually:

• remove Mason support
• evaluate used dependencies per platform
• then consider which package manager to use (if any)

I'm afraid that it will be hard to support desktop and mobile platforms with compatible pre-built binaries for all platforms.

We can discuss more tomorrow.

[thehoneymad]

What precompiled dependencies do we even have? Aren't all covered by submodules?

Great question.

Yes, all of them are currently covered by the git submodules. But the build process is a bit of a mudball. Unless one deeply knows how Mason wires the dependencies in the right order, we are in risk of:

1. Bad builds due to key dependency being added in wrong order. [Boost, RapidJSON]
2. Bad builds due to Mapbox removing packages from Github. [Mason, geojson-vt, earcut.cpp, protozero, polylabel etc]

Mason can provide static includes and binaries both. :)

[thehoneymad]

A great usage of Conan can be seen in open source routing engine Valhalla

[thehoneymad]

Also how is Mason or now conan related to the dependencies we have in the vendor folder with the submodules?

This is a great question. We currently use github sudmodules to pull nearly all dependencies. None of them are precompiled binaries. I will double check again.
But we are depedent on Mason who wires key dependencies for us such as Boost, RapidJSON and Mapbox dependencies.
My high level goal here is to limit the build process as much as possible to only building MapLibre Native and guarantee a confident build on nearly every commit.
Do you peeps see value in a document that explains how and from where our depdencies are wired?

I suspect Mason was used to bump the dependencies (or do similar automation), but we never actually call it.

I would propose this actually:

* remove Mason support

* evaluate used dependencies per platform

* then consider which package manager to use (if any)

I'm afraid that it will be hard to support desktop and mobile platforms with compatible pre-built binaries for all platforms.

We can discuss more tomorrow.

Another good call out. I checked out Conan recipes for that purpose. I am not sure it will do everything but we can have platform (arch) specific recipes for binaries or sources. :)

[thehoneymad]

This is not dead yet. I will come back to this promptly after my MapLibre whitepaper work.