linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Steve Dickson <SteveD@redhat.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 10/10] nfsdcltrack: flip the default in autoconf to "yes" for it
Date: Thu, 25 Oct 2012 10:34:01 -0400	[thread overview]
Message-ID: <20121025103401.4b15123b@corrin.poochiereds.net> (raw)
In-Reply-To: <50894C88.9070205@RedHat.com>

On Thu, 25 Oct 2012 10:28:24 -0400
Steve Dickson <SteveD@redhat.com> wrote:

> 
> 
> On 25/10/12 10:07, Jeff Layton wrote:
> > On Thu, 25 Oct 2012 08:57:17 -0400
> > Steve Dickson <SteveD@redhat.com> wrote:
> > 
> >>
> >>
> >> On 24/10/12 11:25, Jeff Layton wrote:
> >>> Allow nfsdcltrack to be built by default if all of the requirements
> >>> for it are in place. Set the initial state of $enable_nfsdcltrack
> >>> to "maybe", and fix the appropriate tests to just disable building
> >>> the binary unless someone explicitly requests it.
> >> Hmm... I'm not sure I too keen on this "maybe" state... 
> >>
> > 
> > Would it help if we renamed it to
> > "yes_but_only_if_requirements_are_met" ? :)
> :-) 
> 
> > 
> >> So if no flags are given to ./configuration, and not 
> >> all the requirements to build nfsdcltrack exists, the configuration 
> >> will succeed, but the command will not be build. Correct?
> >>
> > 
> > Correct.
> > 
> >> But if the  --enable_nfsdcltrack flag is given and not all
> >> the requirements to build nfsdcltrack exist the configuration
> >> will fail. 
> >>
> > 
> > Correct.
> > 
> >> I'm thinking we might want to make it a bit more binary. Either
> >> on or off. Like it is with the other conditionally built 
> >> commands... 
> >>
> > 
> > So you want to fail the configure stage if all of the requirements for
> > nfsdcltrack aren't present? That doesn't sound good to me. Note that we
> > do have "tristate" handling already for stuff like the --disable-uuid
> > option...
> I'm thinking there it might cause confusion to silently not build
> a binary, when the expectation is this should be there. I'm thinking
> a failure of the config script would remove that confusion... And
> as long as there a way to mask that failure out (aka --enable_nfsdcltrack=no
> or --disable_nfsdcltrack) it will make it more explicit to what is or
> is not happening... 
> 
>  

It's not silent. It does throw a warning in this case, but that is
likely to get lost in the noise. It's your call -- if you want to fail
the build by default if the requirements aren't present, then I'm ok
with that.

-- 
Jeff Layton <jlayton@redhat.com>

      reply	other threads:[~2012-10-25 14:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-24 15:25 [PATCH v2 00/10] nfsdcltrack: create a new usermodehelper upcall program for tracking clients Jeff Layton
2012-10-24 15:25 ` [PATCH v2 01/10] nfsdcltrack: fix segfault in sqlite debug logging Jeff Layton
2012-10-24 15:25 ` [PATCH v2 02/10] nfsdcltrack: rename the nfsdcld directory and options to nfsdcltrack Jeff Layton
2012-10-24 15:25 ` [PATCH v2 03/10] nfsdcltrack: remove pointless sqlite_topdir variable Jeff Layton
2012-10-24 15:25 ` [PATCH v2 04/10] nfsdcltrack: break out a function to open the database handle Jeff Layton
2012-10-24 15:25 ` [PATCH v2 05/10] nfsdcltrack: add a new "one-shot" program for manipulating the client tracking db Jeff Layton
2012-10-25 12:56   ` Steve Dickson
2012-10-25 13:53     ` Jeff Layton
2012-10-25 14:30       ` Steve Dickson
2012-10-24 15:25 ` [PATCH v2 06/10] nfsdcltrack: add a legacy transition mechanism Jeff Layton
2012-10-24 15:25 ` [PATCH v2 07/10] nfsdcltrack: add a manpage for nfsdcltrack Jeff Layton
2012-10-24 15:25 ` [PATCH v2 08/10] nfsdcltrack: remove the nfsdcld daemon Jeff Layton
2012-10-24 15:25 ` [PATCH v2 09/10] nfsdcltrack: update the README about server startup order Jeff Layton
2012-10-24 15:25 ` [PATCH v2 10/10] nfsdcltrack: flip the default in autoconf to "yes" for it Jeff Layton
2012-10-25 12:57   ` Steve Dickson
2012-10-25 14:07     ` Jeff Layton
2012-10-25 14:28       ` Steve Dickson
2012-10-25 14:34         ` Jeff Layton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121025103401.4b15123b@corrin.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=SteveD@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).