Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[Mathieu Lirzin]

NightStrike <address@hidden> writes:

> On Mar 7, 2018 16:05, "Mathieu Lirzin" <address@hidden> wrote:
>
>  John Calcote <address@hidden> writes:
>
>  > A Makefile.am file is really just a Makefile with embellishments. It seems
>  > like your ast would have to incorporate most of make’s syntax to work
>  > correctly.
>  >
>  > The reason Perl was chosen to begin with is because of its great text
>  > processing capabilities as, ultimately, all automake really does is copy
>  > the file directly to the output Makefile.in file, filtering out automake
>  > stuff along the way and injecting make snippets generated from the automake
>  > constructs.
>  >
>  > This may not appear obvious at first because many simpler Makefile.am files
>  > contain only automake stuff. But anything found in the Makefile.am file
>  > that automake doesn’t recognize is assumed to be proper make script and
>  > copied directly to the output file.
>  >
>  > I suggest making your ast handle non automake chunks as a specific token
>  > type designed to be passed through without modifications.
>
>  I agree that using a coarse grained AST is a good first approach.
>  Exploration and evaluation of a finer grained approach later during this
>  GSoC could be interesting too.
>
>  Thanks for your input.
>
> What problem does the AST solve? 

The main one I see is the potential modularity and performant
testability it brings.  Checking some properties in an in-memory tree
data structure instead of reading a file has generally better
performance.  While this performance gain is not important in an
practical interactive usage of 'automake', the benefit will be
significative for the test-suite runtime assuming that most functional
tests are rewritten as unit tests.

Using an AST is not the only possible approach to achieve this goal of
having an in-memory data structure for the tests.  However the AST
approach is generally considered a better design for syntax/semantic
analysis than having a couple of streams of character combined with a
set of global variables.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37