Re: removing a source file for the dist rule

[Vincent Torri]

On Wed, 4 Nov 2009, Ralf Wildenhues wrote:

> * Vincent Torri wrote on Wed, Nov 04, 2009 at 08:05:34PM CET:
> > On Wed, 4 Nov 2009, Ralf Wildenhues wrote:
> > > * Vincent Torri wrote on Wed, Nov 04, 2009 at 07:52:17PM CET:
> > > > we have added an option to our configuration stuff that concatenates
> > > > all the source files, creates another from one from them, and
> > > > compiles it. The problem is that this new source file is
> > > > automatically added to the source files that are added in the tar
> > > > ball.
> > > >
> > > > We have modified DIST_SOURCES so that it contains only the requested
> > > > files to add in the tar ball, but automake gives a warning about
> > > > DIST_SOURCES and that variable is not described in the automake
> > > > manual (using it works, though).
> > >
> > > Can you just show a small example setup instead of complicated words
> > > to describe it?  Thanks.
> >
> > http://pastebin.ca/1657110
> >
> > It's the Makefile.am file we use and is not that big.
>
> pastebins suck a bit because somebody reading this thread some months
> down the road will not be able to see it.  Anyway.

ok, i'll not do it in the future.

> You can simply add the generated file to nodist_libeet_la_SOURCES
> instead of to libeet_la_SOURCES.

indeed. Actually, i used nodistcheck_libeet_la_SOURCES so that make 
distcheck passes too.

> If I were you, I'd replace the first half of the generated file
> eet_amalgamation.c with an
>  #include "header-for-the-big-source-file.h"
>
> and then I'd try to get my other headers to be idempotent so that you
> can replace the rest with a loop
>  for f in $(libeet_la_SOURCES); do \
>    case $$f in \
>      *.c) echo '#include "$$f"' >> $@;; \
>    esac; \
>  done

I'll check that.

> and if you don't need to cater to lots of different compiler versions,
> then I'd just use a compiler/linker that can do whole-program/link-time
> optimization (like GCC 4.5 will, and some others also do), and forget
> about this hack.

Yes, I know that gcc 4.5 will make that hack useless. But it is not 
available and will not during the next 5 months, i think (it's still in 
stage 3). As the libraries can be compiled on Windows with mingw, and as 
the mingw guys will not provide gcc 4.5 in the next 10 years, we keep it 
(but disabled by default). In addition, it speeds up the compilation with 
MSYS a *lot* (of course).

thank you very much

Vincent Torri