search for: parseenvironmentopt

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