[MINC-development] AX_CHECK_GL and friends

[Steve M. Robbins]

On Fri, Apr 01, 2005 at 10:22:32PM +1000, Andrew Janke wrote:
> On Apr 1, 2005 5:11 PM, Steve M. Robbins <steven.robbins@videotron.ca> wrote:
> > 
> > > I found [missing macros] in the autoconf macro archive and can now
> > > build Display.
> 
> Given that these macros are in the acmacros package/distribution, I
> had figured it best to not include them in case they were updated or
> the likes.

I hadn't realized that someone has packaged the autoconf archive.  

Oh, wait! ... Actually I guess I did know, since I see that it's
installed here (Debian package autoconf-archive).


> Would you still reccomend including a static version of them with
> Display/Register/etc?  Myself I'd prefer to use as much of what is
> "out there" as opposed to rolling our own all the time?

I agree wholeheartedly to use existing macros.  But how do you make it
easy for developers?

If it were a simple matter of "install package autoconf-archive"
before running aclocal (or autogen.sh), I could live with that.  This
should be documented in BIG BOLD letters in INSTALL.display because
if you do NOT have the appropriate macro files the configure
script can still be generated, apparently "successful", but the
script is, in fact, broken and Display will fail to link.

However, on my Debian system "aclocal" doesn't search the
autoconf-archive macros by default, so autogen.sh is broken.  I would
have to run aclocal by hand with an extra "-I" option.  (Is that what
you did?)

Alternatively, I could first copy or link the macro files into the m4
directory.  But then why not do this once and put it into CVS?  Macros
smr_WITH_BUILD_PATH.m4 and mni_cxx_have_koenig_lookup.m4, to name two,
are already part of the autoconf archive and also in our CVS tree.

The second reason to put them into CVS is that we then have control
over what appears in the the source distribution.  Imagine that you've
tweaked the configure script to build on OSX while using the newest
AX_CHECK_GL.  But suppose I have an older autoconf-archive installed
here and generate the source tarball from a broken AX_CHECK_GL macro.
You'll tear your hair out tracking down these bugs.  Better to put the
macros in CVS to ensure we're all working from the same sources.


> I had heard on the grapevine that bert had a imagemagick version of
> bicpl and have been eagerly awaiting that instead.  Reason being I
> haven't (yet) been able to build bicpl using ppm on the mac yet. :(

Odd; I would have expected PPM to build easily on the mac.  
What's the problem?

But if your bicpl doesn't link with an image library, at least this
explains why you didn't encounter the link problem with Display.


> I suspect there will be more subtle changes soon to Display/register
> for the upcoming binary mingw/cygwin builds (soon, soon).  So, do you
> prefer to add libtool back in or shall I? And if you do, can you test
> the build on OSX too please?

I will put it back.  But I don't have access to an OSX machine,
so I can't test it.  Sorry.

-Steve