Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Mar 2002 08:33:50 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Dag-Erling Smorgrav <des@ofug.org>
Cc:        <arch@FreeBSD.ORG>
Subject:   Re: bsd.lib.mk modifications
Message-ID:  <20020319080926.C2957-100000@gamplex.bde.org>
In-Reply-To: <xzpr8mipcjo.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Mar 2002, Dag-Erling Smorgrav wrote:

> Bruce Evans <bde@zeta.org.au> writes:
> > Why not just set INCDIR?  I think the most useful meaning for INCDIR is
> > "the (single) directory in which the current set of includes is installed",
> > not "the root of the include tree (default /usr/include)" although the
> > comment in bsd.own.mk suggests the latter meaning.
>
> Ah, I interpreted it as the latter.  Also, using a separate INCSUBDIR
> allows the admin to set INCDIR to whatever he wants and still get
> things "right" (assuming he also patched gcc to look for headers in
> INCDIR); it just seemed cleaner to do it this way.

Well, we only have one other example of FOOSUBDIR (MANSUBDIR), and supporting
and using it (correctly) always seemed to be harder than changing the "base"
to me.  This may be because when you want special subdirs, you often want
more than one, in a file-specific way.

> > >  - make ${INCS} a prerequisite of _includeinstall so generated headers
> > >    will be built in time for beforeinstall (again, to avoid overriding
> > >    beforeinstall).
> > This may result in the headers being built at install time.
>
> Well, they should already exist at install time; the problem I'm
> trying to solve is making sure they exist at 'make includes' time
> during buildworld.

This was handled for libss by building them for 'make includes' but
not for any other install step.

> I now use this:
>
> @@ -282,13 +282,17 @@
>  beforeinstall: _includeinstall
>  .endif
>
> -_includeinstall:
> +_includeinstall: ${INCS}

I think any dependency here causes problems.

> in an attempt to handle the case where we actually install generated
> headers.  The only case I know of so far is libcrypto, which modifies
> some headers at build time to remove potentially-legally-troublesome
> IDEA code, and overrides beforeinstall to deal with this.  I'm trying
> to make the default beforeinstall target smart enough that it doesn't
> need so much overriding.

libcrypto is already broken if it changes the object directory at
install time (this breaks installing from read-only mounts of the
object directory) ... its current beforeinstall target is obviously
broken in theory, since it begins with

beforeinstall:  openssl/opensslconf.h openssl/evp.h

This should cause rebuilding of these headers in the openssl subdir
of the obj directory if the sources are newer.  I think it does.
The dependencies for all the other headers in openssl are broken
(nonexistent), but not the dependencies for these.  All the other
headers get built as a side effect of building opensslconf.h.
This breaks "make depend; make" after a source update, unless
opensslconf.h has changed or the obj directory or openssl subdir
is deleted.

Thanks for cleaning up this Makefile :-).

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020319080926.C2957-100000>