xpack for libraries

[duaneellissd]

Often, in addition to cross tools - many times a code library of some sort needs to be used.

Have you thought about creating something like xPack for code libraries? Examples include an SSL library, or one of the many Arduino, or MBED packages, or for example a BSP of some type.

What's missing in the embedded world is something like the linux "pkg-config" for embedded libraries - that could read from a package provided JSON files, or an "as built" JSON file of some sort..

What's nice about your xpack solution is the ability to have multiple versions "self contained" and is delivered as a package.

The idea of a "central repository" is sometimes very useful, but sometimes a project needs something customized - or tailored to a project.

Here's some ideas and requirements

1. For things like "freertos" there is 1 or more project specific configuration files the library needs to be built using - those configuration files may be LOCAL to the parent project, or LOCAL to the library.

The ability to say to a library package: "Build your self" - using these external configuration files (there may be more then 1 configuration file, and may be of any arbitrary type, ie: 'FOO.mk' - or FOO.h, or what ever.

that is in addition to: "build your self" using one of the built in pre-packaged configuration sets that COMES WITH the package.

2. a central repository is often helpful - but there are times when a project really needs a package defined locally and not part of the central repository.

For example, a library may have been customized for a project, and the project it self needs to provide the customized library as part of its "managed configuration" (aka: Project X, requires Package A - version 1 - slightly customized). But project Y, which came along later needs the same package but Version 2 - again slightly customized, but might use Package Y as is with no changes.

3. Every project has it's own way of customizing and tweaking things :-(

Sometimes the resulting configuration file is a MAKEFILE... a PROJECT file, or C or H files - it varies greatly.

One method that is very helpful and widely used is the Linux kernel "make config" solutions, some are GUI based, some are text based... or - more importantly, one can provide a text file which is the "old config"

There's also the very UNIX centric "autoconf" ... but that does not work for "mere mortals of this world"

Something like menu config is needed to customize packages, and being cross platform would be even more helpful.

Being able to as a package specify "Here's how to launch the configuration" or "this is the configuration method I use"

The result though - needs to usable in various IDEs (like Eclipse) and command line tools like standard Makefiles, etc.

[ilg-ul]

Have you thought about creating something like xPack for code libraries?

Definitely. Actually this was the initial use case for xPacks, as source code packages.

Have you seen the SiFive template project? (https://github.com/micro-os-plus/sifive-templates-xpack)

It is a bit old and outdated, but that's the beauty of xPacks, you can run it at any time and get the same result. The template generates a minimal source base, then xpm brings all dependencies, including the toolchain, and you can build the project.

Please try it, and comment about the experience.

What's nice about your xpack solution is the ability to have multiple versions "self contained" and is delivered as a package.

Thank you, yes, handling multiple (immutable) versions is key.

To be perfectly fair, I did not invent the concept, there are several years since npm did this very well for JavaScript modules, I just thought how to use it for C/C++ (actually any) source code files, plus binary tools.

1. For things like "freertos" there is 1 or more project specific configuration files the library needs to be built using - those configuration files may be LOCAL to the parent project, or LOCAL to the library.

Yes, project configuration is a whole different story.

By design, the xPack project identifies different issues and tries to handle them with specialised tools.

• xpm handles package dependencies and version management, and only this. same as npm for JS
• for project building there are several tools, xpbuild, xpmake, xpninja. They somehow cover the functionality of cmake, make, ninja
• for configuration it is planned to have xpcdl, which is inspired be eCos CDL, the most elaborate configuration mechanism I encountered.

The ability to say to a library package: "Build your self" - using these external configuration files (there may be more then 1 configuration file, and may be of any arbitrary type, ie: 'FOO.mk' - or FOO.h, or what ever.
that is in addition to: "build your self" using one of the built in pre-packaged configuration sets that COMES WITH the package.

I need to better understand these requirements.

a central repository is often helpful - but there are times when a project really needs a package defined locally and not part of the central repository.

Right, the central repository is for read-only code from others.

If different packages need changes, it is always possible to fork that packages and customise them.

Exactly like npm, xpm can also manage git projects, or local folders.

There are many details that can be discussed, but I'd prefer to keep this place for bug reports and specific enhancements.

For discussions I'd prefer to use the project forum, so, if you agree, please open separate topics there and we'll go into more details.