This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: binutils prerequisites (recent zlib version - what else?)


Hello,

* Ian Lance Taylor wrote on Tue, Apr 26, 2011 at 08:18:58PM CEST:
> kevin diggs <diggskevin38@gmail.com> writes:
> > Why? Wouldn't it be better to tell the poor, confused user that they
> > are configuring up the wrong tree? So that we can go RTFM and get the
> > right option (or whine and complain if the desired functionality does
> > not exist)?
> 
> It would be better in some cases, yes.  However, the gcc and binutils
> trees are examples where there is a master configure script at the top
> which invokes a range of sub-configure scripts below.  To make that
> work, the master configure script needs to pass all --with and --enable
> options to the sub-configure scripts.  If configure scripts reject
> unrecognized options, then it would be necessary for every configure
> script to recognize every option.  Since the sub-projects are maintained
> by different groups of people, that is infeasible.
> 
> To avoid the problem there is, yes, an option: --enable-option-checking.
> It's sort of pathetic to have an option for option checking, since most
> people aren't going to be aware of it, but it's the best we have at the
> moment.

The option checking option is enabled by default unless the configure
script uses AC_CONFIG_SUBDIRS or AC_DISABLE_OPTION_CHECKING.  Which is
arguably a simple yet often encountered setup (and the disabling is
done to avoid false warnings as you described).

So, at least patheticness is sort of limited.  ;-)

Cheers,
Ralf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]