On Tue, Jul 25, 2000 at 07:46:02PM +1000, HOOD, Andy wrote:
> I have run into this multiple times in the past with lots of user compiled
> packages on Slackware, Solaris and HP-UX (which I use) and with RedHat
> (solving other people's problems).
> The Gnuish install location is /usr/local. Slackware installs many of the
> non-X11 packages to /usr and the X11 ones to /usr/X11R6. Solaris uses either
> /usr/local or /opt/packagename. HP-UX uses /opt/packagename. RedHat does
> different things.
>
> If you want things to be seamless, you have to look where your package
> manager put bits and build for the same location.
Well, I've just checked in a change that checks where aclocal thinks
autoconf/automake macros should be, and where GTK+ thinks it hid them,
and, if both aclocal and GTK+ reported something meaningful (this
attempts to cope with the nonexistence or unavailability of aclocal and
gtk-config) but disagree, causes a "-I" flag to be jammed down aclocal's
throat causing it to look also where GTK+ hid its macros.
Similar hacks could perhaps be added to the "aclocal-flags" script I
checked for any other packages, *if* there's a good way to find out
where those packages are installed (and if the autoconf/automake macros
for that package are hidden in the obvious place, i.e. in a
"share/aclocal" directory under the "prefix" directory for the package).
Sigh. Sometimes I think of software development as a pitched battle
between the developer of a package and the developers of all the
software on which it depends, with the latter developers trying as hard
as they can to throw in Surprising New Twists to break the former
developer's package and the former developer trying equally hard to cope
with the stuff that gets thrown them.
Scarcely a week seems to go by where *something* in some OS, or in a
third-party package that Ethereal uses, doesn't show up as a Lovely
Little Surprise in a new version, or when the third-party packages etc.
aren't installed in a directory Ethereal's expecting, or....