RTEMS | spec/build/*.yml: Add contrib/.../uuid and contrib/.../utf8proc (!640)

[Joel Sherrill (@joel)]

Joel Sherrill commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/640#note_128151


uuid.h is included from these files:

```
$ grep -rl uuid.h bsps cpukit
bsps/include/acpi/acpica/actbl2.h
bsps/include/acpi/acpica/acuuid.h
cpukit/include/rtems/bdpart.h
```

And bdpart.h is pretty fair game. The file bsps/powerpc/mpc55xxevb/start/sd-card-init.c includes bdpart.h so has an implied dependency on uuid. It also means that an application using this BSP has a tertiary dependency on uuid if they use this BSP and driver.

The uuid capability was an included part of the public RTEMS interface. It still is for applications but this forces users to change their library dependencies in a way that will be incompatible for >7 versus <7. 

And because RTEMS code used these capabilities in places, some BSPs and RTEMS capabilities will end up with users having to change their library dependencies.

These libraries did not even exist before this change. Everything was in librtemscpu.a which is implicitly part of the linking step. 

Did everyone buy off on a user facing breaking change?

How will a user know what libraries a BSP depends on?

I'm not opposed to moving things into contrib/ when they are relatively clean imports of third party code. We just went to great trouble to reduce the number of places a header file could be stored in the source tree before we switched to way. Now the file _spec/build/cpukit/optincludes.yml_ has this list of include directories

`cpukit/include cpukit/score/cpu/${ARCH}/include contrib/cpukit/fastlz/ contrib/cpukit/zlib/ contrib/cpukit/xz-embedded/userspace/`

The first two were already needed. The contrib additions are new and yaml files for other places in the tree got other includes added. Since everything links, I assume they also got libraries or direct reference to contrib files added.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/640#note_128151
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250802/97b3e46b/attachment.htm>