svn commit: r334008 - head/bin/sh

[Bryan Drewery]

On 5/22/2018 5:30 PM, Bryan Drewery wrote:
> On 5/22/2018 1:22 PM, Jilles Tjoelker wrote:
>> On Tue, May 22, 2018 at 10:17:41AM +0200, O. Hartmann wrote:
>>> On Mon, 21 May 2018 21:45:53 -0700
>>> Cy Schubert <Cy.Schubert at cschubert.com> wrote:
>>>> In message <20180522061339.2149763e at freyja.zeit4.iv.bundesimmobilien.de>
>>>> , "O. H
>>>> artmann" writes:
>>>>> On Mon, 21 May 2018 21:52:48 +0000 (UTC)
>>>>> Jilles Tjoelker <jilles at FreeBSD.org> wrote:
>>
>>>>>> Author: jilles
>>>>>> Date: Mon May 21 21:52:48 2018
>>>>>> New Revision: 334008
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/334008
>>
>>>>>> Log:
>>>>>>   sh: Split CNL syntax category to avoid a check on state[level].syntax
>>
>>>>>>   No functional change is intended.
>>
>>>>>> Modified:
>>>>>>   head/bin/sh/mksyntax.c
>>>>>>   head/bin/sh/parser.c
>>> [snip]
>>
>>>>> Have this been tested? Doesn't compile for me:
>>
>>>>> [...]
>>>>> Building /usr/obj/usr/src/amd64.amd64/kerberos5/libexec/hprop/hprop
>>>>> --- all_subdir_rescue ---
>>>>> --- parser.o ---
>>>>> /usr/src/bin/sh/parser.c:1440:9: error: use of undeclared identifier 'CQNL'
>>>>>                         case CQNL:
>>>>>                              ^
>>>>> --- all_subdir_gnu ---
>>>>> Building /usr/obj/usr/src/amd64.amd64/gnu/usr.bin/gdb/libgdb/amd64bsd-nat.o
>>>>> --- all_subdir_rescue ---
>>>>> 1 error generated.
>>>>> *** [parser.o] Error code 1
>>
>>>>> make[6]: stopped in /usr/src/bin/sh
>>
>>>> CQNL is defined in /usr/obj/opt/src/svn-current/amd64.amd64/bin/sh/synta
>>>> x.h, generated by mksyntax.
>>
>>>> slippy$ ag -s CQNL /export/obj/opt/src/svn-current/amd64.amd64/bin/sh/*.
>>>> h
>>>> /export/obj/opt/src/svn-current/amd64.amd64/bin/sh/syntax.h
>>>> 11:#define CQNL 2			/* newline character in quotes */
>>>> slippy$ 
>>
>>>> Remove the file if it's not defined in your syntax.h.
>>
>>>> Just out of interest, do you use meta mode?
>>
>>> I think such a question is of common interest if errors/bugs like that occur:
>>> Yes, I use/compile world/kernel with META mode.
>>
>> The change itself is fine. It built for me and for Jenkins
>> (ci.freebsd.org). What is not fine is an incremental build with meta
>> mode. Apparently, the  syntax.h: .NOMETA  rule added in r301285 causes
>> bmake to build some files against the old syntax.h, even though syntax.c
>> and syntax.h will be rebuilt.
>>
>> To fix this, it may be possible to generate a meta file for syntax.h
>> based on the one for syntax.c. The same would be done for builtins.[ch]
>> and nodes.[ch].
>>
>> Conceptually simpler is accepting what make would like: one command
>> generates one file only. This is not really new with meta mode since a
> 
> Yeah bmake (both with and without meta mode) is lacking in properly
> handling 1 target generating multiple files.  It's a big frustration of
> mine as every pattern I've seen does not do the right thing.  I'll look
> into this case more. For now just remove the syntax.h file from the
> objdir or remove the bin/sh dir.
> 
>> somewhat ugly .ORDER declaration had been necessary before. The .c
>> content can go inside a #ifdef in the .h file so the .c file need not be
>> autogenerated, or the tools can be run twice, once to generate the .c
>> file and once to generate the .h file. In both cases, the tools will be
>> somewhat uglier in order to simplify the build system.
>>
> 
> 


The problem is the rescue build is doing 'make foo.o bar.o' rather than
'make all', so the implicit 'make depend' phase is skipped. Switching
rescue (crunchgen) to use 'make all' fixes it. I am testing a full build
of that now and will commit it soon.

The .NOMETA does certainly cause the problem but 'make all' ensures the
implicit 'make depend' will always run for all modes as intended.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20180523/f3fd6d5c/attachment.sig>