Source builder kinks

[Chris Johns]

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.

Chris