[asterisk-dev] autoconf issues for FreeBSD

[Tzafrir Cohen]

On Thu, Oct 05, 2006 at 12:15:33AM -0700, Luigi Rizzo wrote:
> On Wed, Oct 04, 2006 at 08:37:45PM -0500, Kevin P. Fleming wrote:
> > ----- Luigi Rizzo <rizzo at icir.org> wrote:
> > > I am pretty sure that the code below (which was my patch at the time)
> > > is NOT a proper fix - i would expect autoconf to deal with platform
> > > issues
> > > without having us deal with them on each and every port.
> > 
> > That fix probably won't work correctly any longer, since the change to use ASTCFLAGS and ASTLDFLAGS for the build system.
> 
> as russel said, here i only patched CFLAGS and LDFLAGS which is
> what the configure script uses. AST* variables were already (more
> or less) set properly.
> 
> > autoconf itself does nothing to increase platform compatibility; it is a tool that allows a package builder to increase compatibility. The benefits from autoconf are derived entirely from the logic that we put in the configure script, not autoconf itself.
> 
> i am sure this has been discussed at length many times.
> 
> I think the goal of autotools was to ease portability, both
> cross-platform and within a single platform with different packages
> installed.  Maybe for the latter, autoconf still makes sense.
> 
> But if you have to explicitly put in checks for what are platform
> defaults, the first goal is defeated.
> 
> Besides, the "failures" are often subtle - it's not that configure
> fails completely, it just gives you a suboptimal build because it
> doesn't find 8 codecs and 4 libraries and so it doesn't build the
> dependent modules.
> And it does it so noisily (currently the output of asterisk's
> configure is 332 lines!) that it is easy to miss the failures
> while the text scrolls.

Which of those are unnecessary? That is: will not fail?

Do you thin that some of them are not worth reporting?

There are probably more than a screenfull of features tested, so even a
"summary scrren" won't be really useful.

> 
> Also the choice of using "ancient greek" (pre-1977 shell) 

huh?

> as the
> language for expressing the logic in the configure script doesn't
> help correctness: e.g.  without local variables, i think macros are
> not reentrant and things like
> 
> 	saved_CFLAGS="${CFLAGS}"
> 	...
> 	CFLAGS="${saved_CFLAGS}"
> 
> could easily be trashed.

That's for portability. autoconf's configure scripts is testerd on various 
shells. Luckily you don't have to write them more than you have to
write binary code. It is usually more handy to debug it through the end
of config.log rather than through the configure script .

> 
> > Once again (I'll agree with Russell here) it makes absolutely no sense 
> > for /usr/local to be the standard place for libraries to be installed, 
> > but that they are not in the search path for the compiler and linker. 
> > All this does is require every package that wants to build on FreeBSD 
> > to require special logic to add them to the search path, when the 
> > FreeBSD toolchain could easily have these paths embedded into the toolchain 
> > by default. How frustrating :-)

What happens if you simply hint autoconf? pass it proper values of PATH,
LD_LIBRARY_PATH, CFLAGS , LDFLAGS ?

It's been a while since I've used custom build environments. But I
remember autoconf using such hints well (e.g: on my old Solaris
account). Those were the standard settings in my environment as I had a
non-standard environment. 

So for starters: does autoconf take those hints? Which variables exactly
need settings?

-- 
Tzafrir Cohen         sip:tzafrir at local.xorcom.com
icq#16849755          iax:tzafrir at local.xorcom.com
+972-50-7952406          jabber:tzafrir at jabber.org
tzafrir.cohen at xorcom.com     http://www.xorcom.com