[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10313: configure fails to find include path on openbsd
From: |
David De La Harpe Golden |
Subject: |
bug#10313: configure fails to find include path on openbsd |
Date: |
Sat, 24 Dec 2011 03:40:28 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 |
On 17/12/11 01:23, Paul Eggert wrote:
Thanks for the bug report. I worry that that fix,
though it works for you, may cause problmes on other
OpenBSD installations. So I have some questions.
First, Is this use of /usr/local standardized by OpenBSD?
Is there documentation for this somewhere?
I for one welcome our OpenBSD over... I mean, I suspect Emacs upstream
(i.e. "us") hardcoding an extra /usr/local search path would _not_ be
welcomed by the GNU Emacs OpenBSD port&package maintainers - though I
don't actually speak for them, maybe one Manuel Giraud already knows
them [0]?
Why? Well...
***
OpenBSD local modifications to gcc seem comprehensively documented in
their gcc-local manpage: policy is to explicitly modify the system gcc
to stop it looking in /usr/local [1]:
"""
gcc does not search under /usr/local for include files nor for
libraries: as a system compiler, it only searches the system paths
by default.
"""
***
BUT: /usr/local is where OpenBSD packages and ports install to, it's not
quite the playground it is on some systems. The OpenBSD system is fairly
simple [2]:
"""
Packages install to /usr/local
"""
***
So, um how does that work, you may ask? Well, AFAICS the Done Thing is
to always explicitly specify the extra paths required on the command
line in the package/port build wrapper scripts [3]:
"""
CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include \
-I${LOCALBASE}/include/libpng" \
LDFLAGS="-L${LOCALBASE}/lib"
"""
***
But note $LOCALBASE variable, it is NOT just a hardcoded /usr/local !
In bsd.port.mk, we find [4]:
"""
LOCALBASE where other ports have already been installed. Default:
/usr/local.
"""
***
So, in conclusion, a hardcoded /usr/local is IMO The Wrong Thing for
upstream Emacs on OpenBSD, especially seeing as advanced folk may be
futzing with $LOCALBASE.
Now, the OpenBSD ports&package maintainers can of course just patch out
anything that upstream Emacs adds that they don't like, but IMO no point
putting them to that hassle, and IMO users building from upstream source
on OpenBSD outside the garden of the ports&packages system are advanced
and therefore might be expected to be prepared for little OpenBSD quirks
like having to add the extra paths themselves.
***
[0] http://www.openbsd.org/cgi-bin/cvsweb/ports/editors/emacs23/distinfo
[1] http://www.openbsd.org/cgi-bin/man.cgi?query=gcc-local&sektion=1
[2] http://www.openbsd.org/cgi-bin/man.cgi?query=packages&sektion=7
[3] http://www.openbsd.org/cgi-bin/cvsweb/ports/editors/emacs23/Makefile
[4] http://www.openbsd.org/cgi-bin/man.cgi?query=bsd.port.mk&sektion=5