gcc driver language: poll

gcc driver language: poll

[Zack Weinberg]

I am contemplating rewriting the gcc driver.  The rewrite would have
two goals: make the spec language less incomprehensible, and compile
nothing into the driver program itself.

I've sort-of devised a new spec language, and I'd like to know if you
think it is indeed less incomprehensible than the current one.
Therefore, here are two sample specs for the new language.  They are
direct rewrites of the analogous specs in current GCC.  Please tell me
what you think.  (Documentation is appended, but try to read 'em
without, first, please.  Note that some things -- like forbidding -C
without -E -- are handled elsewhere than they are in current GCC.)

zw

# Rule to preprocess C source files.
%.i: %.c
  cpp -lang-c {~ansi?-std=c89} ~std* ~pedantic
      ~traditional {~ftraditional~traditional-cpp?-traditional}
      ~[CvPH] ~W* ~w ~g* ~d*
      ~M ~MM {~MD|~MMD?$& %(output $*.d)} ~MG
      -undef -D__GNUC__=$M -D__GNUC_MINOR__=$m
      {~ansi~std={!gnu}*?-trigraphs -D__STRICT_ANSI__}
      {~undef?:
          {~ansi~std={!gnu}*?:[-D$(bare-predefs)]}
          [-D__$(bare-predefs)__] [-D$(predefs)] [-A$(assertions)]}
      {~Os?-D__OPTIMIZE_SIZE__} {~O{!0}*?-D__OPTIMIZE__}
      {~ffast-math?-D__FAST_MATH__}
      ~f(no-)leading-underscore $(signed-char) $(cppflags)
      ~[ADU]* [-iprefix $P] ~[iI]* %(expand ~Wp,(*)) $< $@

# Linker flags (sparc-sun-solaris2.6)
libpath = /usr/ccs/lib:/usr/lib
proflibpath = /usr/ccs/lib/libp:/usr/lib/libp

ldflags = ~h* {~v?-V} ~b %(expand ~Wl,(*)) ~G ~R* {~Qy:} {~Qn:-Qy}
  {~static?-dn -Bstatic}
  {~shared?-G -dy {~mimpure-text?:-z text}}
  {~symbolic?-Bsymbolic -G -dy -z text}
  {~YP,*:-Y P,{~compat-bsd?/usr/ucblib$:}{~pg?$(proflibpath)$:}$(libpath)}
  {~compat-bsd?-R /usr/ucblib}

---

$(foo)			user variable
$x, $<			magic variable

~X, ~switch		-X, if -X was an argument to the program
~X*			all switches beginning with -X
~X(*)			same as ~X*, but delete -X
~[ABCD]			all of -A, -B, -C, -D that were supplied;
			may be used with *, (*)
~f(no-)foo		either -ffoo or -fno-foo or both
~std={!gnu}*		all switches beginning -std= that do /not/ begin
			-std=gnu

[...$(foo)...]		as $(foo) but with the surrounding text placed
			around each word: e.g. if foo is "sparc unix"
			then $[-D__$(foo)__] is -D__sparc__ -D__unix__

{foo?bar:baz}		if FOO is nonempty, substitute BAR, else BAZ.
			leading/trailing white space in each area is not
			significant.
{foo|bar?baz:quux}	as above, but if both FOO and BAR are nonempty,
			it is an error.

{foo?bar:}		if FOO is nonempty, substitute BAR, else nothing.
{foo?bar}		same

{foo?:bar}		if FOO is nonempty, substitute nothing, else BAR.
{foo:bar}		if FOO is nonempty, substitute FOO, else BAR.

%(func args)		substitution function:

  %(env FOO)		environment variable FOO

  %(squeeze TEXT)	TEXT, with spaces removed between options and args
  %(expand TEXT)	TEXT, with commas replaced by spaces

  %(Bpath FILE)		find FILE in the search path specified by -B,
  %(Lpath FILE)		-L, or -I switches, and return its absolute
  %(Ipath FILE)		pathname

  %(output FILE)	FILE is to be deleted on failure
  %(inter FILE)		FILE is to be deleted on exit
  %(temp .S)		temp file ending in .S; returns the same name
			for the same suffix; implies %(inter); if -save-temps,
			degenerates to $*.S
  %(tmp .S)		same thing, but %(temp .S) and %(tmp .S) are 
			different files, and %(tmp) doesn't degenerate to $*.S
			if -save-temps.

   Note: $< and $@ do not need to be marked with %(output) or %(inter) or
   set via use of %(temp)/%(tmp).

Magic variables:

$@			the target of this pass; empty if writing stdout
$<			the input to this pass; empty if reading stdin
$*			basename of the input to this pass
$^			all the inputs to this pass (only valid for linker)
$|			"-" if we are reading stdin

$&			in {...?...:...}, whatever the first part expanded to

$O			extension for object files
$X			extension for executables
$M			major version number of compiler (-V)
$m			minor version
$P			current prefix (.../lib/gcc-lib/TARG/VERS) but only
			if -b or -V were used to change it

$$			a dollar sign
${			a left brace
$}			a right brace
$[			a left square bracket
$]			a right square bracket
$?			a question mark
$:			a colon
$~			a tilde

Re: gcc driver language: poll

[Richard Henderson]

On Tue, Mar 23, 1999 at 05:36:14PM -0500, Zack Weinberg wrote:
> I've sort-of devised a new spec language, and I'd like to know if you
> think it is indeed less incomprehensible than the current one.

Not really. 

It is a bit more powerful though, so that shouldn't necessarily stop you.


r~

Re: gcc driver language: poll

[craig]

I don't see any obvious problems with the new proposal, but am not
sufficiently "in touch" with the world of specs to want anyone to
take that as any kind of endorsement.  One question:

>~X*			all switches beginning with -X
>~X(*)			same as ~X*, but delete -X

Would it be reasonable to replace the second form with this?

>~X?*			same as ~X*, excluding -X

Maybe I misunderstand "delete".  Also, I'm thinking in terms of the
syntax looking a bit more like wildcarding than it currently does.
(That might or might not be a good thing in the long run.)

Generally, though, I think `(*)' is syntactically inappropriate to
mean one or more following characters.  Perhaps another character
could be found, etc.

        tq vm, (burley)

Re: gcc driver language: poll

[Richard Henderson]

On Tue, Mar 23, 1999 at 05:36:14PM -0500, Zack Weinberg wrote:
> I've sort-of devised a new spec language, and I'd like to know if you
> think it is indeed less incomprehensible than the current one.

Not really. 

It is a bit more powerful though, so that shouldn't necessarily stop you.


r~

gcc driver language: poll

[Zack Weinberg]

I am contemplating rewriting the gcc driver.  The rewrite would have
two goals: make the spec language less incomprehensible, and compile
nothing into the driver program itself.

I've sort-of devised a new spec language, and I'd like to know if you
think it is indeed less incomprehensible than the current one.
Therefore, here are two sample specs for the new language.  They are
direct rewrites of the analogous specs in current GCC.  Please tell me
what you think.  (Documentation is appended, but try to read 'em
without, first, please.  Note that some things -- like forbidding -C
without -E -- are handled elsewhere than they are in current GCC.)

zw

# Rule to preprocess C source files.
%.i: %.c
  cpp -lang-c {~ansi?-std=c89} ~std* ~pedantic
      ~traditional {~ftraditional~traditional-cpp?-traditional}
      ~[CvPH] ~W* ~w ~g* ~d*
      ~M ~MM {~MD|~MMD?$& %(output $*.d)} ~MG
      -undef -D__GNUC__=$M -D__GNUC_MINOR__=$m
      {~ansi~std={!gnu}*?-trigraphs -D__STRICT_ANSI__}
      {~undef?:
          {~ansi~std={!gnu}*?:[-D$(bare-predefs)]}
          [-D__$(bare-predefs)__] [-D$(predefs)] [-A$(assertions)]}
      {~Os?-D__OPTIMIZE_SIZE__} {~O{!0}*?-D__OPTIMIZE__}
      {~ffast-math?-D__FAST_MATH__}
      ~f(no-)leading-underscore $(signed-char) $(cppflags)
      ~[ADU]* [-iprefix $P] ~[iI]* %(expand ~Wp,(*)) $< $@

# Linker flags (sparc-sun-solaris2.6)
libpath = /usr/ccs/lib:/usr/lib
proflibpath = /usr/ccs/lib/libp:/usr/lib/libp

ldflags = ~h* {~v?-V} ~b %(expand ~Wl,(*)) ~G ~R* {~Qy:} {~Qn:-Qy}
  {~static?-dn -Bstatic}
  {~shared?-G -dy {~mimpure-text?:-z text}}
  {~symbolic?-Bsymbolic -G -dy -z text}
  {~YP,*:-Y P,{~compat-bsd?/usr/ucblib$:}{~pg?$(proflibpath)$:}$(libpath)}
  {~compat-bsd?-R /usr/ucblib}

---

$(foo)			user variable
$x, $<			magic variable

~X, ~switch		-X, if -X was an argument to the program
~X*			all switches beginning with -X
~X(*)			same as ~X*, but delete -X
~[ABCD]			all of -A, -B, -C, -D that were supplied;
			may be used with *, (*)
~f(no-)foo		either -ffoo or -fno-foo or both
~std={!gnu}*		all switches beginning -std= that do /not/ begin
			-std=gnu

[...$(foo)...]		as $(foo) but with the surrounding text placed
			around each word: e.g. if foo is "sparc unix"
			then $[-D__$(foo)__] is -D__sparc__ -D__unix__

{foo?bar:baz}		if FOO is nonempty, substitute BAR, else BAZ.
			leading/trailing white space in each area is not
			significant.
{foo|bar?baz:quux}	as above, but if both FOO and BAR are nonempty,
			it is an error.

{foo?bar:}		if FOO is nonempty, substitute BAR, else nothing.
{foo?bar}		same

{foo?:bar}		if FOO is nonempty, substitute nothing, else BAR.
{foo:bar}		if FOO is nonempty, substitute FOO, else BAR.

%(func args)		substitution function:

  %(env FOO)		environment variable FOO

  %(squeeze TEXT)	TEXT, with spaces removed between options and args
  %(expand TEXT)	TEXT, with commas replaced by spaces

  %(Bpath FILE)		find FILE in the search path specified by -B,
  %(Lpath FILE)		-L, or -I switches, and return its absolute
  %(Ipath FILE)		pathname

  %(output FILE)	FILE is to be deleted on failure
  %(inter FILE)		FILE is to be deleted on exit
  %(temp .S)		temp file ending in .S; returns the same name
			for the same suffix; implies %(inter); if -save-temps,
			degenerates to $*.S
  %(tmp .S)		same thing, but %(temp .S) and %(tmp .S) are 
			different files, and %(tmp) doesn't degenerate to $*.S
			if -save-temps.

   Note: $< and $@ do not need to be marked with %(output) or %(inter) or
   set via use of %(temp)/%(tmp).

Magic variables:

$@			the target of this pass; empty if writing stdout
$<			the input to this pass; empty if reading stdin
$*			basename of the input to this pass
$^			all the inputs to this pass (only valid for linker)
$|			"-" if we are reading stdin

$&			in {...?...:...}, whatever the first part expanded to

$O			extension for object files
$X			extension for executables
$M			major version number of compiler (-V)
$m			minor version
$P			current prefix (.../lib/gcc-lib/TARG/VERS) but only
			if -b or -V were used to change it

$$			a dollar sign
${			a left brace
$}			a right brace
$[			a left square bracket
$]			a right square bracket
$?			a question mark
$:			a colon
$~			a tilde

Re: gcc driver language: poll

[craig]

I don't see any obvious problems with the new proposal, but am not
sufficiently "in touch" with the world of specs to want anyone to
take that as any kind of endorsement.  One question:

>~X*			all switches beginning with -X
>~X(*)			same as ~X*, but delete -X

Would it be reasonable to replace the second form with this?

>~X?*			same as ~X*, excluding -X

Maybe I misunderstand "delete".  Also, I'm thinking in terms of the
syntax looking a bit more like wildcarding than it currently does.
(That might or might not be a good thing in the long run.)

Generally, though, I think `(*)' is syntactically inappropriate to
mean one or more following characters.  Perhaps another character
could be found, etc.

        tq vm, (burley)