Re: should we make --enable-tirpc the default in current nfs-utils?

[Steve Dickson <SteveD@redhat.com>]

Jeff Layton wrote:
> On Mon, 8 Jun 2009 08:36:34 -0700
> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> 
>>  
>>
>>> -----Original Message-----
>>> From: Mike Frysinger [mailto:vapier@gentoo.org] 
>>> Sent: Monday, June 08, 2009 7:24 AM
>>> To: Chuck Lever
>>> Cc: Jeff Layton; Muntz, Daniel; linux-nfs@vger.kernel.org
>>> Subject: Re: should we make --enable-tirpc the default in 
>>> current nfs-utils?
>>>
>>> On Monday 08 June 2009 10:16:07 Chuck Lever wrote:
>>>> Frankly, I think dropping back automatically is not a good 
>>> idea.  The 
>>>> torrent of messages that configure normally spits out means that 
>>>> messages about a missing libtirpc are going to be missed in most 
>>>> cases, and folks will think that because they specified 
>>> --enable-tirpc 
>>>> on the configure command line, that's the build they got.
>>> the automatic fallback is when no tirpc option is specified.  
>>> if --enable- tirpc is specified, then it should fail (and 
>>> that is what the proposed patch does).
>>> -mike
>>>
>> When libnfsidmap, libgssglue, etc. are not present the build fails.  The
>> builder didn't specify any particular --enable-X flag, and the build
>> doesn't just do something like fall back and build v3-only.  Why would I
>> want the build to nondeterministically (to the extent that one might not
>> be aware of what libraries are installed) generate different code?
>>
> 
> The build only fails if you have enabled features that require them.
> For instance it only requires libgssglue if --enable-gss is on. That
> gets turned on by default. You could probably make a case for
> turning off the feature of the required libs weren't available, but at
> some point autoconf becomes a maze of twisty options and fallbacks.
> 
I actual I like the fact that if --enable-gss is enabled and the
correct libs are not install, the configuration fails...
I think that's the right thing to do...

steved.