Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

[Zack Weinberg]

On Thu, Jul 16, 2020 at 1:55 PM Ross Burton <ross@burtonini.com> wrote:
> On Thu, 16 Jul 2020 at 18:51, Paul Eggert <eggert@cs.ucla.edu> wrote:
>>
>> On 7/16/20 10:34 AM, Ross Burton wrote:
>> > Wouldn't that break cross-compilation where a host flex is present but
>> > target libfl isn't?  That case worked previously and should work fine,
>> > as libfl isn't actually that useful.
>>
>> That shouldn't be a problem when building from tarballs, as flex shouldn't be
>> needed then and the patch is a win because it prevents the build from failing
>> unnecessarily. However, it could be a problem when building from Git
>> repositories where you need flex but may well not need the library.
>>
>> So I installed the attached patch, which implements Zack's first suggestion. 
>> I'm
>> being somewhat bold in installing here; feel free to comment and suggest
>> improvements (or suggest I revert :-).
>
> I suggest you revert and take my patch. :)
>
> I can’t actually find any projects that need libfl.so so this will continue 
> to break all cross compilation where a target flex isn’t around.

Can we slow down a bit please?  I had written out a patch (basically
equivalent to what's now in trunk) and I am in the process of setting
up a cross-compilation environment to validate the fix for certain,
but this is going to take several hours.

I believe that what's in trunk now should work fine for
cross-compilation of programs that don't require yywrap, even if there
is no target libfl, even for source tarballs that don't ship lex.yy.c,
as long as the flex program is available in the build environment.  If
that's not the scenario you're talking about, Ross, please clarify,
but I don't see how a tarball that doesn't ship the generated scanner
could ever have worked with no flex at all.

zw