Millsa Erlas wrote: >Does DragonflyBSD plan on keeping the ability to run application code >on FreeBSD to be compiled on DragonflyBSD? > >I suspect that it would be a good idea, even though an improved >package system may be adopted, to perhaps maintain the capability to >use FreeBSD ports as well on DragonflyBSD. Also, I think it may be a >good idea for DragonflyBSD to maintain the capability to compile >application source code written for FreeBSD as well, so applications >ported to FreeBSD run also on DragonflyBSD. This is so that the large >amount of programs ported to FreeBSD can also run on DragonflyBSD >without having to be re-ported to DragonflyBSD. > > The problem is more that their "what can my host OS do?" checks are limited to using uname and developing a profile. Also, auto* tools suck. Everybody here knows this.
So while DragonFly BSD has retained almost bug-for-bug compatibility with FreeBSD, a lot of compilation procedures just don't know that functionality is there. Although autoconf is MEANT to resolve this by checking for functionality individually, it relies on the developer knowing what to check for, and they stupidly defeat the whole purpose of autoconf by making it hinge on uname. Patching these scripts is difficult since they try to regenerate themselves to prevent maintenance. For instance, devel/apr (pkgsrc) does not know how to use DFly's sendfile, despite being directly inherited from FreeBSD. It thinks it's there during configure stage, then freaks out during compile stage. You have to manually modify the header and continue the compilation. For many users, this is unbearable, and in no case should it be tolerated. This is an easy example. Try to get a Mozilla-based product to compile. My suggestion? Give up and become a Zen monk, it'll help you deal with GNUisms. Eventually they'll catch up and realise DragonFly is a more than viable platform. At the moment, FreeBSD ports (with overrides) and pkgsrc have their own capabilities for working with DFly, but neither system manages to fix all of the brokenness out there. If more systems had bsd...mk-like compilation instead of GNU automation tools (autoconf, libtool, etc.), there would be no such problems. Systems would define their capabilities in their build environment and all compilation profiles - libraries, individual programs, heirarchies, kernel modules, etc. - would be there already, not requiring reinventing the wheel incompatibly for every package. GNU: GNU's Not Usable
