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

[Will Estes]

You might also have a look at the flex test suite to see various ways in which 
automake is abused to build odd things for flex itself. There's a lot of edge 
cases there and you might get ideas.

On Wednesday, 12 July 2017, 10:23 am -0400, Nick Bowler <address@hidden> wrote:

> Hello,
> 
> On 7/12/17, Kip Warner <address@hidden> wrote:
> > My challenge is replicating their functionality for flexc++(1) and
> > bisonc++(1) in the absense of macros to make their usage easier in
> > Automake
> [...]
> > In trying to integrate the two tools into my build environment, I've
> > attempted the following in Makefile.am:
> [...]
> >     BUILT_SOURCES = \
> [...]
> >       Source/ParserBase.h \
> >       Source/Parser.h \
> >       Source/Parser.ih \
> >       Source/Parser.cpp
> >
> >     myprogram_SOURCES = \
> [...]
> >       Source/Parser.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.
> 
> There aren't really any "elegant" solutions.  Make handles this kind of
> tool quite badly.  It is possible to get things to work but it is always
> a tradeoff between flexibility of your build system and simplicity of
> your rules.
> 
> If you are happy with this method then it is totally fine.  Do make
> sure parallel builds work by testing them routinely (both clean and
> incrementally) -- I think listing everything in BUILT_SOURCES like you
> do probably "resolves" any parallelism problems here, (by reducing
> opportunities for parallelism).
> 
> The Automake manual has section on writing portable make rules for tools
> that produce multiple outputs[1], with a discussion of various approaches
> and their limitations.  I generally prefer approaches using a dedicated
> witness file.
> 
> Finally, consider whether you want to distribute the generated parser
> sources.  That way your users don't need these tools installed just to
> build your package.
> 
> [1] 
> https://www.gnu.org/software/automake/manual/automake.html#Multiple-Outputs
> 
> Cheers,
>   Nick
> 

-- 
Will Estes
address@hidden