Bruce Evans wrote:
On Sat, 12 Jul 2003, Tim Kientzle wrote:


Terry Lambert wrote:

Does this damage CURRENT on CURRENT or anything like that?

Don't know, haven't had a chance to try it.


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:

 * It updates the file "version" in the current directory
 * It creates the file "vers.c" in the current directory
 * 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.)

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.

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 don't really understand this machinery well enough
to propose a concrete fix, though.

Tim Kientzle

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to