yost@esquire.UUCP (David A. Yost) (06/14/90)
Imagine this:
Thinks to self: Hmm, where is the source to thingy?
Types this: cd /src/where/`which thingy`
Et voila!
Here's the idea:
For each installed binary or other file which is
built and installed from somewhere else (e.g.
the src tree), there is a symbolic link at a
corresponding path under the directory tree
/src/where, and this symbolic link points to
the directory where the source is found.
Each source directory contains an install
subdirectory, in which each file that is to
be installed exists as a symbolic link to its
installed location. Thus, the install target
in the Makefile copies to install/thingy, which
automatically causes the install to the right
place.
Benefits:
1. Provides a reliable mechanism to map between
each installed file and the location of its
source.
2. Source tree hierarchy need not model the
installed locations, but can (and should) be
organized according to other criteria, like
where the source came from, who maintains it,
etc. Source tree organizations to date that
I have seen mix these two models.
3. A program can be run to verify a one-to-one
correspondence between source and installed
versions of things, without having to
understand or even look at Makefiles or other
files.
I prefer this way of doing things to reliance on
tools such as the Berkeley `whereis' command
because `whereis' is only able to make guesses,
can give inconclusive, multiple answers, and has
information wired into it.
A similar technique using symbolic links could be
applied to mapping between installed files and
their corresponding online documentation, instead
of rummaging around in man1, man2, ... manl. For
example, /usr/man/usr/lib/sendmail would be a
symbolic link to /usr/man/man8/sendmail.8.
--dave yost
yost@dpw.com or uunet!esquire!yost
Please ignore the From or Reply-To fields above, if different.dce@smsc.sony.com (David Elliott) (06/15/90)
In article <2083@esquire.UUCP>, yost@esquire.UUCP (David A. Yost) writes: |> Imagine this: |> |> Thinks to self: Hmm, where is the source to thingy? |> Types this: cd /src/where/`which thingy` |> Et voila! I like your idea, Dave. I would like to point out, though, that with judicious use of cdpath, this can already be done. I've done a couple of Unix utilities ports in the past 7 years, and maintained X clients for over a year now. With such a large number of items, I've always had elements from my source trees in my cdpath. The source for 'ls' is always a 'cd ls' away. David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "If I had a hat the size of Oklahoma, I'd be a happy person."
jeff@quark.WV.TEK.COM (Jeff Beadles;685-2568;;;quark) (06/15/90)
yost@esquire.UUCP (David A. Yost) writes: >Imagine this: >Thinks to self: Hmm, where is the source to thingy? >Types this: cd /src/where/`which thingy` >Et voila! >Here's the idea: >For each installed binary or other file which is >built and installed from somewhere else (e.g. >the src tree), there is a symbolic link at a >corresponding path under the directory tree >/src/where, and this symbolic link points to >the directory where the source is found. >Each source directory contains an install >subdirectory, in which each file that is to >be installed exists as a symbolic link to its >installed location. Thus, the install target >in the Makefile copies to install/thingy, which >automatically causes the install to the right >place. [ ... ] At one time, I worked in a unix build environment where the entire environment was set-up like a user's system. For example, the top was "/ube/src" and if you wanted the source for /bin/passwd, you looked in /ube/src/bin/passwd. Libc was in /ube/src/lib/libc, etc... It was VERY easy to find your way around, although it did have other problems. (Find /bin/ex, which is a link to /bin/vi, etc... I know, there could have been yet another sumbolic link.) Also, this method assumes that all systems that use it have symbolic links. How about (looking to make sure that nobody is watching :-) MSDOS, and other operating systems that don't support soft links? -Jeff Jeff Beadles jeff@quark.WV.TEK.COM Utek Engineering, Tektronix Inc. +1 503 685 2568 SPEEA - Just say no.