[Mapserver-dev] Force Freetype1 problem, suggested change
jgwinnup at mbvlab.wpafb.af.mil
Wed Feb 5 09:23:12 EST 2003
One thing that you gain from the automake approach is automating/fixing
the install path bug - e.g. files want to be installed in /usr/local
instead of the directory specified in --prefix= .
Another way this may be useful - it allows us to easily build libmap as
a shared library (via automake's libtool support).
The file syntax is very easy. I'll email my working Makefile.am and
configure.in for your perusal. Anyone else interested, please email me
and I'll send them to you.
This isn't perfect (or done) but I think it addresses a couple issues
some people have building the software. The larger question is: Does it
make sense to totally disrupt the current Unix build process.
On Tue, 2003-02-04 at 16:36, Daniel Morissette wrote:
> Jeremy Gwinnup wrote:
> > I saw someone suggesting changes to the configure.in script - Is there any
> > interest in converting the build script to use both Automake and Autoconf
> > to build the package on the Unix side? I've made a rudimentary attempt at
> > it, but it needs work. Let me know if anyone's interested in this.
> Can you please describe the benefits that Automake would bring relative
> to the current approach which is based purely on Autoconf and Makefile
> BTW I agree that the current configure scripts and Makefiles aren't as
> clean as they could be and could use some work (my bad in big part), so
> if you know some ways to make them work better in some conditions where
> they currently fail then your help would be welcome for sure. I would
> also be open to seeing everything being replaced by a new system as long
> as you can demonstrate that there is a benefit to making the switch, and
> that you are prepared to support the new scripts and Makefiles at least
> until they're proven to be as stable as the old ones.
Jeremy Gwinnup <jgwinnup at mbvlab.wpafb.af.mil>
More information about the mapserver-dev