Compatability with FreeBSD Ports

[Dmitri Nikulin]

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