Source builder kinks
chrisj at rtems.org
Sun Dec 14 22:03:53 UTC 2014
On 13/12/2014 5:44 am, Steve B wrote:
> I can give that a shot some time soonish and let you know.
> Since zlib is a compression/decompression library I would like to guess
> that it's not super critical for rtems build environment, but taking
> away that dependency still doesn't solve the ncurses5-dev or python
> headers ones, so I'd rather think of a good way to check for those in
> the sb-check. Or if we can figure out how to ensure that hash checking
> thing actually works so the builder doesn't start from the beginning
> each time; then just having to install those packages and pick up where
> the builder last left off would have been much less of an inconvenience!
I understand what you are saying and logically it makes sense however
the RSB is cross-platform so the support needs to be consistent across
all supported platforms.
On FreeBSD it is easy (one flavour), on Linux support needs to cover the
wide range of packaging systems, and on Windows and MacOS there is no
concept of packages.
What the RSB can build is growing so if we add a package with a weird
and large package mix should the RSB not build anything until you
install all packages possibly needed ? No, so the dependences need to be
RSB package specific.
A way to understand the complexities is to examine requirements such a
change would need meet:
1. Common package description for the internal package naming. This
would be the FreeBSD port naming scheme. This scheme is currently used
for the packages names. How this is maps out may prove difficult if
packages are managed differently. How would versions be managed ?
2. The framework to support this needs to provides an easy way to add a
specific packaging system's support. The specific support needs to
manage all version and naming translations.
3. Interactions with the current pkgconfig support would need to be made
to work smoothly. See the bare/qemu support for examples of this.
4. Each RSB package needs to defines its specific list of packages. This
means the set builder needs to parse and learn this list and check it
before starting building the first package. What happens with clashing
version numbers between packages ? How do you manage dependences between
packages being built ?
5. If a host is not supported the current method is the fall back.
As you can see this is not an easy thing to do and you need to avoid
writing yet another packaging system. This is the reason for me
basically ignoring it and asking users to self manage and provide
documentation patches to help make it simpler. I am still not completely
comfortable with heading down this path as defining packages starts to
link the state of the RSB with the state of various packaging systems
and I feel this is outside the scope of the RTEMS project.
More information about the users