similar to: [LLVMdev] Patch: Prefix for ParseCommandLineOptions()

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Patch: Prefix for ParseCommandLineOptions()"

2009 Mar 04
0
[LLVMdev] Patch: Prefix for ParseCommandLineOptions()
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
2009 Mar 04
2
[LLVMdev] Patch: Prefix for ParseCommandLineOptions()
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?
2009 Mar 09
0
[LLVMdev] Patch: Prefix for ParseCommandLineOptions()
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 :(
2009 Mar 09
1
[LLVMdev] Patch: Prefix for ParseCommandLineOptions()
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).
2012 Sep 21
2
[LLVMdev] patch to enable response file support in ParseCommandLineOptions
Hi, I am sending a patch to enable response file support in ParseCommandLineOptions. With this change, all llvm tools will support response file. This helps overcome the command line length limit which we encountered recently. Index: include/llvm/Support/CommandLine.h =================================================================== --- include/llvm/Support/CommandLine.h (revision 164408) +++
2012 Sep 22
0
[LLVMdev] patch to enable response file support in ParseCommandLineOptions
Hi Sam, please add a testcase. Does this cause any regressions? Ciao, Duncan. > I am sending a patch to enable response file support in ParseCommandLineOptions. > With this change, all llvm tools will support response file. This helps overcome > the command line length limit which we encountered recently. > > Index: include/llvm/Support/CommandLine.h > >
2012 Oct 02
3
[LLVMdev] [llvm-commits] patch to enable response file support in ParseCommandLineOptions
Thanks Chris for the comment. Since there is no objection, I attached a new patch which enables response file support and removes the argument for controlling/disabling response file support. The patch also contains a simple test. I did regression check and there are no regressions. + llvmdev Sam From: Chris Lattner [mailto:clattner at apple.com] Sent: Sunday, September 30, 2012 2:20 PM To:
2012 Oct 02
1
[LLVMdev] [llvm-commits] patch to enable response file support in ParseCommandLineOptions
Can we call this a "parameters file"? I find "response file" to be non-obvious. On Tue, Oct 2, 2012 at 8:18 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > Thanks Chris for the comment. > > > > Since there is no objection, I attached a new patch which enables response > file support and removes the argument for controlling/disabling response >
2012 Oct 03
0
[LLVMdev] [llvm-commits] patch to enable response file support in ParseCommandLineOptions
Response file is the conventional name for files serving this purpose. A google search shows the usage of "response file" is not rare. Also it has been used in the LLVM documentation: http://llvm.org/docs/CommandLine.html#response-files Sam -----Original Message----- From: Matt Beaumont-Gay [mailto:matthewbg at google.com] Sent: Tuesday, October 02, 2012 1:35 PM To: Liu, Yaxun (Sam)
2007 May 21
2
Some suggestions for extra metadata
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
2018 Jun 03
3
chrony configuration for secondary samba DC
The output is: alexei at ubuntu-dc:~$ sudo samba -b | grep 'SIGND' NTP_SIGND_SOCKET_DIR: /var/lib/samba/ntp_signd On Sun, Jun 3, 2018 at 5:32 PM Rowland Penny via samba <samba at lists.samba.org> wrote: > > On Sun, 3 Jun 2018 17:11:47 +0300 > Alexei Rozenvaser <alexei.roz at gmail.com> wrote: > > > On Sun, Jun 3, 2018 at 4:51 PM Rowland Penny via samba
2018 Jun 03
1
chrony configuration for secondary samba DC
But according to following command output chrony on my samba dc already serves the windows clients: alexei at ubuntu-dc:~$ sudo chronyc clients Hostname NTP Drop Int IntL Last Cmd Drop Int Last =============================================================================== 192.168.0.45 4 0 7 - 501 0 0 - - 192.168.0.72
2018 Jun 03
4
chrony configuration for secondary samba DC
On Sun, Jun 3, 2018 at 4:51 PM Rowland Penny via samba <samba at lists.samba.org> wrote: > > On Sun, 3 Jun 2018 16:29:04 +0300 > Alexei Rozenvaser via samba <samba at lists.samba.org> wrote: > > > Hi > > > > I'm running samba 4.7.6 on ubuntu 18.04 as (backup / secondary) domain > > controller > > No your not, you are just running Samba as
2018 Jun 03
2
chrony configuration for secondary samba DC
Am 03.06.2018 um 16:48 schrieb Rowland Penny via samba: > On Sun, 3 Jun 2018 17:37:45 +0300 > Alexei Rozenvaser <alexei.roz at gmail.com> wrote: > >> The output is: >> alexei at ubuntu-dc:~$ sudo samba -b | grep 'SIGND' >> NTP_SIGND_SOCKET_DIR: /var/lib/samba/ntp_signd > > First three letters are NTP and at the moment, Samba only supports the
2018 Jun 03
5
chrony configuration for secondary samba DC
Hi I'm running samba 4.7.6 on ubuntu 18.04 as (backup / secondary) domain controller that joined to an Existing Active Directory (Windows 2012R2 server). The question is about Time Synchronization across the domain. How should I configure chrony v3.2 in order to provide time synchronization: 1. between main Windows DC and Samba DC 2. Between Samba DC and windows clients in case when
2001 Dec 11
2
Rsyncd limits
Hi all, I was wondering if it will require any major rewrites of the daemon/client to include limits on the data transfer rate ? Alexei.
2018 Jun 03
2
chrony configuration for secondary samba DC
On Sun, Jun 3, 2018 at 4:51 PM Rowland Penny via samba <samba at lists.samba.org> wrote: > > On Sun, 3 Jun 2018 16:29:04 +0300 > Alexei Rozenvaser via samba <samba at lists.samba.org> wrote: > > > Hi > > > > I'm running samba 4.7.6 on ubuntu 18.04 as (backup / secondary) domain > > controller > > No your not, you are just running Samba as
2015 Aug 05
2
[LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Hi, Alexei On 2015/7/30 1:13, Alexei Starovoitov wrote: > On 7/29/15 2:38 AM, He Kuang wrote: >> Hi, Alexei >> >> On 2015/7/28 10:18, Alexei Starovoitov wrote: >>> On 7/25/15 3:04 AM, He Kuang wrote: >>>> I noticed that for 64-bit elf format, the reloc sections have >>>> 'Addend' in the entry, but there's no 'Addend' info
2018 Jun 03
3
chrony configuration for secondary samba DC
How you so sure about it? Even at https://packages.ubuntu.com/bionic/samba chrony mentioned as suggested related package . On Sun, Jun 3, 2018 at 6:13 PM Rowland Penny via samba <samba at lists.samba.org> wrote: > > On Sun, 3 Jun 2018 16:59:38 +0200 > Reindl Harald via samba <samba at lists.samba.org> wrote: > > > > > > > Am 03.06.2018 um 16:48 schrieb
2013 Sep 18
2
[LLVMdev] [lld][Options] Sharing common options across flavors
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)