[sane-devel] How best to distribute the m4 directory?

[m. allan noah]

On Sun, Jan 11, 2009 at 9:01 PM, Chris Bagwell <chris at cnpbagwell.com> wrote:
> Hi all,
>
> I notice one of Fedora's patches against sane-backends-1.0.19.tar.gz is
> that they add back in the m4/ directory that is in CVS but not packaged
> by "make dist".  Thats because they need to rerun autoreconf to make
> some configure.in patches take affect.
>
> Since we are distributing configure.in and acinclude.m4 (which
> references m4 directory), I'm assuming we should be packaging the m4
> directories as well.  As it stands, the end user needs to stop using
> released packages and go to CVS if they make any source code changes
> that require rerunning autoreconf.

Yes- this has been on my todo list for awhile.

>
> I'd like to help resolve this issue but need some direction from
> whomever looks over the make infrastructure the most.  I see a few basic
> options.  #2 and #3 are my preferences.
>
> 1) Follow include/ directories lead and place a Makefile in m4/
> directory so that its files can be packaged up.  Not sure how autotools
> will react to that but it probably ignores anything that doesn't end in .m4.
>
> 2) Change makefiles to be built using automake tools.  It handles the
> dirty work  pretty good.  It would also simplify the Makefile logic
> quite a bit.  Current Makefile.in look very much like a hand generated
> files based on how automake would do it anyways.  Any objections to
> using automake?
>
> 3) Port over latest automake logic for DISTFILES which supports path
> names and will both create these directories and copy files.  This would
> allow adding m4/byteorder.m4 and similar to toplevel DISTFILES in
> Makefile.in and would also allow removing the unneeded Makefile from the
> include/ directory and move its work to toplevel or src/ as well.

Which of these works best on all the platforms on which SANE builds?
#1 was my original intention...

allan
-- 
"The truth is an offense, but not a sin"