Subject: bug#10313: configure fails to find include path on openbsd

From: David De La Harpe Golden <[email-masked]>
Date: Sat, 24 Dec 2011 03:40:28 +0000

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