Bob McGowan <ramjr0915%gmail.com@localhost> writes: > OK. The question as to if I had done a 'make clean clean-depends' is > answered with 'yes'. However, note that this whole experience started > with trying to do cross-compiles on my Linux x86_64 system. Once I > got qemu working and NetBSD installed, rather than download all the > files again, I copied them from the Linux system to NetBSD, which > forced the make clean; make clean-depends. > > Given that the potential for cross contamination may still be there I > will clean up by deleting and downloading a complete new set of files. You can, but really the important thing is to rm -rf */*/work, and then do an update and make sure nothing is modified. Redoing it amounts to the same thing and has less opportunity for error. > As for the discussion of variables, and which should or should not be > changed by the user, I was mis-interppreting the following: > > ========================================================================== > The following variables will affect the build process of this package, > gnome-doc-utils-0.20.10nb7. Their current value is shown below: > > * PYTHON_VERSION_DEFAULT = 38 > > Based on these variables, the following variables have been set: > > * PYPACKAGE = python27 > > You may want to abort the process now with CTRL-C and change their > value > before continuing. Be sure to run `/usr/bin/make clean' after > the changes. > ========================================================================== > > The last sentence says "...change _their_ value...". But looking > closer and at other cases of similar messages, where multiple > variables are mentioned, so I suspect the plural refers to the > variables in the upper section of the message only. This text is misleading. What's going on is that there are variables set from various places (user, package, infrastructure) and via logic that is sometimes complicated lead to variables that control things. The text should probably make clear that only the first group of variables is user-settable, and the second group should not be set explicitly. Don't feel bad for making mistake here - this is very complicated and the message you read was misleading. I have just edited mk/misc/show.mk to refrain from suggesting that variables in the second group be set.
Attachment:
signature.asc
Description: PGP signature