This page distills the requirements that have been suggested as part of PROTON-194 and the related Proton mailing list discussion.

Requirements

The following requirements are listed in no particular order.

Unless otherwise specified, "proton-c" currently means the the C implementation itself, plus all the language bindings. "proton" includes proton-c, proton-j, and the system tests.

Requirement

Stakeholder

When a user has downloaded the tarball source release of proton, they can build it and run all the system tests without requiring non-standard tools*.

QA tester or End User

A checkout of proton can be built without requiring non-standard tools*.

Developer

A checkout of proton can be tested without requiring non-standard tools*

Developer

The build system will be capable of running in "offline" mode, i.e. without Internet access. For example, it will not have to fetch dependencies from a remote Maven repository, although this may be enabled as a convenience.

Developer, Release Manager, End User

As with all build systems, the other requirements should be met whilst maximising simplicity and minimising duplication. For example, it would be good if the aforementioned proton tarball release could be produced by performing a simple "svn export" of a proton checkout.

Developer, Release Manager

Non-standard tools

*non-standard tools means libraries and build tools that are not easily available on a supported platform.

For example, Maven is considered non-standard because the package managers of RHEL and Fedora do not offer a sufficiently recent version. In contrast, make and cmake are standard tools on our supported platforms.

Note that it is acceptable to require a given non-standard tool to perform an operation that is intrinsically related to it. For example, it is acceptable for the build system to require Maven to be installed in order to publish the artefacts to a Maven repository. It is also acceptable for the build system to allow the use of Maven as an optional convenience to the developer.

  • No labels

3 Comments

  1. Gordon Sim

    Is 7 not a restatement of 5 (without the JNI qualification)? Does that mean that even the JNI bindings should be buildable without requiring 'non-standard' tools?

    In my view 'non-standard tools' are toolchains not usual to a particular language (.e.g requiring a java compiler if just interested in c, requiring a c compiler if just interested in java). I think the build should be smart enough to adapt the components that can be built based on the tools available (e.g. only got c compiler? -> you only build the c library. Got swig and perl dev tools? you can build perl binding etc etc)

    Testing is an interesting area. Having tests that can run against both implementations is a good thing certainly. That likely means some tests are written in a language not everyone prefers. I do think that python is a good option there, as something not as alien to either c or java as java or c respectively!

  2. Gordon Sim

    My prioritised list would be:

    (1) no 'foreign' toolchain should be imposed on developers that do not need it (vital for end users, just nice to have for those contributing to proton itself)
    (2) no duplicate copies of the same files in svn

    1. Rob Godfrey

      I agree with Gordon's top two priorities... I consider both of these to be essential requirements.

      (3) for me would be two have the source structure / build scripts we release to be identical to that within subversion.

      Having the source / build scripts differ between how the developers use it and how the end users experience it would seem to be to be a great way to ensure that we introduce bugs into our user experience.

      One thing that is absolutely not a priority to me is to make sub-directories of proton to be completely isolated from each other. If a developer wishes to change the proton engine API (s)he needs to be aware of the effects on all the language implementations not just their favoured language.