[OpenAFS-devel] FreeBSD 4.8-stable compile failure

[Derek Atkins]

Jim Rees <rees@umich.edu> writes:

> This one is a bit harder.  I've been working sporadically on FreeBSD 5.0 for
> a while.
> 
> First, I wish the FreeBSD sysnames didn't have that second underscore.  I
> suppose it's too late to change this.
> 
> Second, why do the fbsd param.h files #define all previous ENVs?  For
> example:

Linux does this too.  Generally it's useful because things change
going forwards but not backwards.  For example, something will be
introduced in linux-2.2 that didn't exist in 2.0, but still remains in
2.4.  So instead of having to say AFS_LINUX22_ENV and AFS_LINUX24_ENV
and everything else going forward, we can just say AFS_LINUX22_ENV...
If some future version changes that particular behavior, then we can
change it to:

#if defined(AFS_LINUX22_ENV) && !defined(AFS_LINUX44_ENV) and now
we've got a range :)

> % grep AFS_FBSD param.i386_fbsd_47.h
> #define AFS_FBSD_ENV 1
> #define AFS_FBSD40_ENV 1
> #define AFS_FBSD42_ENV 1
> #define AFS_FBSD43_ENV 1
> #define AFS_FBSD44_ENV 1
> #define AFS_FBSD45_ENV 1
> #define AFS_FBSD46_ENV 1
> #define AFS_FBSD47_ENV 1
> 
> I am going to try removing the AFS_FBSD40_ENV from param.i386_fbsd_50.h so
> I'll have some easy way of distinguishing between 4.x and 5.x.

I don't know how different FreeBSD 4.x is from FreeBSD 5.x, but you're
welcome to try.  However, from previous experience the ability to have
a range option is useful.  OTOH, if 5.x is so siginificantly different
from 4.x that it's a completely new port, then sure, you can just start
over with AFS_FBSD50_ENV and leave out all the 4x_ENV values.  But then
you'll have to go through all the code and add the 50 checks to all the
required defines.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available