From: Daniel Vetter <daniel@ffwll.ch>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [igt PATCH 3/4] lib: add subtest extra command line option handling
Date: Fri, 16 Aug 2013 14:09:25 +0200 [thread overview]
Message-ID: <20130816120925.GG776@phenom.ffwll.local> (raw)
In-Reply-To: <1376651227.2576.14.camel@intelbox>
On Fri, Aug 16, 2013 at 02:07:07PM +0300, Imre Deak wrote:
> On Tue, 2013-08-06 at 11:09 +0200, Daniel Vetter wrote:
> > On Mon, Aug 05, 2013 at 02:45:25PM +0300, Imre Deak wrote:
> > > At the moment any command line option handling done by tests will
> > > interfere with the option handling of the subtest interface. To fix this
> > > add a new version of the subtest_init function accepting optional short
> > > and long command line options. Merge these together with the subtest
> > > interface's own long options and handle both together in the same
> > > getopt_long call.
> > >
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> >
> > Hm, I've thought that getopt would filter the passed-in argv/argc arrays
> > and we could run a second getopt afterwards without too much interfence
> > (maybe we need to reset a few global getop state variables). But I'm not
> > sure since I've never tried it out. Am I wrong?
>
> Afaics getopt itself can't handle the long options (which we already
> have for subtests), it'll try to parse each character of the long option
> as a short one.
>
> We could still do the scanning twice by always using getopt_long, but
> there I don't like the fact that we would have to set opterr=0 and
> silently ignore invalid options. Also I thought that later we could add
> a check for clashing test case/subtest options and that's not possible
> by scanning twice.
Hm, just scanning with getopt_long twice was actually my idea. It's a bit
ugly that we then can't check for unknown options. But since you have all
already solved I think we could just move ahead with your patch here. So
please push.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2013-08-16 12:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 11:45 [igt PATCH 0/4] add support for testing clone output configs Imre Deak
2013-08-05 11:45 ` [igt PATCH 1/4] lib: shorten DP/eDP connector names Imre Deak
2013-08-05 11:45 ` [igt PATCH 2/4] lib: handle SIGSEGV similarly to other error signals Imre Deak
2013-08-05 11:45 ` [igt PATCH 3/4] lib: add subtest extra command line option handling Imre Deak
2013-08-06 9:09 ` Daniel Vetter
2013-08-16 11:07 ` Imre Deak
2013-08-16 12:09 ` Daniel Vetter [this message]
2013-08-05 11:45 ` [igt PATCH 4/4] tests: add kms_setmode Imre Deak
2013-08-06 9:23 ` Daniel Vetter
2013-08-16 11:23 ` Imre Deak
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=20130816120925.GG776@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.