PLATFORM lists

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

Right now we have LP64PLATFORMS, which is widely used for
NOT_FOR_PLATFORM/BROKEN_ON_PLATFORM. It is set at the bottom of
bsd.prefs.mk, where it doesn't really fit all that well.

In the course of going through all the NOT_FOR_PLATFORM settings to
distinguish NOT_FOR from BROKEN, I found a number of other cases where
a centrally maintained platform list would be helpful; that is,
multiple packages depending on an OS-level feature where each
currently maintains the list of OSes itself and the lists aren't
always consistent. The most common examples are various audio and
video APIs, but there are others, like inotify. There are also some
packages that depend on CPU features, e.g. vector instructions.

I think it perhaps makes sense to create central lists like
LP64PLATFORMS for use in NOT_FOR_PLATFORM/BROKEN_ON_PLATFORM, e.g.

   .include "../../mk/bsd.prefs.mk"
   NOT_FOR_PLATFORM+=	${INOTIFYPLATFORMS}

and put them in a single location, e.g. mk/platformlists.mk.

Although I wonder if it's maybe better to just create a mk/foo.bl3.mk
for each of these cases, e.g. mk/inotify.buildlink3.mk. For inotify it
probably is, as (at least in theory) it could pull in a compat library
on platforms that have something else comparable, and set
PKG_SKIP_REASON or PKG_FAIL_REASON otherwise.

But for miscellaneous multimedia APIs I'm not so sure. Many packages
probe and work with several alternative sound or video interfaces, but
others work with only some or support only one, and the expected
semantics of bl3 files is not really compatible with this.

Thoughts anyone? This came up on freenode the other day in connection
with inotify.

(Note that right now along with LP64PLATFORMS there are also platform
lists in bsd.prefs.mk for endianness; these should probably go away
again in favor of endian.mk... although it's not too clear as
endian.mk runs the compiler every time it's included and that's not so
nice.)

-- 
David A. Holland
dholland%netbsd.org@localhost