-current broken when src is on NFS

David Wolfskill david at catwhisker.org
Sun Jul 19 19:02:19 UTC 2015


On Sun, Jul 19, 2015 at 10:31:36AM -0600, Ian Lepore wrote:
> ....
> I've been following this saga (on irc and here) as much as I have time
> for, and I can't escape the feeling that it is the directory structure
> at fault somehow, but I can't quite put my finger on it.
> 
> I never (ever) build from /usr/src or use /usr/obj as an object dir
> (they're both empty dirs on all my machines).  But one thing that is
> always true for me is that the source dir and its related object dir are
> siblings in the same parent dir.  That is, it's always
>  
>    /any/path/here
>       obj/
>       src/

Well, as counterpoint....  The systems where I do FreeBSD builds are
usually set up (and have been since about 1999) so that:

* The sources reside in /usr/src.

* The file system layput is such that:
  + /usr is on a different file system from /, but these reside in
    partitions 4 and 1 (respectively) of the same slice.
  + /var is a file system that resides on a partition on slice 4.
  + swap is on slice 4, partition 2.
  + /tmp is a swap-backed tmpfs.  (Well, the implementation of that has
    changed over the years -- used to be mfs.)
  + My home directory resides in a file system on a partition in slice
    4 mounted on /common -- along with quite a few other things that do
    not need to physically be on the same slice that I booted from.
  + /usr/ports is a symlink to an SVN working copy (was a CVS working
    directory once upon a time) that's in the same file system as
    my home directory.
  + Historically, /usr/local was also a symlink to a hierarchy in that
    same file system.  (I only built ports under stable, but used them
    under both stable and head.)
  + /usr/obj is also a symlink to a hierarchy in that same file system
    (/common) -- I had one for each slice (/common/S{1,2,3,4}).

* Each of slices 1, 2, and 3 has a / and a /usr file system (as
  described above); slice 4 has those, as well as swap, /var, /common, and
  (often) a few others (e.g., /repo or /bkp).

* If I'm merely booting to single-user mode, each of the 4 slices is
  independent of the others, and I can boot any of them.  As soon as I
  start setting up swap, I become dependent on slice 4 (if I wasn't
  already booted from it).

It is not at all uncommon for me to "clone" one slice to another using a
'dump | restore' pipeline; by having the actual contents of /usr/obj in a
separate file system, it is easy to make copying that optional -- and if
my intent is to move it (vs. copy), renaming a directory is pretty fast
and cheap.

> Given that we have (or at least had at one time) some of those magical
> "..." paths that cause bmake to search up the hierarchy for its .mk
> files, I wonder if an odd relationship between src and obj dir confuses
> it, or if it somehow wanders into a wrong src tree while searching?
> ...

Well, I suspect that if that were an issue, I'd likely have encountered
it (while muttering further deprecation against realpath all the while).
:-}

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20150719/33784a6b/attachment.bin>


More information about the freebsd-current mailing list