Re: toolchain/48675: evbarm userland fails to build in current with sources checked out March 21, 2014

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

The following reply was made to PR toolchain/48675; it has been noted by GNATS.

From: "David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: toolchain/48675: evbarm userland fails to build in current with 
sources checked out March 21, 2014
Date: Wed, 9 Apr 2014 01:22:21 -0400

 In summary, this PR can be closed; consider it user error. (Though,
 I do have a question about documentation below.)
 
 I should add, I tried build.sh with -m macppc and -m evbarm options,
 in case that made a difference in terms of how it cleaned directories.
 With -m macppc, there was no difference, but with -m evbarm, various
 files were cleaned out of the obj directory, including the file with
 Power PC assembly in it that was causing the problem. After that point,
 there are still remaining Power PC object files in the directory, some
 dependency files, a header file, and an i386 executable (the underlying
 build architecture).
 
 I'd seen in the UPDATING document there were the following entries:
 
 20131129:
        The GMP sources were updated, and builds will likely fail without
        cleaning their build trees for both tools and in-tree, like below.
 
 20131128:
        The MPC and MPFR sources were updated, and builds may require
        their tools and in-tree directories cleaned for successful updates.
        
 But to me "cleaning" implied it could be done automatically with the
 build scripts.
 
 I'm assuming what happened was after the GMP library was updated, files
 created for an old version were no longer relevant, so they were by
 definition missing from lists of what should be cleaned. This makes
 perfect sense and I can't really expect this could be dealt with
 automatically.
 
 I would say though that this and the other PR I opened pose a question
 concerning the assumptions made in the supplied documentation (unless I
 missed something, which is entirely possible) in terms of what level of
 expertise/familiarity is being catered to, i.e. is it worth mentioning
 things that may be self-evident to many but not the inexperienced?
 
 In any case, I'll try to be more careful about opening PRs like this in
 future... Sorry for the noise.
 
 Dave