automake
[Top][All Lists]
Advanced

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

Fwd: Integrating flexc++(1) and bisonc++(1) into Makefile.am


From: Diab Jerius
Subject: Fwd: Integrating flexc++(1) and bisonc++(1) into Makefile.am
Date: Wed, 12 Jul 2017 11:55:40 -0400

---------- Forwarded message ----------
From: Diab Jerius <address@hidden>
Date: Wed, Jul 12, 2017 at 10:44 AM
Subject: Re: Integrating flexc++(1) and bisonc++(1) into Makefile.am
To: Kip Warner <address@hidden>


On Wed, Jul 12, 2017 at 12:13 AM, Kip Warner <address@hidden> wrote:
> Hey list,
>
> I'm aware autoconf has M4 macros for traditional GNU flex(1) and
> bison(1) implementations of POSIX lex(1) and yacc(1) respectively. I'm
> also aware the manual contains information for integrating the two into
> a typical autotool'd build environment.
>
> My challenge is replicating their functionality for flexc++(1) and
> bisonc++(1) in the absense of macros to make their usage easier in
> Automake. These are C++ generators for a lexer and parser, analogous to
> their C counterparts. Some of the available tutorials online contradict
> some of the recommendations of the Autoconf / Automake documentation,
> so I figured I'd ask the gurus.
>
> What I am trying to accomplish is have Makefile.am run the two tools on
> their two respective inputs and generate their source as part of the
> build process of the rest of my project. This is normally done
> externally like so:
>
>     $ flexc++ Lexer.lpp
>     (produces LexerBase.h, Lexer.h, Lexer.ih, and LexerBase.cpp)
>
>     $ bisonc++ Parser.ypp
>     (produces ParserBase.h, Parser.h, Parser.ih, and Parser.cpp)
>
>     $ g++ Parser.cpp LexerBase.cpp Main.cpp -o MyProgram
>
> All of the generated files I consider derived for the purpose of my
> project and I don't mind if the 'clean' target removes them. I figured
> as I refine my grammar rules, the lexer and parser code will change a
> lot anyways.



Take a look at section 18.2 of the automake manual "Handling new file
extensions"

Essentially you want to tell automake to tell make that you have a
rule to create a .cpp file from a .lpp file.

As an example, here's what I have to compile Lua code

SUFFIXES += .lc .lua
AX_V_LUAC = $(address@hidden@)
AX_V_LUAC_ = $(address@hidden@)
AX_V_LUAC_0 = @echo LUAC $@;
.lua.lc :
        $(AX_V_LUAC)test "$(LUA_PATH)set" = set || export
LUA_PATH="$(LUA_PATH)" ;\
        $(LUAC) -o $@ $<

It uses the automake silent rules convention to quiet things; see
section 21.3 "How Automake can help in silencing make"

It doesn't work with the automake subdir-objects option; I'm trying to
figure out why.








> In trying to integrate the two tools into my build environment, I've
> attempted the following in Makefile.am:
>
>     ...
>
>     BUILT_SOURCES = \
>       Source/LexerBase.h \
>       Source/Lexer.h \
>       Source/Lexer.ih \
>       Source/LexerBase.cpp \
>       Source/ParserBase.h \
>       Source/Parser.h \
>       Source/Parser.ih \
>       Source/Parser.cpp
>
>     myprogram_SOURCES = \
>       ... \
>       Source/LexerBase.cpp \
>       Source/Parser.cpp
>
>     ...
>
>     EXTRA_DIST = \
>       ... \
>       Source/Lexer.lpp \
>       Source/Parser.ypp
>
>     ...
>
>     # Generate lexer source from regular expression token descriptions via 
> flexc++...
>     Source/LexerBase.h:
>     Source/LogicLexer.h:
>     Source/LogicLexer.ih:
>     Source/LexerBase.cpp: Source/LogicLexer.lpp
>             $(FLEXCPP) --target-directory=$(top_builddir)/Source $< ; \
>             $(SED) -i '/#include "Lexer.ih"/a #include "ParserBase.h" \/\/ 
> Token declarations...' $(top_builddir)/Source/LexerBase.cpp
>
>     # Generate parser source from Backus-Naur grammar rules via bisonc++...
>     Source/ParserBase.h:
>     Source/Parser.h:
>     Source/Parser.ih:
>     Source/Parser.cpp: Source/Parser.ypp
>             $(BISONCPP) --target-directory=$(top_builddir)/Source $<
>
> FLEXCPP and BISONCPP are obtained via AC_PATH_PROG in configure.ac.
>
> This all works ok, but I suspect this is not an elegant solution and
> there are some very good suggestions from this mailing list.
>
> Yours truly,
>
> --
> Kip Warner | Senior Software Engineer
> OpenPGP signed/encrypted mail preferred
> http://www.thevertigo.com



reply via email to

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