Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Jul 2003 12:57:01 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Tim Kientzle <kientzle@acm.org>
Cc:        Andrey Elperin <mizzy@colocall.net>
Subject:   Re: make release of CURRENT on 4.7 box
Message-ID:  <20030713123229.A2435@gamplex.bde.org>
In-Reply-To: <3F10B60C.3000106@acm.org>
References:  <20030712165749.GA14599@colocall.net> <3F104A71.7060906@acm.org> <3F105499.BC7768C0@mindspring.com> <3F10576E.3060904@acm.org> <20030713095642.B1771@gamplex.bde.org> <3F10B60C.3000106@acm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Jul 2003, Tim Kientzle wrote:

> Bruce Evans wrote:
> > On Sat, 12 Jul 2003, Tim Kientzle wrote:
> >>To be honest, I was never able to understand how
> >>the previous version was supposed to work, since
> >>the newvers.sh script was run with a very
> >>odd current directory.
> >
> > Looks like it was assumed to just set variables, so that sourcing
> > it doesn't make a mess.
>
> Here's the part that confuses me.
> sys/conf/newvers.sh does more than just
> set variables:

I think it was originally only for building ver* files for kernels.
Then it got (mis)used in src/include/Makefile.

>   * It updates the file "version" in the current directory
>   * It creates the file "vers.c" in the current directory

This is very old kernel-building stuff.  The only problem with it
seems to be that it writes garbage files vers.c and `version' to
the current directory (always the object directory for src/include?)

>   * It runs 'make -V KERN_IDENT' , which assumes at a minimum
>     that there is a Makefile in the current directory.
>     (Otherwise, you're invoking 'make' with no target.)

This part is from a commit to newvers.sh last month.

> When building -CURRENT on 4.7, the build fails in
> /usr/src/include because of the following:
>
> osreldate.h:    ${.CURDIR}/../sys/conf/newvers.sh \
>                  ${.CURDIR}/../sys/sys/param.h \
>                  ${.CURDIR}/Makefile
>          @${ECHO} creating osreldate.h from newvers.sh
>          @setvar PARAMFILE ${.CURDIR}/../sys/sys/param.h; \
>          . ${.CURDIR}/../sys/conf/newvers.sh;                    \
>          echo "$$COPYRIGHT" > osreldate.h;                       \
>
> In particular, newvers.sh is being run with the
> current directory being ${.OBJDIR}, and ${.OBJDIR}
> doesn't contain a Makefile, so the 'make -V KERN_IDENT'
> fails.  My patch just runs newvers.sh in ${.CURDIR},
> which is also wrong, since that creates two files in
> ${.CURDIR} that shouldn't be there.

The difference seems to be that `make -V FOO' doesn't require a Makefile
in -current.  I think this is a side effect of indirectly related fixes
for make -V (maybe the one to fix `make -f /dev/null -V FOO'.  ISTR
`make foo.o' never required a Makefile with BSD make.  Apparently
`make -V' was surprisingly different, and still is in 4.7.

> I don't know the "right" way to fix this, because
> I don't really understand why 'osreldate.h' cares
> about KERN_IDENT, nor why it is reasonable for vers.c
> and version to be created as side-effects.  I suspect
> that newvers.sh should be broken into two pieces: one
> that sets the variables and another that creates/updates
> version and vers.c.  The former might then be useful
> in building osreldate.h.

I think splitting it or making it exit after just setting variables
in the userland case is the right fix.  I don't completely understand
the KERN_IDENT changes, but they are only relevant for building kernels
so we just need to turn them off for src/include/Makefile.

Bruce



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