On Tuesday, 3 June 2025 20.09.21 Central European Summer Time [email protected] wrote: > We don't plan to drop APE without finding a way to migrate the things > people actually use, either by providing better options (eg, npe for > porting code that doesn't need select()) or by writing native options > that remove the need for ape utilities (like patch(1)).
What inspired me to start with APExp (I should get started again after several months of pause due to busy work etc) was the prospect/hope that the base system might drop it. In a way, this could be a good thing because it also means that APE can be expanded and get bigger and messier with the explicit goal of compiling "any" POSIX-compliant software (not just the software used in the base system), and potential licensing or other NIH bikeshedding is less of an issue (it is after all voluntary to use it). The way I see APExp is something akin to Msys2 on Windows. (I still need to test/make sure that APExp also works on 9legacy etc) > > The objection to APE isn't having a compatibility layer, but that APE > has a great deal of duplicated system functionality, and is therefore > a pain in the butt to maintain. Indeed. I am super excited about the possibility of npe potentially replacing APE in the base system and reducing the duplications in it. > ------------------------------------------ > 9fans: 9fans > Permalink: > https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M04ec7e680b00061bdf6ff409 > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M03e8c1f94daa1f6d2f8e02ee Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
