unless they change, and we want to rebuild based upon what inputs are
present, not when they were last touched.
this fixes update builds that switch options that change the dirlist
like MKX11 or MKCOMPAT, restoring a portion of rev 1.14.
note that some opertions like turning off MKX11=yes will also require
a fresh DESTDIR, in addition to this fix. there may be more issues
remaining, but i am now able to enable MKX11=yes successfully without
any other change.
This way, there is no file name issue with radeon(4) from
the old not-kms driver; and subdir man pages are preferred
to non-subdir.
Addresses MKREPRO issue from PR 50132.
XXX: This will stop being correct if radeon-kms is ported to more
platforms like sparc64.
and a lot of other goodies.
You can use and manage up to 32 virtual screens called workspaces.
You swap from one workspace to another by clicking on a button in an
optional panel of buttons (the workspace manager) or by invoking a function.
You can custom each workspace by choosing different colors, names
and pixmaps for the buttons and background root windows.
Main features are:
- Optional 3D window titles and border (ala Motif).
- Shaped, colored icons.
- Multiple icons for clients based on the icon name.
- Windows can belong to several workspaces.
- A map of your workspaces to move quickly windows between
different workspaces.
- Animations: icons, root backgrounds and buttons can be animated.
- Pinnable and sticky menus.
- etc...
See http://web.zephyrite.net/NetBSD/wm/index.html
ok mrg.
the support in the rest of the source tree.
X11 sets could use some cleaning up perhaps (just deletion, as
we've never really marked the old X11R6 as obsolete for native
xorg using platforms so far either.)
and the information from compat/archdirs.mk. Also add suport MKCOMPATTESTS
and process the NetBSD.dist.tests to generate appropriate compat directories.
- only install it by default on x86, set new MKRADEONFIRMWARE variable
- install in /libdata, so that separate /usr systems work
(this still doesn't solve PR#49811, which possibly could be handled by
having them being a kernel module loaded by /boot.)
ozaki-r