[asterisk-dev] autoconf issues for FreeBSD

[Luigi Rizzo]

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.

Also the choice of using "ancient greek" (pre-1977 shell) 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.

> 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 :-)

Yes, frustrating. But blaming the platform (or autoconf as i did above,
or my own ignorance as i often do privately) doesn't fix the build, so
let's work on the latter :)

	cheers
cheers: Command not found.

	/usr/local/cheers :)
	luigi