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
