unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: David De La Harpe Golden <david@harpegolden.net>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 10313@debbugs.gnu.org, Manuel Giraud <manuel@ledu-giraud.fr>
Subject: bug#10313: configure fails to find include path on openbsd
Date: Sat, 24 Dec 2011 03:40:28 +0000	[thread overview]
Message-ID: <4EF549AC.3050104@harpegolden.net> (raw)
In-Reply-To: <4EEBEF0C.4050604@cs.ucla.edu>

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









  parent reply	other threads:[~2011-12-24  3:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 10:51 bug#10313: 24.0.92; configure fails to find include path on openbsd Manuel Giraud
2011-12-17  1:23 ` bug#10313: " Paul Eggert
2011-12-17  3:07   ` Glenn Morris
2011-12-24  3:40   ` David De La Harpe Golden [this message]
2012-01-02 18:42     ` Glenn Morris
2012-01-02 18:51       ` Paul Eggert
2012-01-02 20:54       ` David De La Harpe Golden
2012-01-02 21:51       ` David De La Harpe Golden
2012-01-03 14:10     ` Manuel Giraud
2012-01-09 16:43     ` Manuel Giraud
2012-01-09 17:12       ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EF549AC.3050104@harpegolden.net \
    --to=david@harpegolden.net \
    --cc=10313@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=manuel@ledu-giraud.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).