Displaying 19 results from an estimated 19 matches for "parseenvironmentopt".
2012 Sep 21
2
[LLVMdev] patch to enable response file support in ParseCommandLineOptions
...t argc, const char * const *argv,
const char *Overview = 0,
- bool ReadResponseFiles = false);
+ bool ReadResponseFiles = true);
//===----------------------------------------------------------------------===//
// ParseEnvironmentOptions - Environment variable option processing alternate
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120921/0fb08888/attachment.html>
2012 Sep 22
0
[LLVMdev] patch to enable response file support in ParseCommandLineOptions
...const char *Overview = 0,
>
> - bool ReadResponseFiles = false);
>
> + bool ReadResponseFiles = true);
>
> //===----------------------------------------------------------------------===//
>
> // ParseEnvironmentOptions - Environment variable option processing alternate
>
> Sam
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
2013 Jan 16
3
[LLVMdev] [llvm-commits] [PATCH] A "very verbose" mode for FileCheck
...like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function.
>>
>> I agree that a command line option would be better. But in that case
>> all tests should be updated. It is not an issue for me -- it is
>> mostly mechanical. So should I change tests to use %FileCheck?
>
> Here's a third attempt.
>
> Th...
2013 Jan 16
0
[LLVMdev] [PATCH] A "very verbose" mode for FileCheck
...like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function.
-Chris
2013 Jan 16
0
[LLVMdev] [llvm-commits] [PATCH] A "very verbose" mode for FileCheck
...like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function.
>>>
>>> I agree that a command line option would be better. But in that case
>>> all tests should be updated. It is not an issue for me -- it is
>>> mostly mechanical. So should I change tests to use %FileCheck?
>>
>> Here's a thi...
2013 Jan 16
3
[LLVMdev] [PATCH] A "very verbose" mode for FileCheck
...like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function.
I agree that a command line option would be better. But in that case
all tests should be updated. It is not an issue for me -- it is
mostly mechanical. So should I change tests to use %FileCheck?
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j...
2004 Jul 03
1
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
...std::allocator<char*> >&, const char*)':
CommandLine.cpp:189: error: `strdup' undeclared (first use this function)
CommandLine.cpp:189: error: (Each undeclared identifier is reported only
once
for each function it appears in.)
CommandLine.cpp: In function `void llvm::cl::ParseEnvironmentOptions(const
char*, const char*, const char*)':
CommandLine.cpp:230: error: `strdup' undeclared (first use this function)
gmake[1]: *** [/usr/local/src/llvm/lib/Support/Debug/CommandLine.lo] Error 1
gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support'
gmake: *** [all] Error 1...
2013 Jan 16
1
[LLVMdev] [llvm-commits] [PATCH] A "very verbose" mode for FileCheck
...like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function.
>>>>
>>>> I agree that a command line option would be better. But in that case
>>>> all tests should be updated. It is not an issue for me -- it is
>>>> mostly mechanical. So should I change tests to use %FileCheck?
>>>
>&...
2018 Sep 06
3
Environment variables
...re huge customer codes with
often many Makefiles which may be generated by custom tools we don't
understand at all. :) It's much easier to use the compiler flags that
are in the Makefiles and set some environment variables to override
things during "make."
It seems odd that cl::ParseEnvironmentOptions exists but there is no
"official" way to get at environment variables.
If this isn't something the community wants or needs, that's fine. I
was just asking if a contribution would be welcomed if we end up
developing something.
-David
Matthias Braun &...
2013 Jan 16
4
[LLVMdev] [PATCH] A "very verbose" mode for FileCheck
Hello,
When someone breaks a FileCheck-based test on some buildbot, sometimes
it may not be obvious *why* did it fail. If the failure can not be
reproduced locally, it can be very hard to fix.
I propose adding a "very verbose" mode to FileCheck. In this mode
FileCheck will dump the input file in case of failure. This mode will
be enabled by an environment variable
2013 Jan 16
0
[LLVMdev] [PATCH] A "very verbose" mode for FileCheck
...like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function.
>
> I agree that a command line option would be better. But in that case
> all tests should be updated. It is not an issue for me -- it is
> mostly mechanical. So should I change tests to use %FileCheck?
Here's a third attempt.
The new behavior is as follows:
1....
2013 Jan 17
2
[LLVMdev] [llvm-commits] [PATCH] A "very verbose" mode for FileCheck
...sed on environment variables. It isn't discoverable in --help.
> If for some reason, it is bad for lit to implicitly pass the option, I'd
> rather have a standard FILECHECK_COMMANDLINE environment variable, and have
> filecheck parse arbitrary options out of it using the
> cl::ParseEnvironmentOptions function.
> >>>
> >>> I agree that a command line option would be better. But in that case
> >>> all tests should be updated. It is not an issue for me -- it is
> >>> mostly mechanical. So should I change tests to use %FileCheck?
> >>...
2018 Sep 06
2
Environment variables
...which may be generated by custom tools we don't
> > understand at all. :) It's much easier to use the compiler flags that
> > are in the Makefiles and set some environment variables to override
> > things during "make."
> >
> > It seems odd that cl::ParseEnvironmentOptions exists but there is no
> > "official" way to get at environment variables.
> >
> > If this isn't something the community wants or needs, that's fine. I
> > was just asking if a contribution would be welcomed if we end up
> > developing something....
2004 Jul 02
1
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
...std::allocator<char*> >&, const char*)':
CommandLine.cpp:189: error: `strdup' undeclared (first use this function)
CommandLine.cpp:189: error: (Each undeclared identifier is reported only
once
for each function it appears in.)
CommandLine.cpp: In function `void llvm::cl::ParseEnvironmentOptions(const
char*, const char*, const char*)':
CommandLine.cpp:230: error: `strdup' undeclared (first use this function)
gmake[1]: *** [/usr/local/src/llvm/lib/Support/Debug/CommandLine.lo] Error 1
gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support'
gmake: *** [all] Error 1...
2013 Jan 17
0
[LLVMdev] [llvm-commits] [PATCH] A "very verbose" mode for FileCheck
...t;>> If for some reason, it is bad for lit to implicitly pass the option, I'd
>> >>>> rather have a standard FILECHECK_COMMANDLINE environment variable, and have
>> >>>> filecheck parse arbitrary options out of it using the
>> >>>> cl::ParseEnvironmentOptions function.
>> >>>
>> >>> I agree that a command line option would be better. But in that case
>> >>> all tests should be updated. It is not an issue for me -- it is
>> >>> mostly mechanical. So should I change tests to use %FileCheck...
2013 Jan 17
3
[LLVMdev] [llvm-commits] [PATCH] A "very verbose" mode for FileCheck
...ason, it is bad for lit to implicitly pass the
> option, I'd
> >> >>>> rather have a standard FILECHECK_COMMANDLINE environment variable,
> and have
> >> >>>> filecheck parse arbitrary options out of it using the
> >> >>>> cl::ParseEnvironmentOptions function.
> >> >>>
> >> >>> I agree that a command line option would be better. But in that
> case
> >> >>> all tests should be updated. It is not an issue for me -- it is
> >> >>> mostly mechanical. So should I chang...
2013 Jan 17
0
[LLVMdev] [llvm-commits] [PATCH] A "very verbose" mode for FileCheck
...;>> option, I'd
>> >> >>>> rather have a standard FILECHECK_COMMANDLINE environment variable,
>> >> >>>> and have
>> >> >>>> filecheck parse arbitrary options out of it using the
>> >> >>>> cl::ParseEnvironmentOptions function.
>> >> >>>
>> >> >>> I agree that a command line option would be better. But in that
>> >> >>> case
>> >> >>> all tests should be updated. It is not an issue for me -- it is
>> >> >>...
2018 Sep 06
2
Environment variables
Ok, thanks! I'm not dealing with UTF-8 so I don't think Process::GetEnv
will work. I was looking for something that caches calls to getenv so
checks could be put into tight(-ish) loops without too much performance
impact.
Would such a utility be of interest to the community?
-David
Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
2007 Apr 17
1
[LLVMdev] Execution of generated code after multiple compiles fails
Hola LLVMers,
I'm having a tricky time diagnosing something that is going on in my
program and am hoping some of you might have used LLVM in a similar way
before. All of this is using LLVM 1.9 on Mac OSX. Here is our usage
pattern:
1. Read in a program in a language we are designing
2. Transform it into LLVM IR using the llvm class hierarchy
3. Link this module to a set of support