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
