automake
[Top][All Lists]
Advanced

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

Re: Wishlist: Clean target for generated C files?


From: Bob Proulx
Subject: Re: Wishlist: Clean target for generated C files?
Date: Thu, 1 Mar 2007 09:37:56 -0700
User-agent: Mutt/1.5.9i

Perrog wrote:
> 2007/2/28, Bob Proulx <address@hidden>:
> >I would really like a clean target that would remove generated source
> >files such as generated .c and .h files.  In the case of yacc and lex
> >I would like to distribute the generated files so as not to require
> >the use of yacc and lex to compile the distribution.  This rules out
> >DISTCLEANFILES or that would work.  But they are not true source and
> >so at times it is useful to delete them and rebuild them.  Such as
> >when asking the question, which version of flex works and which fails?
> 
> Do you mean having a template file with extra rules feeded to automake
> command, containing a target like CLEANDERIVED concatenated to every
> Makefile.am file. Or do you mean adding a new primitive
> _DERIVEDSOURCES to auto-makefiles with a list of intermediare/derived
> files? Or both?

I was thinking that something like the MOSTLYCLEANFILES behavior which
supports 'make mostlyclean'.  An additional MORECLEANFILES variable
supporting a 'make moreclean' target that includes MOSTLYCLEANFILES
and CLEANFILES and additionally MORECLEANFILES would be perfect.

I mentioned yacc and lex but in my case there is also a project
specific code generator that produced .c and .h files from a .d
definition file.  I was modifying the generator.  Conceptually it is
similar to yacc and lex paradigm of generated source files that
everyone knows though.

Putting the clean behavior on a scale they look like this following
with to the left being less clean and to the right being more clean.

  <-- less clean -- more clean -->
    MOSTLYCLEANFILES
        CLEANFILES
            DISTCLEANFILES
                MAINTAINERCLEANFILES

AFAICT the expected use model for mostlyclean would be for after the
build.  That would tidy up some by removing the *.o files but leave
behind *.a libraries and program binaries.  This is not as useful for
me personally but I can see where it would be useful for others.

  ./configure
  make
  make mostlyclean

What I am wishing for is something more like this.

  <-- less clean -- more clean -->
    MOSTLYCLEANFILES
        CLEANFILES
            MORECLEANFILES
                DISTCLEANFILES
                    MAINTAINERCLEANFILES

With a use model more like this somewhat stylized example.

  ./configure
  make
  make check
  ...modify code generator...
  make moreclean
  make
  make check
  ...modify code generator...
  make moreclean
  make
  make check

Certainly right now I can 'make maintainer-clean' and then bootstrap
the project again to get the same result.

  ./configure
  make
  make check
  ...modify code generator...
  make maintainer-clean
  autoreconf --install
  ./configure
  make
  make check
  ...modify code generator...
  make maintainer-clean
  autoreconf --install
  ./configure
  make
  make check
  
But then I must also autoreconf the project.  With large projects this
can be a very long amount of time.  That large time penalty is painful
when needing to be done repeatedly in the interactive development
cycle and best avoided.  And in that case I must also have all of the
autotools available on that platform to support it whereas with the
proposal only the distributed configure support is needed.

[Instead I used find and generated a list of .y and .l files and then
converted them into a list of potential .c and .h files and then
generated a script from this to remove those generated files creating
my own private moreclean functionality.  That worked but it was not as
nice as it could have been.]

Bob




reply via email to

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