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"
