Comments on pkgsrc and DragonFly

[Francois Tigeot]

On Fri, Jan 07, 2011 at 03:03:58PM -0500, Stephane Russell wrote:
> While porting programs to DragonFly, I had these issues (which are not
> bugs):
> 
> - "BSD" is undefined in DragonFly, this isn't working:
> #if (defined(BSD) && BSD >= 199306)

Never saw this one.
All tests I encountered in third-party software were looking for full OS
names or OS-specific defines like "__FreeBSD__" or "irix"

> - In many autoconf scripts, BSD variants are grouped this way:
> 
> case ${OSARCH} in
> *BSD)
> 
> case "$uname" in
> *BSD*)
>
> both are excluding DragonFly, since uname -s return "DragonFly" and

These are a pain, but I don't think they are so pervasive; Darwin is
also considered as a BSD system and has the same problem here.
In all cases I've seen, it was fixed with a new test checking for the
full OS name:

    case ${OSARCH} in
    *BSD)
        blah
  + Darwin)
  +     blah

> But it does mean that choosing FreeBSD as build type won't
> necessarly mean no changes required on the autotool scripts.
> 
> - Some programs are compiling successfully by defining FreeBSD as build
> type. Is DragonFly kept close as possible to FreeBSD on purpose or
> should we expect this to be a vanishing legacy?

This is a vanishing legacy.
I had to distinguish between FreeBSD and DragonFly when porting the jdk
In some cases, FreeBSD oriented code was failing and I had to use the
same #define directives as NetBSD or Linux.

Kde4 packages are also troublesome; if I remember correctly, they consider
DragonFly as FreeBSD and fail at some stage during the compilation.

> Official positions here will me help me knowing what to expect while
> porting.

When it's on a small scale, one-liner patches fit the bill and they can
be safely sent upstream:

  - #ifdef __FreeBSD__
  + #if defined(__FreeBSD__) || defined(__DragonFly__) 

In other cases, adding an abstraction function such as isLinuxOrBSD may
help replace a bunch of #defines.

Sometimes, the original code is really weird/non-portable and can be
safely replaced by an equivalent construct which works equally well on
all known operating systems.

This is no official position, simply my experience so far.

-- 
Francois Tigeot