[asterisk-dev] autoconf issues for FreeBSD

[Luigi Rizzo]

On Thu, Oct 05, 2006 at 11:11:00AM +0200, Tzafrir Cohen wrote:
> On Thu, Oct 05, 2006 at 12:15:33AM -0700, Luigi Rizzo wrote:
...
> > 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?

when there are 303 successful checks and 29 failed ones,
i would much like a simple option to only report the failures.
I blame myself for not knowing how this --useful-output
option is spelled.

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

>From http://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Portable-Shell.html#Portable-Shell

	When writing your own checks, there are some shell-script
	programming techniques you should avoid in order to make
	your code portable. The Bourne shell and upward-compatible
	shells like the Korn shell and Bash have evolved over the
	years, but to prevent trouble, do not take advantage of
	features that were added after Unix version 7, circa 1977
	(see Systemology).

i agree it could have been worse - they might have used MIX assembly.

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

the "configure.ac" scripts don't look very different from machine code.
They are generally huge and obfuscated and often buggy because people
have no time to waste on them and rely on copying from other equally
poor examples.

But yes, it's great to be able to run them on a PDP-11 :)

> 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?

it does take the hints. That is not the problem.

The problem is that platform-specific _defaults_ should be provided
by the tool (which should aware of platform issues) not by the
asterisk or perl or gzip or ghostscript programmer (who cannot know
what's the default location of stuff on FreeBSD, Knoppix, Ubuntu,
RedHat, Fedora, DragonFly, minix, you-name-it).

Basically the problem is that a lot of autoconf-based packages only work
on the platform where they were developed, and everywhere else they need
massive porting efforts.

	cheers
	luigi