Date: Mon, 18 Mar 2002 10:21:21 -0700 From: John E Hein <jhein@timing.com> To: hackers@FreeBSD.ORG Subject: ports & DESTDIR (was: STLPORT and gcc3 (openoffice porting)) Message-ID: <15510.8721.546546.172867@brain.timing.com> In-Reply-To: <bulk.10690.20020318034730@hub.freebsd.org> References: <bulk.10690.20020318034730@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert2@mindspring.com> wrote 20:42:42 -0800 on Mar 17:
> Paul Marquis wrote:
> > Since the port of STLport is designed as a drop in replacement for
> > the system STL, I've always used the -nostdinc++ option in my
> > projects so that gcc won't even look at the default header files.
> > This option should be used when building the port itself. As the
> > STLport maintainer, I should have specified that. :-(
>
> From bsd.prog.mk:
> - ----------------------------------------------------------------
> .if defined(DESTDIR) && !defined(BOOTSTRAPPING)
> CFLAGS+= -I${DESTDIR}/usr/include
> CXXINCLUDES+= -I${DESTDIR}/usr/include/g++
> .endif
> - ----------------------------------------------------------------
>
> That option does not good, if you set DESTDIR and use the BSD
> .mk file system, which will put it right back in the options
> list for the program being built.
>
> You really do have to hack up the Makefile to list the port
> compiler include path first, or this overrides it.
>
> The typical way I do this for the includes is to redefine
> the compiler to have a "-I/usr/local/<where ever>" as part
> of the command itself. It's generally harmless, otherwise.
>
> Otherwise... don't set "DESTDIR", or explicitly set
> "BOOTSTRAPPING". Both of these have side effects that
> are harder to control than jamming the include path into
> the compiler command.
bsd.ports.mk uses DESTDIR differently (wrongly IMO) than FreeBSD's
buildworld or the rest of the world as far as I have seen. See (and
lobby for) ports/28155. Unfortunately, the fix in 28155 will make
DESTDIR behave the "right" way, and thus anyone expecting the "wrong"
behavior will be surprised. OTOH, any ports using DESTDIR will do the
wrong thing now anyway in many cases (see the How-To-Repeat in PR 28155).
The problem with 28155 is that is a sweeping change that requires fixes
to all ports that incorrectly use PREFIX & DESTDIR. But, if they don't
define DESTDIR by default (the vast majority don't), then the patch
is a no-op. If you build with 'make DESTDIR=/some/where', this patch
will do the "right" thing. (I don't know if this will fix the STPORT
problem since I didn't look that closely at it, but the direction Terry
was taking that thread made me think of 28155).
Anyway, I've never built the entire ports tree with the patch from 28155,
just the few dozen ports we've needed for our products. So I don't know
how badly it would break the ports tree (if at all). There may be a less
disruptive fix than my patch (although we've been using it successfully
in product builds here), but the whole ports/DESTDIR problem has been
there for a long time now.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15510.8721.546546.172867>