Perrog wrote:
> 2007/2/28, Bob Proulx <[EMAIL PROTECTED]>:
> >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
