On Mon, Nov 24, 2003 at 11:56:08AM -0800, Timothy M. Shead wrote:
> Tristan 'Minty' Colgate wrote:
> >>* Removed acinclude.m4. Now that the various configure macros have been
> >>moved to the m4 directory, acinclude.m4 is redundant.
> > The idea of haveing acinclude.n4 there is this. If you edit one of the
> >Makefile.am stuff the attempt of automake to rebuild the Makefile.in fails
> >because it tried to run aclocal without any args (no -I ./m4), I can't
> >out how to get it to pass an arg. With the acinclude.m4 aclocal picks up
> >the macros from there and auto building of the Makefile.in just works.
> > It basically get's rid of the need to explicitly call bootstrap after
> >touching any of the build stuff.
> > It is also partly movtivated by wanting to make it a little easier for
> > people
> >to work with the distributed tar balls, whilst it isn't neccesary to
> >this stuff it can be convenient.
> I see your point, on aclocal not having the correct args, but I think
> that this is an argument in favor of sticking with having acinclude.m4
> include all distributed macros (we don't seem to have that many,
> anyway). Regardless, copying aclocal.m4 back into acinclude.m4 is a big
> mistake, as you're taking a bunch of private implementation macros that
> are specific to your version of autotools on your system, and
> distributing them to the world. acinclude.m4 should include just those
> macros that are particular to Aqsis.
yep, agreed. The reason I preferred doing it this way was that some of the
macros we are using were not developed by us but are part of one of the macro
repositories, I would prefer keeping them all in seperate files and I thaught
cat ./m4/*.m4 > acinclude.m4
was just a bit more ugly than getting aclocal to do it for me.
If I upgrade to automake 1.7 then it becomes less of a problem, but
ultimately I think you are right, haveing any of the local .m4 macros in there
at all is not really desireable.
I'll stick the above 'cat' in bootstrap and get rid of the of -I m4 argument
to aclocal. I'll commit it a bit later tonight.
> > One thing I have had an urge to do for ages is to actually get rid of the
> >/usr/local/aqsis prefix completely. For a few internal reasons this isn't
> >asstraight forward as it could be so I haven't gotten up the courage to do
> >yet. From a packaging point of view the additional prefix is more of a pain
> >than it might first seem to be. Any comments? I noticed k3d uses it's own
> >/usr/local/k3d prefix, so my guess is that you prefer things that way.
> My argument in this regard is thus: you're never going to pick a default
> that suits every distribution, and people who are packaging the software
> for different distros are going to use the capabilities provided by
> configure to put things where they want, anyway. So the default should
> be convenient for developers. I consider "/usr/local/aqsis" to be a
> good default because it doesn't spread files across the filesystem, and
> I can zap in installation with a single "rm -rf" ... something I've been
> doing a lot in conjunction with trying to create that ebuild.
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> Aqsis-development mailing list
Tristan 'Minty' Colgate
<minty@...> | ICQ #154577755
"I don't mean to sound bitter, cold, or cruel, but
I am, so that's how it comes out"
- Bill Hicks