Re: A couple of config(1) questions

[mlelstv%serpens.de@localhost (Michael van Elst)]

paul%vps1.whooppee.com@localhost (Paul Goyette) writes:

>The man page for config(9) says the syntax for including source files is
> 	file pathname [attributes [flags]] [rule]
>It doesn't actually describe the syntax for [rule] but examples seem to 
>indicate that we can do at least rudimentary boolean expressions, ie
> 	x & y
> 	x | y | z
> 	x & !w
>Just how complex can these expressions be?  For example, can I use
> 	(a | b) & (x | y | z)
>with parentheses?


config uses a yacc grammar (src/usr.bin/config/gram.y):

define_file:
        XFILE filename fopts fflags rule        { addfile($2, $3, $4, $5); }

/* filename. */ 
filename:
          QSTRING                       { $$ = $1; }
        | PATHNAME                      { $$ = $1; }
;

/* file options: optional expression of conditions */
fopts:
          /* empty */                   { $$ = NULL; }
        | condexpr                      { $$ = $1; }
;

/* zero or more flags for a file */
fflags:
          /* empty */                   { $$ = 0; } 
        | fflags fflag                  { $$ = $1 | $2; }
;       

/* one flag for a file */
fflag:
          NEEDS_COUNT                   { $$ = FI_NEEDSCOUNT; }
        | NEEDS_FLAG                    { $$ = FI_NEEDSFLAG; }
;

/* extra compile directive for a source file */
rule:
          /* empty */                   { $$ = NULL; }
        | COMPILE_WITH stringvalue      { $$ = $2; }
;


So it's the options that can be an expression. [rule] is
the keyword 'compile-with' followed by a string holding
a compiler command that is used in the generated Makefile.
Without a rule, config generates the rule ${NORMAL_<upper-case-suffix>}
I.e. ${NORMAL_C} for a C file. That variable is defined in
sys/conf/Makefile.kern.inc.

The condexpr used for fopts can handle the operators |,& and
! (or,and,not) and allows parenthesis, i.e. (a | b) & (x | y | z)
works fine. But the parser does not handle negations of sub-expressions
like !( a | b ).

/* expression of conditions */
condexpr:
        cond_or_expr
;

cond_or_expr:
          cond_and_expr
        | cond_or_expr '|' cond_and_expr        { $$ = MKF2(cx, or, $1, $3); }
;

cond_and_expr:
          cond_prefix_expr
        | cond_and_expr '&' cond_prefix_expr    { $$ = MKF2(cx, and, $1, $3); }
;       
 
cond_prefix_expr:
          cond_base_expr
/* XXX notyet - need to strengthen downstream first */
/*      | '!' cond_prefix_expr                  { $$ = MKF1(cx, not, $2); } */
;       
 
cond_base_expr:
          condatom                      { $$ = $1; }
        | '!' condatom                  { $$ = MKF1(cx, not, $2); }
        | '(' condexpr ')'              { $$ = $2; }
;       
  
/* basic element of config element expression: a config element */
condatom:
        WORD                            { $$ = MKF1(cx, atom, $1); }
;                       


>Question 2:  does config(1) support '\' at the end of a physical line to 
>indicate line continuation?  (If the complex boolean expression above is 
>supported, I'm likely to have a longer-than-80-char command!)

The config parser uses a different syntax to handle continuation
lines. From config(9):

     Each device definition file consists of a list of statements, typically
     one per line.  Comments may be inserted anywhere using the ``#''
     character, and any line that begins with white space continues the
     previous line.

See also src/usr.bin/config/scan.l:

\n[ \t] {
                /*
                 * Note: newline followed by whitespace is always a
                 * continuation of the previous line, so do NOT
                 * return a token in this case.
                 */
                yyline++;
        }


-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."