Jeff Layton wrote: > On Mon, 8 Jun 2009 08:36:34 -0700 > "Muntz, Daniel" <Dan.Muntz@xxxxxxxxxx> wrote: > >> >> >>> -----Original Message----- >>> From: Mike Frysinger [mailto:vapier@xxxxxxxxxx] >>> Sent: Monday, June 08, 2009 7:24 AM >>> To: Chuck Lever >>> Cc: Jeff Layton; Muntz, Daniel; linux-nfs@xxxxxxxxxxxxxxx >>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
