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

[m. allan noah]

On Mon, Jan 12, 2009 at 9:32 AM, Chris Bagwell <chris at cnpbagwell.com> wrote:
> m. allan noah wrote:
>>
>> On Sun, Jan 11, 2009 at 9:01 PM, Chris Bagwell <chris at cnpbagwell.com>
>> wrote:
>>
>>>
>>> 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
>>
>
> All three should be equally portable.  Option #3 would run 'sed' and 'sort'
> but existing Makefile.in is already using 'sed' so should not be any issues
> in enhancing the "dist" target to support paths.
>
> Option #2 should also be equally portable.  I have experience in other
> projects that use automake on linux, various BSD's, OS/2, cygwin, Mac OS X,
> and a lot of fringe OS's like Atari and DOS. No issues found... All issues
> I've had revolve around libtool's behavior and not automake itself.
>
> I remember being uncomfortable the first time a project I worked with
> switched to automake but it turned out for the best.  If you guys are game
> for it, I'll be happy to do the conversion.
>
> I'll try to give you a feel for how automake makes things easier to read.  I
> think the toplevel Makefile.in would convert to the following for
> Makefile.am (untested but should be close).  Its pretty easy to convert over
> because the sane Makefile.in's are already very automake-ish for what ever
> reason.
> autoreconf converts Makefile.am into Makefile.in that looks very much like
> todays Makefile.in but with some additional useful targets and maybe
> slightly enhanced versions of existing targets (like dist and install can
> install filenames with directory names on them).  Then Makefile.in gets
> converted to Makefile in same step as today.
>
> Basically, automake takes care of defining all your standard variables like
> $prefix and all your standard targets like install/uninstall, install-man,
> dist, clean, depend, ctags/etags, and so on. Then we can just worry about
> the project specific stuff.  The backend/Makefile.am would be much more
> interesting example to see and show better benefit but it would take me a
> couple of hours to prototype it so would like some feedback first (so not to
> waste precious time :-) ).
> Also, notice any Autotool's related files are automatically track so do not
> need to be manually listed any more.

You (and others on this list) have more experience with these tools
than I, so I am willing to defer to your judgement. But watch out for
the sane-specific copy of libtool. We have some hacks in there to make
each sane backend's .so export symbols so that it can be linked
directly.

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