https://wiki.allseenalliance.org/core/packaging_proposal_v1
Alljoyn framework is a set of projects where each one follows it's own release cadence. There are major versions of the Core functionality, and the rest of the projects release on their own convenience for those versions afterwards.
This proposal aims to ease the involment of both the comunity and non-leader companies within the development and the release process.
The workflow established in all projects mainly involve a main company carrying the development, and a series of contributors and interested companies on the process. Apart from the development process, one of the most important steps is the testing cadence and the release.
The testing is usually done by the leading company, and sometimes the documentation on how the format of the source code of the release will be is scarce. Also, as workgroups are independent from each other, the release tarball layout is usually really different. In the worst cases, tarballs include code that is not part of the workgroup's repositories, but added on when the release is created.
There are some usual defects on the release process that this proposal is aiming to address:
- External builds scripts are usually referenced, in worst cases as mandatory dependencies - External projects are built, sometimes using those objects within the compilation of the targeted project - Linking to dynamic libraries is not an option if unavailable for compilation - Non standard layout is followed
Although these defects sometimes arise for manual compilation, because the reference layout of the git repos is sometimes not met, or the version of each dependency is not the one exected, the real problem is when you try to automatize the compilation of Alljoyn. Specifically, this proposal has been written around all the difficulties that arise when packaging for Linux desktop systems and Openwrt.
When other projects are packaged, the contents of the release tarball and the contents of the release tagged in the source version control tree should be *exactly the same*. This is really important because it allows to generate release packages from the source tree in a programatic and standard way (using git archive for example). This has a series of implications on the git repository:
1. All the build scripts the project *mandatorily* relies on must be within the git source. In most of the cases, this would mean copying the referenced build scripts to the project tree. 2. External build scripts that are *optional* should be optionally compiled using some flag to enable their compilation. 3. External objects to the tree should not be used within the compilation. In scons this means that a new env should be created for/from them, without adding them to the project environment. 4. External distribution directories should not be referenced. Instead use some generic argument to extend the linking path, the include path or whatever. 5. If a referenced library is a dependency, it should be linked if not available for compilation
As you may observe, the first step is to make modular the projects. This will allow a packager to create packages of the alljoyn framework separatelly, and without possible ABI issues.
Once the projects are independent from each other, in order to make it easier for the packager (and the rest of the users) to compile the software, the projects should have the same input and output. This means that the same commandline should do the same in all projects with this step implemented.
This goal is more complete than the other one before because projects do usually use core/alljoyn/build_core, making the core build/ folder's layout the defacto standard within the alliance. Standardizing it would be highly recommended, and this proposal wants to propose the following structure: