search for: optiongroups

I was thinking about this more, and perhaps a more preferable solution would have some kind of OptionGroup parameter to constructors of cl options. This would of course be optional, with the default being a global one. Then, ParseCommandLineOptions() could instead take as an optional parameter an OptionGroup, and would then only work on cl options in that group. Would this approach be preferable?

Here are a few extra attributes which I have not seen mentioned yet which I think would be useful. Any comments would be appreciated. *Version* The version of the plugin, I think the reasons for this are obvious. <version> <major>0</major> <minor>1</minor> <patch>0</patch> </version> *Addition to features* Just add an attribute to

On Mar 4, 2009, at 12:15 AM, Alexei Svitkine wrote: > I was thinking about this more, and perhaps a more preferable solution > would have some kind of OptionGroup parameter to constructors of cl > options. This would of course be optional, with the default being a > global one. Hi Alexei, Sorry for the delay, I've been swamped lately and tend to process email in LIFO order :(

I don't have any opinions about this. Chris? Evan On Feb 17, 2009, at 8:00 PM, Alexei Svitkine wrote: > The motivation behind this patch is that tools that use LLVM as a > library and want to use its command line parsing facilities may not > want all the various options defined in the LLVM libraries to be > available - simply because they may not be relevant. > > This patch

...ommands[subcommand]._run( File "/usr/local/samba/lib/python2.4/site-packages/samba/netcmd/__init__.py", line 201, in _run return self.subcommands[subcommand]._run( File "/usr/local/samba/lib/python2.4/site-packages/samba/netcmd/__init__.py", line 142, in _run parser, optiongroups = self._create_parser(argv[0]) File "/usr/local/samba/lib/python2.4/site-packages/samba/netcmd/__init__.py", line 130, in _create_parser prog=prog,epilog=epilog) Are there any links for those successfully upgrade their samba 3 to samba 4? Regards, Mario

On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. > > As the first step, I am thinking of consolidating the common options shared across all the Unix

The motivation behind this patch is that tools that use LLVM as a library and want to use its command line parsing facilities may not want all the various options defined in the LLVM libraries to be available - simply because they may not be relevant. This patch adds an optional "Prefix" parameter to ParseCommandLineOptions(). If set, this will make inaccessible any options that do not

I like your predicate idea - that could solve both #1 and #2. I'm wondering whether it would be possible to get the predicate stuff automatically somehow - based on which library an option is coming from. Something like looking at the path in __FILE__. Then we could simply enable/disable any options based on their library of origin (i.e. as in, one of the --libs out of llvm-config --libs).

Hi Nick, There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. The options that are shared between Darwin/GnuLD are :- a) -o b) -L c)

Hi all, i tried to set up the helper method "grouped_programs_selector" in application_helpers.rb. Since i dont have a deep understanding of Ruby itself, I pretty much copied the Grouped Selection List (Chapter 17, pp. 259, 260) example from Dave & David''s Book. The optiongroups are properly created by my method, but there are no options inside. Maybe you can debug this one? -snip- from index.rhtml <%= option_groups_from_collection_for_select( grouped_programs_selector(:programs, :programtypes), # calling application_helper - method. :options, :type_name, :id,...

On 9/18/2013 4:31 PM, Nick Kledzik wrote: > On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > >> Hi Nick, >> >> There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. >> >> As the first step, I am thinking

Hi, A feature I've wanted in lit for a while is a having a timeout per test. Attached are patches that implement this idea. I'm e-mailing llvm-dev rather than llvm-commits because I want to gather more feedback on my initial implementation and hopefully some answers to some unresolved issues with my implementation. Currently in lit you can set a global timeout for all of the tests but