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

Steve Dickson
2009-06-09T13:02:05Z

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.