You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2010/09/29 23:31:38 UTC

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Working to catch up the win32 build change here...

> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/Makefile.in?rev=1002824&r1=1002823&r2=1002824&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/ssl/Makefile.in (original)
> +++ httpd/httpd/trunk/modules/ssl/Makefile.in Wed Sep 29 19:42:03 2010
> @@ -25,15 +25,13 @@ include $(top_srcdir)/build/special.mk
>  #
>  
>  ssl_expr_scan.c: $(top_srcdir)/modules/ssl/ssl_expr_scan.l ssl_expr_parse.h
> -	flex -Pssl_expr_yy -s -B $(top_srcdir)/modules/ssl/ssl_expr_scan.l
> -	sed -e '/$$Header:/d' -e "s|\"`pwd`/|\"|g" <lex.ssl_expr_yy.c >ssl_expr_scan.c && rm -f lex.ssl_expr_yy.c
> +	flex -Pssl_expr_yy -o ssl_expr_scan.c ssl_expr_scan.l
> +	mv ssl_expr_scan.c ssl_expr_scan.c.tmp
> +	sed -e "s|\"`pwd`/|\"|g" <ssl_expr_scan.c.tmp >ssl_expr_scan.c
> +	rm -f ssl_expr_scan.c.tmp
>  
>  ssl_expr_parse.c ssl_expr_parse.h: $(top_srcdir)/modules/ssl/ssl_expr_parse.y
> -	yacc -d $(top_srcdir)/modules/ssl/ssl_expr_parse.y
> -	sed -e 's;yy;ssl_expr_yy;g' \
> -	    -e "s|\"`pwd`/|\"|g" \
> -	    -e '/#if defined(c_plusplus) || defined(__cplusplus)/,/#endif/d' \
> -	    <y.tab.c >ssl_expr_parse.c && rm -f y.tab.c
> -	sed -e 's;yy;ssl_expr_yy;g' \
> -	    <y.tab.h >ssl_expr_parse.h && rm -f y.tab.h
> -
> +	bison -pssl_expr_yy --defines=ssl_expr_parse.h -o ssl_expr_parse.c ssl_expr_parse.y
> +	mv ssl_expr_parse.c ssl_expr_parse.c.tmp
> +	sed -e "s|\"`pwd`/|\"|g" < ssl_expr_parse.c.tmp > ssl_expr_parse.c
> +	rm -f ssl_expr_parse.c.tmp
> 

You just invalidated some arbitrary versions of bison (testing on 1.28)...
"option `--defines' doesn't allow an argument"

Should we be testing for a baseline rev of bison which is acceptable?

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 30 September 2010, William A. Rowe Jr. wrote:
> 
> 	2001-09-18  Marc Autret  <au...@epita.fr>
> 
> 	* src/getargs.c (longopts): Declare --defines and --graph as
> options with optional arguments.
> 
> Seems we need to declare that bison must be rev 1.30 or later.


If you want to go that way: %lex-param and %parse-param need 1.75b or 
later.

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/29/2010 4:51 PM, Stefan Fritsch wrote:
> 
> Your version is a bit old:
> 
> I am not really a bison/flex expert and have no idea which features 
> have been introduced in which version.

	2001-09-18  Marc Autret  <au...@epita.fr>

	* src/getargs.c (longopts): Declare --defines and --graph as options
	with optional arguments.

Seems we need to declare that bison must be rev 1.30 or later.

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 30 September 2010, Rainer Jung wrote:
> On 30.09.2010 11:08, Stefan Fritsch wrote:
> > On Thursday 30 September 2010, Rainer Jung wrote:
> >> On 30.09.2010 10:24, Stefan Fritsch wrote:
> >>> On Thursday 30 September 2010, William A. Rowe Jr. wrote:
> >>>> On 9/29/2010 6:49 PM, Guenter Knauf wrote:
> >>>>> Am 30.09.2010 01:17, schrieb Guenter Knauf:
> >>>>>> a touch would probably do ... - if not I will face same for
> >>>>>> NetWare ...
> >>>>> 
> >>>>> just checked, and beside some new prototype warnings:
> >>>>> Compiling ssl_expr_scan.c
> >>>>> ### mwccnlm Compiler:
> >>>>> #    File: ssl_expr_scan.c
> >>>>> # ------------------------
> >>>>> #    2066:  {
> >>>>> # Warning:  ^
> >>>>> #   function has no prototype
> >>>>> ### mwccnlm Compiler:
> >>>>> #    2142:  {
> >>>>> # Warning:  ^
> >>>>> #   function has no prototype
> >>> 
> >>> No, those are the ones I mentioned in the commit log. They
> >>> appear with gcc, too:
> >>> 
> >>> ssl_expr_scan.c:2065: warning: no previous prototype for
> >>> 'ssl_expr_yyget_column'
> >>> ssl_expr_scan.c:2141: warning: no previous prototype for
> >>> 'ssl_expr_yyset_column'
> >>> 
> >>> If someone has a the latest Fedora and can regenerate the file,
> >>> that would probably fix it. Otherwise it will have to wait
> >>> until the fixed flex is in Debian, I am too lazy to install a
> >>> new flex from source for just too warnings.
> >> 
> >> Do you have a pointer to the flex source code you want to be
> >> used? I build the toolchain for myself on Solaris, so I can
> >> easily update from 2.5.35 to some custom version to do this
> >> test.
> > 
> > That would be nice. There is no official release, yet, but this
> > bug report has a patch:
> > 
> > http://sourceforge.net/tracker/?func=detail&aid=3029024&group_id=
> > 97492&atid=618177
> > 
> > (I have read somewhere that Fedora has included the patch)
> 
> I also get the warning (only when using "-Wmissing-prototypes", the
> flag "-Wall" didn't produce the warning) for the original file.
> 
> I rebuilt flex with the above patch (original flex 2.5.35, no other
> patch) and regenerated the file. No more warning and two additional
> prototypes are there:
> 
> +int ssl_expr_yyget_column  (yyscan_t yyscanner );
> +
> +void ssl_expr_yyset_column (int column_no ,yyscan_t yyscanner );
> +
> 
> The full diff is available at:
> 
> http://people.apache.org/~rjung/patches/patched-flex-ssl_expr_scan_
> c.patch
> 
> Unfortunately it looks like my flex plus one patch also changes
> other stuff, which looks more correct in your version, likely
> because your flex already contains other pathces (the original
> version 2.5.35 is already about 2 years old, but there is no more
> recent official release).
> 
> So I'm not sure, what we should check in. I'd say leave as if, as
> results will vary depending on the system the RM uses and the
> missing prototype warnings are not too bad.

Thanks for trying. I agree that we should leave it as it is for the 
time being.

> I also rebuild ssl_expr_parse.(c|h) with bison 2.4.2 I had at hand.
> Latest would be 2.4.3. The header file does not contain any
> relevant difference. The source files does have some differences
> in the macro use.
> 
> Full diff here:
> 
> http://people.apache.org/~rjung/patches/bison-2_4_2-ssl_expr_parse.
> patch
> 
> Finally: I tweaked the Makefile a bit to allowe out of tree use of
> the flex and bison targets (r1003061). There is still an open
> point for me:
> 
> at the moment when doing an out of tree build and when the
> timestamps are not right, the targets generate the new source and
> header files in the build directory, not the source directory. At
> least when I tested it, those win, so the compiled code uses the
> right ones without overriding the original ones. Is that like we
> want it, or do we actually want to regenerate in the source
> directory?

I think if one builds out of tree, one does not want the real source 
directories to be modified. So the current behaviour seems fine to me.

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Rainer Jung <ra...@kippdata.de>.
On 30.09.2010 11:08, Stefan Fritsch wrote:
> On Thursday 30 September 2010, Rainer Jung wrote:
>> On 30.09.2010 10:24, Stefan Fritsch wrote:
>>> On Thursday 30 September 2010, William A. Rowe Jr. wrote:
>>>> On 9/29/2010 6:49 PM, Guenter Knauf wrote:
>>>>> Am 30.09.2010 01:17, schrieb Guenter Knauf:
>>>>>> a touch would probably do ... - if not I will face same for
>>>>>> NetWare ...
>>>>>
>>>>> just checked, and beside some new prototype warnings:
>>>>> Compiling ssl_expr_scan.c
>>>>> ### mwccnlm Compiler:
>>>>> #    File: ssl_expr_scan.c
>>>>> # ------------------------
>>>>> #    2066:  {
>>>>> # Warning:  ^
>>>>> #   function has no prototype
>>>>> ### mwccnlm Compiler:
>>>>> #    2142:  {
>>>>> # Warning:  ^
>>>>> #   function has no prototype
>>>
>>> No, those are the ones I mentioned in the commit log. They appear
>>> with gcc, too:
>>>
>>> ssl_expr_scan.c:2065: warning: no previous prototype for
>>> 'ssl_expr_yyget_column'
>>> ssl_expr_scan.c:2141: warning: no previous prototype for
>>> 'ssl_expr_yyset_column'
>>>
>>> If someone has a the latest Fedora and can regenerate the file,
>>> that would probably fix it. Otherwise it will have to wait until
>>> the fixed flex is in Debian, I am too lazy to install a new flex
>>> from source for just too warnings.
>>
>> Do you have a pointer to the flex source code you want to be used?
>> I build the toolchain for myself on Solaris, so I can easily
>> update from 2.5.35 to some custom version to do this test.
>
> That would be nice. There is no official release, yet, but this bug
> report has a patch:
>
> http://sourceforge.net/tracker/?func=detail&aid=3029024&group_id=97492&atid=618177
>
> (I have read somewhere that Fedora has included the patch)

I also get the warning (only when using "-Wmissing-prototypes", the flag 
"-Wall" didn't produce the warning) for the original file.

I rebuilt flex with the above patch (original flex 2.5.35, no other 
patch) and regenerated the file. No more warning and two additional 
prototypes are there:

+int ssl_expr_yyget_column  (yyscan_t yyscanner );
+
+void ssl_expr_yyset_column (int column_no ,yyscan_t yyscanner );
+

The full diff is available at:

http://people.apache.org/~rjung/patches/patched-flex-ssl_expr_scan_c.patch

Unfortunately it looks like my flex plus one patch also changes other 
stuff, which looks more correct in your version, likely because your 
flex already contains other pathces (the original version 2.5.35 is 
already about 2 years old, but there is no more recent official release).

So I'm not sure, what we should check in. I'd say leave as if, as 
results will vary depending on the system the RM uses and the missing 
prototype warnings are not too bad.

I also rebuild ssl_expr_parse.(c|h) with bison 2.4.2 I had at hand. 
Latest would be 2.4.3. The header file does not contain any relevant 
difference. The source files does have some differences in the macro use.

Full diff here:

http://people.apache.org/~rjung/patches/bison-2_4_2-ssl_expr_parse.patch

Finally: I tweaked the Makefile a bit to allowe out of tree use of the 
flex and bison targets (r1003061). There is still an open point for me:

at the moment when doing an out of tree build and when the timestamps 
are not right, the targets generate the new source and header files in 
the build directory, not the source directory. At least when I tested 
it, those win, so the compiled code uses the right ones without 
overriding the original ones. Is that like we want it, or do we actually 
want to regenerate in the source directory?

Regards,

Rainer

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 30 September 2010, Rainer Jung wrote:
> On 30.09.2010 10:24, Stefan Fritsch wrote:
> > On Thursday 30 September 2010, William A. Rowe Jr. wrote:
> >> On 9/29/2010 6:49 PM, Guenter Knauf wrote:
> >>> Am 30.09.2010 01:17, schrieb Guenter Knauf:
> >>>> a touch would probably do ... - if not I will face same for
> >>>> NetWare ...
> >>> 
> >>> just checked, and beside some new prototype warnings:
> >>> Compiling ssl_expr_scan.c
> >>> ### mwccnlm Compiler:
> >>> #    File: ssl_expr_scan.c
> >>> # ------------------------
> >>> #    2066:  {
> >>> # Warning:  ^
> >>> #   function has no prototype
> >>> ### mwccnlm Compiler:
> >>> #    2142:  {
> >>> # Warning:  ^
> >>> #   function has no prototype
> > 
> > No, those are the ones I mentioned in the commit log. They appear
> > with gcc, too:
> > 
> > ssl_expr_scan.c:2065: warning: no previous prototype for
> > 'ssl_expr_yyget_column'
> > ssl_expr_scan.c:2141: warning: no previous prototype for
> > 'ssl_expr_yyset_column'
> > 
> > If someone has a the latest Fedora and can regenerate the file,
> > that would probably fix it. Otherwise it will have to wait until
> > the fixed flex is in Debian, I am too lazy to install a new flex
> > from source for just too warnings.
> 
> Do you have a pointer to the flex source code you want to be used?
> I build the toolchain for myself on Solaris, so I can easily
> update from 2.5.35 to some custom version to do this test.

That would be nice. There is no official release, yet, but this bug 
report has a patch:

http://sourceforge.net/tracker/?func=detail&aid=3029024&group_id=97492&atid=618177

(I have read somewhere that Fedora has included the patch)

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Rainer Jung <ra...@kippdata.de>.
On 30.09.2010 10:24, Stefan Fritsch wrote:
> On Thursday 30 September 2010, William A. Rowe Jr. wrote:
>> On 9/29/2010 6:49 PM, Guenter Knauf wrote:
>>> Am 30.09.2010 01:17, schrieb Guenter Knauf:
>>>> a touch would probably do ... - if not I will face same for
>>>> NetWare ...
>>>
>>> just checked, and beside some new prototype warnings:
>>> Compiling ssl_expr_scan.c
>>> ### mwccnlm Compiler:
>>> #    File: ssl_expr_scan.c
>>> # ------------------------
>>> #    2066:  {
>>> # Warning:  ^
>>> #   function has no prototype
>>> ### mwccnlm Compiler:
>>> #    2142:  {
>>> # Warning:  ^
>>> #   function has no prototype
>
> No, those are the ones I mentioned in the commit log. They appear with
> gcc, too:
>
> ssl_expr_scan.c:2065: warning: no previous prototype for
> 'ssl_expr_yyget_column'
> ssl_expr_scan.c:2141: warning: no previous prototype for
> 'ssl_expr_yyset_column'
>
> If someone has a the latest Fedora and can regenerate the file, that
> would probably fix it. Otherwise it will have to wait until the fixed
> flex is in Debian, I am too lazy to install a new flex from source for
> just too warnings.

Do you have a pointer to the flex source code you want to be used? I 
build the toolchain for myself on Solaris, so I can easily update from 
2.5.35 to some custom version to do this test.

Regards,

Rainer

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 30 September 2010, William A. Rowe Jr. wrote:
> On 9/29/2010 6:49 PM, Guenter Knauf wrote:
> > Am 30.09.2010 01:17, schrieb Guenter Knauf:
> >> a touch would probably do ... - if not I will face same for
> >> NetWare ...
> > 
> > just checked, and beside some new prototype warnings:
> > Compiling ssl_expr_scan.c
> > ### mwccnlm Compiler:
> > #    File: ssl_expr_scan.c
> > # ------------------------
> > #    2066:  {
> > # Warning:  ^
> > #   function has no prototype
> > ### mwccnlm Compiler:
> > #    2142:  {
> > # Warning:  ^
> > #   function has no prototype

No, those are the ones I mentioned in the commit log. They appear with 
gcc, too:

ssl_expr_scan.c:2065: warning: no previous prototype for 
'ssl_expr_yyget_column'
ssl_expr_scan.c:2141: warning: no previous prototype for 
'ssl_expr_yyset_column'

If someone has a the latest Fedora and can regenerate the file, that 
would probably fix it. Otherwise it will have to wait until the fixed 
flex is in Debian, I am too lazy to install a new flex from source for 
just too warnings.

> Those are the malloc free namespace collisions?

Can you expand on this? It should be possible to rewrite 
yyalloc/yyrealloc/yyfree in terms of apr_palloc, but I didn't think it 
was worth the effort. Do you think that would help you?

> > it compiles fine for NetWare. We have this in our NWGNUmakefile:
> Cool - we are broken on Win32 by the include unistd.h, dunno about
> OS2.

There is a flex option for that. Please try if this patch helps:
http://people.apache.org/~sf/flex-no-unistd.diff


Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Guenter Knauf <fu...@apache.org>.
Am 30.09.2010 02:06, schrieb William A. Rowe Jr.:
> Those are the malloc free namespace collisions?
not looked at yet.

> Cool - we are broken on Win32 by the include unistd.h, dunno about OS2.
AFAIK both native compile with Watcom as well as EMX have unistd.h.

Gün.



Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/29/2010 6:49 PM, Guenter Knauf wrote:
> Am 30.09.2010 01:17, schrieb Guenter Knauf:
>> a touch would probably do ... - if not I will face same for NetWare ...
> just checked, and beside some new prototype warnings:
> Compiling ssl_expr_scan.c
> ### mwccnlm Compiler:
> #    File: ssl_expr_scan.c
> # ------------------------
> #    2066:  {
> # Warning:  ^
> #   function has no prototype
> ### mwccnlm Compiler:
> #    2142:  {
> # Warning:  ^
> #   function has no prototype

Those are the malloc free namespace collisions?

> it compiles fine for NetWare. We have this in our NWGNUmakefile:

Cool - we are broken on Win32 by the include unistd.h, dunno about OS2.



Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Guenter Knauf <fu...@apache.org>.
Am 30.09.2010 01:17, schrieb Guenter Knauf:
> a touch would probably do ... - if not I will face same for NetWare ...
just checked, and beside some new prototype warnings:
Compiling ssl_expr_scan.c
### mwccnlm Compiler:
#    File: ssl_expr_scan.c
# ------------------------
#    2066:  {
# Warning:  ^
#   function has no prototype
### mwccnlm Compiler:
#    2142:  {
# Warning:  ^
#   function has no prototype

it compiles fine for NetWare. We have this in our NWGNUmakefile:

# Make sure that the build doesn't attempt to regenerate the shipping files.
# This requires a 'touch' utility.  Can be downloaded from 'coreutils' at
#  http://sourceforge.net/projects/gnuwin32/
ssl_expr_parse.h : ssl_expr_parse.y
	touch ssl_expr_parse.h
ssl_expr_parse.c : ssl_expr_parse.y
	touch ssl_expr_parse.c
ssl_expr_scan.c : ssl_expr_scan.l
	touch ssl_expr_scan.c

Gün.



Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Guenter Knauf <fu...@apache.org>.
Am 30.09.2010 00:15, schrieb William A. Rowe Jr.:
> On 9/29/2010 4:51 PM, Stefan Fritsch wrote:
>>
>> Maybe you just need to run buildconf once to fix the timestamps?
>
> on Win32?  ;-P
a touch would probably do ... - if not I will face same for NetWare ...

Gün.



Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/29/2010 4:51 PM, Stefan Fritsch wrote:
> 
> Maybe you just need to run buildconf once to fix the timestamps?

on Win32?  ;-P


Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 29 September 2010, William A. Rowe Jr. wrote:
> On 9/29/2010 4:31 PM, William A. Rowe Jr. wrote:
> > Working to catch up the win32 build change here...

I am not sure you need to care about that. See below

> > You just invalidated some arbitrary versions of bison (testing on
> > 1.28)... "option `--defines' doesn't allow an argument"
> > 
> > Should we be testing for a baseline rev of bison which is
> > acceptable?

Your version is a bit old:

        2001-09-07  Akim Demaille  <ak...@epita.fr>

        Version 1.29.

I am not really a bison/flex expert and have no idea which features 
have been introduced in which version. I know it works with 2.4.1, 
therefore I would say the required baseline is 2.4.0. And it should 
not matter much, since ...

> For that matter... should we simply move this to buildconf?

... normally bison/flex is not executed at all during a build. 
Buildconf (at least on unix) takes care that the timestamps are set so 
that make thinks the files are up to date. And the generated files are 
included in httpd. People who are not hacking on the .y/.l files 
should not need to care about bison and flex.

Maybe you just need to run buildconf once to fix the timestamps?

Re: svn commit: r1002824 [1/4] - in /httpd/httpd/trunk: ./ modules/ssl/

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/29/2010 4:31 PM, William A. Rowe Jr. wrote:
> Working to catch up the win32 build change here...
> 
>> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/Makefile.in?rev=1002824&r1=1002823&r2=1002824&view=diff
>> ==============================================================================
>> --- httpd/httpd/trunk/modules/ssl/Makefile.in (original)
>> +++ httpd/httpd/trunk/modules/ssl/Makefile.in Wed Sep 29 19:42:03 2010
>> @@ -25,15 +25,13 @@ include $(top_srcdir)/build/special.mk
>>  #
>>  
>>  ssl_expr_scan.c: $(top_srcdir)/modules/ssl/ssl_expr_scan.l ssl_expr_parse.h
>> -	flex -Pssl_expr_yy -s -B $(top_srcdir)/modules/ssl/ssl_expr_scan.l
>> -	sed -e '/$$Header:/d' -e "s|\"`pwd`/|\"|g" <lex.ssl_expr_yy.c >ssl_expr_scan.c && rm -f lex.ssl_expr_yy.c
>> +	flex -Pssl_expr_yy -o ssl_expr_scan.c ssl_expr_scan.l
>> +	mv ssl_expr_scan.c ssl_expr_scan.c.tmp
>> +	sed -e "s|\"`pwd`/|\"|g" <ssl_expr_scan.c.tmp >ssl_expr_scan.c
>> +	rm -f ssl_expr_scan.c.tmp
>>  
>>  ssl_expr_parse.c ssl_expr_parse.h: $(top_srcdir)/modules/ssl/ssl_expr_parse.y
>> -	yacc -d $(top_srcdir)/modules/ssl/ssl_expr_parse.y
>> -	sed -e 's;yy;ssl_expr_yy;g' \
>> -	    -e "s|\"`pwd`/|\"|g" \
>> -	    -e '/#if defined(c_plusplus) || defined(__cplusplus)/,/#endif/d' \
>> -	    <y.tab.c >ssl_expr_parse.c && rm -f y.tab.c
>> -	sed -e 's;yy;ssl_expr_yy;g' \
>> -	    <y.tab.h >ssl_expr_parse.h && rm -f y.tab.h
>> -
>> +	bison -pssl_expr_yy --defines=ssl_expr_parse.h -o ssl_expr_parse.c ssl_expr_parse.y
>> +	mv ssl_expr_parse.c ssl_expr_parse.c.tmp
>> +	sed -e "s|\"`pwd`/|\"|g" < ssl_expr_parse.c.tmp > ssl_expr_parse.c
>> +	rm -f ssl_expr_parse.c.tmp
>>
> 
> You just invalidated some arbitrary versions of bison (testing on 1.28)...
> "option `--defines' doesn't allow an argument"
> 
> Should we be testing for a baseline rev of bison which is acceptable?

For that matter... should we simply move this to buildconf?