search

atsushieno / ndkports

private fork of ndkports for my own packages, see https://android.googlesource.com/platform/tools/ndkports/
1 stars 0 forks source link

[meta][upstream] there are so many design issues #1

Open atsushieno opened 4 years ago

atsushieno commented 4 years ago

If NdkPorts seriously aims to become a standard package provider which targets not only Android, there are many, many, many issues to resolve.

(1) The entire package ecosystem must not be one single tree but should rather be more like "hedges" - there will be more than one packages for a source project, and they have to be "fork-able". What ndkports does right now is that everything is packaged as com.android.ndk.thirdparty.* which means there is no options. The package name is not customizible.

(2) The sources are checked in directly in the repo, which is nonsense. Even CDep was doing better. Sources must be cloned or downloaded, then patched, and then built.

(3) There is no option to specify platform-specific configurations. That is most likely why the existing MesonPort (in the original source tree) fails to build glib, even if we have libffi and libiconv ported.

(4) There is no way to specify PLATFORM_API_LEVEL.

(5) Traditional sources with autotools don't always expect that build intermediates can be stored somewhere outside the source tree. They can be saved within the source tree. Therefore sources must be cloned per ABI.

GStreamer Cerbero build system does all of those except for (1), whereas NdkPorts does none of them.

Although Cerbero declares that it aims to build ONLY GStreamer related projects i.e. not for general purpose.

atsushieno commented 4 years ago

There should be package dependency resolution path that resolves to other prefab packages but there is no such thing in the current NdkPorts, because of (1) above(!)