Re: [PATCH] libc/include/sys/tree.h: Re-add sys/tree.h

On 18/07/2024 16:13, Corinna Vinschen wrote:
> On Jul 17 11:15, Gedare Bloom wrote:
>> On Wed, Jul 17, 2024 at 11:14 AM Sebastian Huber
>> <[email protected]> wrote:
>>> Again, I would simply remove <sys/tree.h> from libbsd, monitor the FreeBSD changes, and after evaluation update the Newlib version if there are benefits.
>>>
>> I'm not opposed to this route, but, we now wind up in the same problem
>> in newlib: cygwin would like to update tree.h, but rtems would like to
>> keep the rbtree version.
> 
> Cygwin does not use sys/tree.h internally.  We don't have any specific
> need for a specific internal implementation of the API.  Therefore, we
> don't really care which impementation is used.
> 
> The concern here is to remove a header which has potentially been used
> by a Cygwin package, and as I mentioned in my reply to Joel, there *are*
> packages out there using this file, for instance tmux.  While tmux still
> works if sys/tree.h is suddenly gone, I have no idea if it still works
> as before, or if you get user-visible changes due to that.  That's what
> I'd like to avoid.
> 
> Yes, it might or might not have been a questionable decision to put
> sys/tree.h into newlib, but now it's there and removing it could have
> unwelcome side-effects outside RTEMS, that's all I'm saying.
> 
> So, let's update it and live with it and next time such a file is
> supposed to be added, let's be a bit more thorough in discussing its
> need.
> 
> In terms of updating the file, I completely trust Sebastian to do the
> right thing.
> 
> 
> Thanks,
> Corinna
> 

The usual way to deal with things like this is to follow a deprecation process.

first put #warning in the file so that it complains if users try to use it.
Then upgrade to #error, but allow something like -D__PERMIT_DEPRECATED_TREE_H to suppress this.
Finally remove the file, or move it somewhere well out of the way, like sys/obsolete/tree.h

R.