[FR/IDEA] splitted framework

[farfromrefug]

I thought that i should be possible to split the carto SDK into multiple packages and publish those packages independently. This would not break the current behavior as you could still publish a full one but it could make things a lot easier/small/faster for most of your users. We could imagine:

• Carto Core ( maybe with raster and http data source)
• Carto Carto (with online carto). This one requires the registration
• Packages
• Routing
• Geocoding
• Valhalla

It might requires a little bit of work but it seems totally faisible:

• refactor header includes ( cant be relative anymore)
• cmake structure.

I know it might not be in your roadmap. But if you are ok with the idea i could work on it.

[vTechGIS]

This is really a good idea,

[mtehver]

At the high level this is something we have thought about and the idea looks quite attractive. The advantages with this approach:

1) Cleaner modularization, 2) Smaller APKs/DLLs if using only a subset of the SDK functionality

Note that the second advantage only applies to platforms using dynamic libraries (Android, UWP) and is actually a disadvantage (larger binaries) if most of the SDK functionality is being used (due to duplicated C++ STL code, etc).

In general this is something we would like to do for "SDK 5.0" with bunch of other things:

1) Refactor and reorganize the SDK structure. 2) Migrate to dynamic libraries on all platforms 3) Remove obsolete features from the SDK

Unfortunately that would break backward compatibility, which is something we can not do for 4.x versions.

[farfromrefug]

@mtehver we are on the same page. Except i dont get why you say "duplicated C++ STL code". I mean using shared so should prevent that? For example the routing so lib would depend on the "core" so lib? So all "shared" C++ code/ symbols would be in the "core" so lib. That s what is done with STL on android (when built to use it) i think.

[mtehver]

@farfromrefug Regarding duplicated C++ STL code. Currently SDK is built using static STL library. This means that everything that is used from STL is instantiated and embedded into the compiled SDK .so binary. If split into multiple .so files, then a lot of this code needs to be embedded into multiple SDK .so files (like std::string, std::regex, std::vector<...>, etc).

Another option would be to use 'libc++_shared.so' library (shared STL library). Then there would be little duplicate STL code in the SDK binaries, but 'libc++_shared.so' is itself quite big. I think it is over 6MB for ARM64 currently.

[farfromrefug]

@mtehver indeed it is quite big. But it is still better because if another library uses it they can use the same. Plus not certain but I think you can use a system provided one ( I think it is what we do in Nativescript)