Re: Preparation for creating netbsd-7 branch

["David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>]

Hi all,

To give a user's perspective, I'd like to comment on a couple of
items in the thread so far.

Christos Zoulas wrote:
>Yes, I've been trying to follow that thread. Can you please summarize
>the problem and propose a solution? Is it a backwards compatibility
>issue? Or do we need to worry about binaries produced with sf on hf
>able machines in the future? Why would one do that? To be compatible
>with old machines?

Someone like myself could need to move from the old "evbarm" to
something else, e.g. on a Raspberry Pi, from "evbarm" to
"evbearmv6hf-el", which means they're going from soft float to hard
float, and from OABI to EABI. The method to do so isn't documented
anywhere (to my knowledge). There are also users trying to run
current pkgsrc builds for evbarm on other variants.[1] (That could of
course disappear if pkgsrc builds changed to match the new defaults.)

I'd seen correspondence on port-arm about compatibility being offered
via COMPAT_NETBSD32, though it was unclear what the extent of that
is.[2] I think I'd misunderstood things, as I'd tried to help another
user and it wasn't working as I'd thought. I'd opened a PR[3] seeking
to improve the COMPAT_NETBSD32 man page, with the intent of
documenting just what it does for ARM, but I hadn't yet approached
any of the developers for help with the explanation.

Nick Hudson wrote:
>Something (build.sh/wiki/both) can document each evbarm board to the
>correct MACHINE_ARCH variant based could then be provided.
>
>build.sh already contains useful information here

From what I can see, traditionally the BUILDING document covers this
information. (Well, not matching boards to aliases, but listing the
various aliases.) However, it is rather out of date compared to
build.sh, and not just for ARM ports. (As I think everyone here is
already aware.) I'd submitted a PR[4] to try and bring the existing
extent of the documentation up to date (as well as provide a few
unrelated amendments).

To avoid the overhead of maintaining documentation separately, the
existing information in BUILDING could be removed and an option and
function could be added to the build.sh script that would output the
table, with users being directed there from BUILDING. (Or something
else, but the existing documentation is inadequate for a number of
ports.)

I understand that writing documentation can often lag development
efforts, but it would be unfortunate if users can't appreciate all
the work developers have put in. (Well, I realize no one's doing
this for fame, but...)

References:

1. http://mail-index.netbsd.org/current-users/2014/07/17/msg025274.html
2. http://mail-index.netbsd.org/port-arm/2014/04/07/msg002350.html
3. http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48968
4. http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48741

Regards,

Dave