On 1/12/20 5:31 pm, Sebastian Huber wrote: > On 30/11/2020 21:43, Joel Sherrill wrote: >> On Mon, Nov 30, 2020 at 1:06 PM Sebastian Huber >> <sebastian.hu...@embedded-brains.de >> <mailto:sebastian.hu...@embedded-brains.de>> wrote: >> On 30/11/2020 20:00, Joel Sherrill wrote: >> > Applications can use something like: >> > >> > #if __RTEMS_MAJOR__ >= 5 >> > >> > POSIX threads are always enabled ... >> > >> > #endif >> > >> > This is a change to our public API that was completely unnecessary. >> > >> > We do not require changes to application code when it can be >> avoided. >> If you enable the POSIX API, then you don't have to change >> anything in >> your application. You can use now more of the POSIX API without >> having >> to enable it explicitly. It is up to you if you want to rely on >> this or not. >> >> >> What about rtems-libbsd? It fails to build because of this flag having >> changed >> meaning. >> >> I think we broke a contract on what the meaning of a published >> feature macro means. > > Sorry, I still don't understand the problem. You always had to build libbsd > with > a BSP which was configured with --enable-posix. > > Since now more POSIX APIs are enabled by default, we may remove this check > from > libbsd. However, this requires someone with enough time to implement and test > this.
The semantics of what is being offered by the option has changed. Yes adding the option does make things build but it is now inconsistent in what it covers and how it is being detected and used. Papering over this only delays the point in time we need to address it Can the enable-posix option be removed and always enabled? We minimise the executable size automatically. Always being enabled means the option in the header is always true and any dependent package or build system can happily continue and be updated when it suites. Failing that can the default always be true? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
