2.6.18-rc1 build error (YACC): followup

2.6.18-rc1 build error (YACC): followup

[Bob Tracy]

I wrote:
>$YACC now seems to be undefined when I do a "make bzImage" and the
>build process gets to drivers/scsi/aic7xxx/aicasm (with the aic7xxx
>driver configured as a built-in).  As a workaround, it's possible to
>"cd" into the indicated directory and run "make" directly.  Once the
>default build completes, restarting "make bzImage" from the kernel
>source root continues as expected.

Found it.  The main "Makefile" has "MAKEFLAGS += -rR" uncommented as
of 2.6.18-rc1.  The deleted comment about "possibly random breakage"
that used to be just above that line pretty much says it all :-).

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: 2.6.18-rc1 build error (YACC): followup

[Sam Ravnborg]

On Fri, Jul 07, 2006 at 03:24:42PM -0500, Bob Tracy wrote:
> I wrote:
> >$YACC now seems to be undefined when I do a "make bzImage" and the
> >build process gets to drivers/scsi/aic7xxx/aicasm (with the aic7xxx
> >driver configured as a built-in).  As a workaround, it's possible to
> >"cd" into the indicated directory and run "make" directly.  Once the
> >default build completes, restarting "make bzImage" from the kernel
> >source root continues as expected.
> 
> Found it.  The main "Makefile" has "MAKEFLAGS += -rR" uncommented as
> of 2.6.18-rc1.  The deleted comment about "possibly random breakage"
> that used to be just above that line pretty much says it all :-).
Translated: aic7xxx must supply its own definition of YACC or we should
put it in the top-level Makefile.

kbuild no longer rely on the predefined variables in make.

	Sam

Re: 2.6.18-rc1 build error (YACC): followup

[Sam Ravnborg]

On Fri, Jul 07, 2006 at 03:24:42PM -0500, Bob Tracy wrote:
> I wrote:
> >$YACC now seems to be undefined when I do a "make bzImage" and the
> >build process gets to drivers/scsi/aic7xxx/aicasm (with the aic7xxx
> >driver configured as a built-in).  As a workaround, it's possible to
> >"cd" into the indicated directory and run "make" directly.  Once the
> >default build completes, restarting "make bzImage" from the kernel
> >source root continues as expected.
> 
> Found it.  The main "Makefile" has "MAKEFLAGS += -rR" uncommented as
> of 2.6.18-rc1.  The deleted comment about "possibly random breakage"
> that used to be just above that line pretty much says it all :-).
I have now applied a patch where YACC= bison is dined in
aicasm/Makefile.
There are no other $(YACC) users in the kernel - the others specify bison
direct.

	Sam

Re: 2.6.18-rc1 build error (YACC): followup

[H. Peter Anvin]

Sam Ravnborg wrote:
> On Fri, Jul 07, 2006 at 03:24:42PM -0500, Bob Tracy wrote:
>> I wrote:
>>> $YACC now seems to be undefined when I do a "make bzImage" and the
>>> build process gets to drivers/scsi/aic7xxx/aicasm (with the aic7xxx
>>> driver configured as a built-in).  As a workaround, it's possible to
>>> "cd" into the indicated directory and run "make" directly.  Once the
>>> default build completes, restarting "make bzImage" from the kernel
>>> source root continues as expected.
>> Found it.  The main "Makefile" has "MAKEFLAGS += -rR" uncommented as
>> of 2.6.18-rc1.  The deleted comment about "possibly random breakage"
>> that used to be just above that line pretty much says it all :-).
> I have now applied a patch where YACC= bison is dined in
> aicasm/Makefile.
> There are no other $(YACC) users in the kernel - the others specify bison
> direct.
> 

I propose the following as a global yacc rule; already used in usr/dash 
in the klibc tree, and which seems to work for both bison and BSD yacc:

quiet_cmd_yacc = YACC    $@
       cmd_yacc = $(YACC) -d -o $@ $<

$(obj)/%.c %(obj)/%.h: $(src)/%.y
         $(call cmd,yacc)


Note that bison seems to make smaller code than yacc, so I definiteily 
think we should default to bison over yacc.

	-hpa

Re: 2.6.18-rc1 build error (YACC): followup

[Sam Ravnborg]

On Fri, Jul 07, 2006 at 04:54:34PM -0700, H. Peter Anvin wrote:
> I propose the following as a global yacc rule; already used in usr/dash 
> in the klibc tree, and which seems to work for both bison and BSD yacc:
> 
> quiet_cmd_yacc = YACC    $@
>       cmd_yacc = $(YACC) -d -o $@ $<
> 
> $(obj)/%.c %(obj)/%.h: $(src)/%.y
>         $(call cmd,yacc)
klibc and the kernel does not share any rules today.
And yacc is so special that it's not worth it only for yacc to start
doing this.

In todays kernel build yacc is never used. For the few cases were output
of yacc is needed the kernel include _shipped files. For dash we should
maybe consider the same?

	Sam

Re: 2.6.18-rc1 build error (YACC): followup

[H. Peter Anvin]

Sam Ravnborg wrote:
> On Fri, Jul 07, 2006 at 04:54:34PM -0700, H. Peter Anvin wrote:
>> I propose the following as a global yacc rule; already used in usr/dash 
>> in the klibc tree, and which seems to work for both bison and BSD yacc:
>>
>> quiet_cmd_yacc = YACC    $@
>>       cmd_yacc = $(YACC) -d -o $@ $<
>>
>> $(obj)/%.c %(obj)/%.h: $(src)/%.y
>>         $(call cmd,yacc)
> klibc and the kernel does not share any rules today.
> And yacc is so special that it's not worth it only for yacc to start
> doing this.
> 
> In todays kernel build yacc is never used. For the few cases were output
> of yacc is needed the kernel include _shipped files. For dash we should
> maybe consider the same?
> 

Personally I consider that pretty silly.  yacc/bison is a standard, 
portable utility, and it isn't even architecture-dependent so there is 
no porting effort.

	-hpa

Re: 2.6.18-rc1 build error (YACC): followup

[Bob Tracy]

H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> > On Fri, Jul 07, 2006 at 04:54:34PM -0700, H. Peter Anvin wrote:
> >> I propose the following as a global yacc rule; already used in usr/dash 
> >> in the klibc tree, and which seems to work for both bison and BSD yacc:
> >>
> >> quiet_cmd_yacc = YACC    $@
> >>       cmd_yacc = $(YACC) -d -o $@ $<
> >>
> >> $(obj)/%.c %(obj)/%.h: $(src)/%.y
> >>         $(call cmd,yacc)
> > klibc and the kernel does not share any rules today.
> > And yacc is so special that it's not worth it only for yacc to start
> > doing this.
> > 
> > In todays kernel build yacc is never used. For the few cases were output
> > of yacc is needed the kernel include _shipped files. For dash we should
> > maybe consider the same?
> > 
> 
> Personally I consider that pretty silly.  yacc/bison is a standard, 
> portable utility, and it isn't even architecture-dependent so there is 
> no porting effort.

While the correct fix is being contemplated, LEX also needs defining in
the same aic7xxx/aicasm Makefile context.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------