Creating a Deployable SDK style MW:COM Package

[btirunagaru]

We would like to deploy MW:COM as a (shared object & headers ) prebuilt package ( in a SDK style) in our platforms preferably single dynamic library.

Meaning an .so & public headers ( cross compiled for our platform ). App developers will be using .so and headers/data files that are required to build their applications ( instead of using a Bazel SRC projects ).

As a part of that – we seem to encounter specific problems and looking for recommendation on how to resolve this.
(or) does the contributors here can suggest on what next steps.

Issues Identified in our study

• Public headers seem to include a lot of transitive dependent libraries public headers & in some cases private headers too. Don't seem to find a clear marking/export definition of public headers that are absolutely needed for app developers ( instead of hdr tag for a lot of cc_library projects)
• The dependency runs deep into Baselibs and directory structure seems to complex enough for us.
• Bazel skips a lot symbols from inclusion - when compiled as shared libraries for the transitive deps at the COM API level ( forces us to add deps in the top level directories).

Next Steps:

Is there any improvement/work item that targets to include BUILD file that lets the users of the project to create a shared object & header package creation. (By resolving the dependency chain & adding necessary exports to truly public headers for app developers talking to MW:COM API).

[FScholPer]

I like the idea. We are currently working on a S-CORE CLI(https://github.com/mercedes-benz/score_scrample/tree/feature/scorex). That could be something we can integrate there.

[opajonk]

IMHO such kind of CLI tools are really a game changer for the UX in the (highly important) first hour of someone new experiencing a project. If in addition, some repetitive work can be automated even during regular development - cool. But that is a later step.

One could even create e.g. a VSCode extension which uses this tool. The extension would be only cheap glue code, no business logic. That remains in the CLI tool and will continue to work for everyone, even people who do not use VSCode.

[olivembo]

@btirunagaru I guess the problem is that you do not know the build system of the customer. If you only provide .so and header files, the customer will need to manually configure their build system to locate these files, set up the correct include paths, and link against the shared libraries. This can be a tedious and error-prone process, especially there can be complex dependencies or specific compiler flags are required. You'll want to provide a very good documentation and/or potentially even helper scripts/configuration files that make this integration as smooth as possible for various common build systems.

[btirunagaru]

I feel it differently, we provide a platform and middleware offering to customers( building application framework and write applications). So we do know the build system and configuration for the platform and middleware composition.
Hence having a deployable script in the project make sense for such UCs.

Also the application linking this heavy framework statically is overkill especially; its more ideal they link dynamically and keep their applications lighter.

Yes i definitely agree the documentation on how to use the SDK and develop application is the key and this is something thats part of our platform offering and providing necessary tooling to build applications as well.