bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10154: ylwrap error:


From: Stefano Lattarini
Subject: bug#10154: ylwrap error:
Date: Thu, 1 Dec 2011 12:35:58 +0100
User-agent: KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; )

On Monday 28 November 2011, Joe Chen wrote:
> On Mon, Nov 28, 2011 at 12:32 PM, Stefano Lattarini
> >
> > On Monday 28 November 2011, Joe Chen wrote:
> >>
> >> I am using automake for compile flex input file.  The flex command
> >> line option --prefix=<STRING> or -P<STRING> works with the direct
> >> invoking of flex, buy ylwrap gets error all the time for me:
> >>
> >> /bin/bash ../build-aux/ylwrap configf_lexer.l lex.yy.c configf_lexer.c
> >> -- flex  --case-insensitive --prefix=configf_yy
> >> make[4]: *** [configf_lexer.c] Error 1
> >>
> >>
> >> Is this a known issue?
> >>
> > This is not an issue in ylwrap, but rather and usage error.  Let's see
> > again the help screen from ylwrap:
> >
> >  Usage: ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
> >
> >  Wrapper for lex/yacc invocations, renaming files as desired.
> >
> >   INPUT is the input file
> >   OUTPUT is one file PROG generates
> >   DESIRED is the file we actually want instead of OUTPUT
> >   PROGRAM is program to run
> >   ARGS are passed to PROG
> >
> >  Any number of OUTPUT,DESIRED pairs may be used.
> >
> > This suggests that, instead of using `--prefix' to modify the name of
> > the generated `.c' file, you should simply use the DESIRED argument:
> >
> >  ylwrap configf_lexer.l lex.yy.c configf_lexer.c \
> >        -- flex --case-insensitive
> >
> > Or, if you have other reasons to want to stick with the `--prefix'
> > option (whose exact effects and semantics I don't pretend to know),
> > you must inform `ylwrap' of the different expected OUTPUT filename:
> >
> >  ylwrap configf_lexer.l lex.configf_yy.c configf_lexer.c \
> >        -- flex --case-insensitive --prefix=configf_yy
> 
> THANKS! This format of ylwrap no longer gets the error, and works for
> my purpose:
> >  ylwrap configf_lexer.l lex.configf_yy.c configf_lexer.c \
> >          -- flex --case-insensitive --prefix=configf_yy
> Could you point to me how to compose my files of "configure.ac" and/or
> "Makefile.am" to let "ylwrap" takes the exact OUTPUT and DESIRED that
> I want?
>
The simpler way I can think of is to provide, in your Makefile.am,
hand-written rules to build `.c' files from your `.l' files, and to
distribute said `.l' files explicitly; something like this perhaps
(warning: untested!):

  configf_lexer.c: configf_lexer.l
        $(SHELL) $(top_srcdir)/ylwrap \
          configf_lexer.l lex.configf_yy.c configf_lexer.c \
          -- $(LEX) $(LFLAGS) --case-insensitive --prefix=configf_yy

  EXTRA_DIST = ... configf_lexer.l ...

  bin_PROGRAMS = foo
  foo_SOURCES = main.c ... configf_lexer.c ...

Still, note that the main purpose of `ylwrap' is to allow parallel builds
when multiple `.l' files are to be processed in the same Makefile; but if
you follow the route of requiring flex and ensuring that the output files
for different `.l' files all have different names, you can dispense with
the use of ylwrap altogether, as in (again, warning: untested!):

  configf_lexer.c: configf_lexer.l
        $(LEX) $(LFLAGS) --case-insensitive --prefix=configf_yy \
        --output configf_lexer.c configf_lexer.l

  EXTRA_DIST = ... configf_lexer.l ...

  bin_PROGRAMS = foo
  foo_SOURCES = main.c ... configf_lexer.c ...

> Very often, I have multiple pairs of *.y and *.l files to be linked
> together and this --prefix=<STRING> makes it possible.  And thus I
> have a need to flexibly specify the OUTPUT and DESIRED as needed.
> 
> BTW, --prefix=<STRING> lets flex to generate "<STRING>text" in place
> of "yytext" in the generated file.
> 
Ah, ok, now I see why you want to use the `--prefix' option.  But it
looks strange that this option also changes the name of the default
output file ...  There isn't a way to avoid this?  If yes, you won't
have to use the workarounds I described above, but will be able to
just rely on the automake-provided Lex support.

Regards,
  Stefano





reply via email to

[Prev in Thread] Current Thread [Next in Thread]