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

[Amar Takhar (@amar)]

Amar Takhar commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/640#note_128152


**FYI if any headers weren't installed in the same place that's a bug there should be no user-facing changes at all.**

The change I was making -- and wasn't finished yet is to:

* Isolate 3rd party builds to individual libraries (not done yet but some are already built this way)
* Create a 3rd library that builds rtems source that uses the 3rd patty library with the right includes

Note: This is waf no libraries are created they can stay as `.o` objects this just handles build flags.

This avoids having a flat "namespace' for includes.  Chris made the argument that on operating systems these go into a general `include/` directory but this is about building the operating system _not_ what happens when it's "installed" and in use by a user writing their application.  OSes themselves are built in isolation -- yes I know Linux does not do this or kind of goes in a roundabout way to attempt it but most headers are installed in `/usr/include/` .. I don't use Linux so this argument falls flat on me there are reasons I don't use it this is actually one of them.  CI builds are done in a chroot environment on Linux to avoid this it's annoying but necessary.

The future is to use those built objects and link in the 3rd party test suites for testing.  Most of them have their own test suites that should at least in part run under RTEMS so we can ensure the upstream tests work to verify that everything is OK.  We currently do not do this and if we do it's not across the board.

There's no reason for every C source file built to have access to every header when building RTEMS.  Doing it this way makes it more deliberate and lets us know which files are using which 3rd party APIs and frankly we should be doing this internally, too.

This is not a huge change as far as development goes.  If you need access to a header that's not generally available it's a one or two line change in the build that to me is not a big deal for the clean builds we can ensure in the future.  I do understand there may not be buy in for this and there will be a lot of "what's the point" but what's wrong with ensuring that unused APIs aren't exposed when they are not being used?  Especially for 3rd party code and that's all I'm attempting here at the moment.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/640#note_128152
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/ed700316/attachment.htm>