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

[Chris Bagwell]

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.

Chris

--- Makefile.am ---

SUBDIRS = include lib sanei backend frontend tools doc po
DIST_SUBDIRS = include lib sanei backend frontend tools doc po

EXTRA_DIST = AUTHORS COPYING ChangeLog ChangeLog-1.0.0 ChangeLog-1.0.1 \
  ChangeLog-1.0.2 ChangeLog-1.0.3 ChangeLog-1.0.4 ChangeLog-1.0.5 \
  ChangeLog-1.0.6 ChangeLog-1.0.7 ChangeLog-1.0.8 ChangeLog-1.0.9 \
  ChangeLog-1.0.10 ChangeLog-1.0.12 ChangeLog-1.0.13 ChangeLog-1.0.14 \
  ChangeLog-1.0.15 ChangeLog-1.0.16 ChangeLog-1.0.17 ChangeLog-1.0.18 \
  ChangeLog-1.0.19 \
  LICENSE NEWS \
  PROBLEMS PROJECTS README README.aix README.beos README.darwin 
README.djpeg \
  README.freebsd \
  README.hp-ux README.linux README.netbsd \
  README.openbsd README.os2 README.solaris README.unixware2 
README.unixware7 \
  README.windows README.zeta \
  sane-backends.lsm

$(PACKAGE)-$(VERSION).lsm: $(PACKAGE)-$(VERSION).tar.gz $(PACKAGE).lsm
        ( cat $(PACKAGE).lsm | \
         sed -e "s|_DATE_|`date +%d%b%y`|g" \
          -e "s|_VERSION_|$(VERSION)|g" \
          -e "s|_T_S_|`find $(PACKAGE)-$(VERSION).tar.gz -printf 
\"%4k\"`|g"\
          -e "s|_L_S_|`find $(PACKAGE).lsm -printf "%4k"`|g" > \
             $(PACKAGE)-$(VERSION).lsm \
        )
lsm: $(PACKAGE)-$(VERSION).lsm

#
# Keep the .cvsignore files sorted, and use this target to do it.
#
PERL=perl
sort-cvsignore:
        for f in `find . -name .cvsignore`; do \
                $(PERL) -e 'print sort <>;' < $$f > $$f.tmptmp; \
                mv $$f.tmptmp $$f; \
        done
        done
#
# Check to make sure only sane_ and sanei_ symbols are exported from
# the libraries
#
libcheck:
        @echo "Libraries exporting 'illegal' symbols:"
        @for lib in backend/.libs/*.a; do \
          lines=`nm -g $$lib|grep '\( T \)\|\( D \)'|egrep -v ' sane_| 
sanei_'`
; \
          if test -n "$$lines" ; \
          then \
            echo -e "*** $$lib:\n$$lines"; \
          fi \
        done
        @echo "Libraries exporting 'non-standard sane_*' symbols:"
        @for lib in backend/.libs/*.a; do \
          lines=`nm -g $$lib|grep '\( T \)\|\( D \)'|egrep ' sane_' | 
egrep -v '
sane_.*init|sane_.*exit|sane_.*get_devices|sane_.*open|sane_.*close|sane_.*get_o
ption_descriptor|sane_.*control_option|sane_.*get_parameters|sane_.*start|sane_.
*read|sane_.*cancel|sane_.*set_io_mode|sane_.*get_select_fd|sane_strstatus'` 
; \
          if test -n "$$lines" ; \
           then \
            echo -e "*** $$lib:\n$$lines"; \
          fi \
        done

md5: dist
        md5sum $(distdir).tar.gz > $(distdir).tar.gz.md5

# Alternative to this line to generate lsm and md5 when "make dist" is ran:
#sane-backends: dist lsm md5
dist-local: lsm md5

clean-local:
        rm -f sane-backends-*.lsm
        rm -f $(distdir).tar.gz.md5