Ethereal-cvs: [Ethereal-cvs] cvs commit: ethereal/epan Makefile.am

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 17 Jan 2001 00:13:40 -0600 (CST)
guy         2001/01/17 00:13:40 CST

  Modified files:
    epan                 Makefile.am 
  Log:
  Automake 1.4b (which is actually a test version of 1.5, i.e. of a
  *future* version, not of 1.4, which is the *current* version - i.e.,
  it's newer than 1.4) complains, if "dfilter-grammar.c" and
  "dfilter-scanner.c" are part of "EXTRA_libethereal_a_SOURCES", that
  "dfilter-grammar.o" is built both from "dfilter-grammar.c" and
  "dfilter-grammar.y", and that "dfilter-scanner.o" is built both from
  "dfilter-scanner.c" and "dfilter-scanner.l", and refuses to build
  "Makefile.in".
  
  Moving them to "EXTRA_DIST" makes 1.4b happy.
  
  Automake 1.4 allows them either to be in "EXTRA_libethereal_a_SOURCES"
  or in "EXTRA_DIST"; the only difference between the generated
  "Makefile.in" files is which of those two variables the files are in,
  and the only difference that makes is that it keeps those two files out
  of "SOURCES", which means that "make ID" doesn't include them in the
  files it looks at, and "make TAGS" and "make tags" don't include them in
  the files they look at.  I'm not sure whether the tags file should be
  built from "dfilter-grammar.y" and "dfilter-scanner.l", or from
  "dfilter-grammar.c" and "dfilter-scanner.c"; the former means you see
  the real source file, not the generated source file, if you look for a
  symbol defined in one of those files, while the latter means you can
  look for symbols in code generated by YACC/Bison or Flex.
  
  In either case, the generated files go into the distribution tarball,
  which is what we want.
  
  For now, we go with what makes Automake 1.4b happy.
  
  Revision  Changes    Path
  1.15      +4 -4      ethereal/epan/Makefile.am