similar to: [CMake] External File Dependencies for Unit Tests

Thanks James! Thanks for the help. I certainly see your point. > In either case, if you wanted to change the test input, you'd need to rerun CMake again This is unfortunate, I would have hoped I could have CMake create $(wildcard *.yaml) type of output in the make files. But it sounds like this doesn't exist on make alternatives, so this wont work. There is actually a function to get

On 25/06/2019 11:24, James Henderson via llvm-dev wrote: > Hi Alex, > > Would you recommend that I do what is done in > unittest/ObjectYAML/MinidumpYAMLTest.cpp which just uses a string > inside the source file, or use an Inputs directory? Both are not > great, as you point out about using an Inputs directory > > > I'd be inclined to go with the

I have been working towards this on D63859. My current route was to add an optional callback to MemoryBuffer::getFileOrSTDIN which will be executed if stdin has not been redirected. James and I were talking over there and are maybe deciding that this might not be the best solution. The alternative in my mind is that the tools which want this behavior could do so by explicitly testing if

Like James, Michael suggested, I would prefer the default behavior be consistent across tools (either always read from stdin or no default at all /give error messages) From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, June 26, 2019 2:31 AM To: Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Cc: Fāng-ruì Sòng <maskray at google.com>; LLVMDev

Sounds good, I'll work on removing these in favor of defaulting to stdin then? > I think it would be much friendlier to just print "file or pipe expected" and then print the help. Do you have thoughts on this? I'm not sure there is a clean way to do this, the cleanest would be through getFileOrSTDIN(), but I'm not sure all of its users want this behavior. I don't

I'm working on an update to the patch. The only thing holding me up is trying to come to a final decision as to where all the various pieces should live. Specifically, the Google Test library, and the actual unit tests themselves. On Mon, Dec 29, 2008 at 9:17 AM, Chris Lattner <clattner at apple.com> wrote: > On Dec 27, 2008, at 8:54 PM, Talin wrote: > > Although I haven't

Debuginfo folks, What is your opinion on this proposal? Do we need to work on better DWARFLinker library for now? or Can we start to integrate llvm-dwarfutil as a series of small patches? If it is OK to start integrating of llvm-dwarfutil, Is it OK to move llvm-objcopy implementation into separate library ObjCopy ? Thank you, Alexey. On 01.09.2020 20:18, James Y Knight wrote: > > >

> Does anyone actually use the default to a.out behavior? This is a good point. What bugs me is continuity across the tools, I agree with you that it isn't particularly useful to default to a.out. But we are kind of stuck with the weird way that GNU's binutils do things. I am not in favor of llvm-objdump defaulting to a.out, but llvm-readelf giving this warning message. My guess is that

On Dec 30, 2008, at 2:54 PM, Talin wrote: > OK changes made and new patch attached. Nice +++ utils/unittest/Makefile (revision 0) ... +# This has to come after Makefile.common, since it doesn't allow us to +# override the VPATH value unless we set PROJECT_NAME, which we don't want +# to do. +VPATH = $(LLVM_SRC_ROOT)/utils/unittest/googletest/src/ Why play with VPATH here? What

On Fri, Dec 26, 2008 at 8:06 PM, Misha Brukman <brukman at gmail.com> wrote: > On Dec 22, 7:34 pm, Talin <viri... at gmail.com> wrote: > > (Forwarding this to llvm-dev) > > > > This patch adds a unit test framework to LLVM, along with a sample unit > test > > for DenseMap. I don't expect this patch to be accepted as-is, this is > mainly > > a

On Mon, Dec 29, 2008 at 1:57 PM, Misha Brukman <brukman at gmail.com> wrote: > 2008/12/29 Talin <viridia at gmail.com> > >> Do the existing tests use a wildcard rule to gather all test sources? We >> would need to insure that the wildcard rule for the unit tests and the large >> tests are mutually exclusive. >> > > By "large tests", I

Hello everyone, Are there any reasons the unittests in LLVM repo are split into independent executables, e.g. ADTTests, AnalysisTests, etc. Are there any performance or easy-to-use reasons for this? I plan to migrate to GTest from a project where we have all unittests in a single executable. - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL:

(Forwarding this to llvm-dev) This patch adds a unit test framework to LLVM, along with a sample unit test for DenseMap. I don't expect this patch to be accepted as-is, this is mainly a trial balloon and proof of concept. Some notes about the patch: 1) For the testing framework, I went with Google Test, since it's the one I have the most experience with. I fully expect an extended

Hi Tim and Alex Thanks for your replies. So just to make it clear for me: does this imply that there’s indeed no way on the current version to tell the compiler or Clang to optimize this? Thanks, Joan > On 8 Aug 2019, at 18:30, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, 8 Aug 2019 at 17:08, Alex Brachet-Mialot via llvm-dev > <llvm-dev at

2008/12/29 Talin <viridia at gmail.com> > Do the existing tests use a wildcard rule to gather all test sources? We > would need to insure that the wildcard rule for the unit tests and the large > tests are mutually exclusive. > By "large tests", I assume you mean the .ll tests? Those are one-file-per-test. Also, if you use Chris' suggestion on directories, it

On Dec 22, 7:34 pm, Talin <viri... at gmail.com> wrote: > (Forwarding this to llvm-dev) > > This patch adds a unit test framework to LLVM, along with a sample unit test > for DenseMap. I don't expect this patch to be accepted as-is, this is mainly > a trial balloon and proof of concept. I think this is a great idea! As Keir already noted, I would also agree with LLVM

Thanks for the reply. Typing in my username and clicking "Forgot password?" got me a link I could use to log in. It'd still be good if federated login worked again. Is there an upstream issue for this? On Thu, Nov 28, 2019 at 5:09 PM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Yes this was broken for me too, there was another post on here about this

Do the existing tests use a wildcard rule to gather all test sources? We would need to insure that the wildcard rule for the unit tests and the large tests are mutually exclusive. Also, will the unit tests be one executable or many? They will probably compile/run faster if there is a smaller number of executables. On Mon, Dec 29, 2008 at 1:43 PM, Misha Brukman <brukman at gmail.com> wrote:

Just a curiosity question, why push for gtest vs Boost Test or a different test suite? I normally use Boost, and their test suite, so I'm more familiar with that. So I was wondering is one better then the other, or is it just that someone makes a patch for it? Regards Mark Kromis On Dec 27, 2008, at 12:26 AM, Keir Mierle wrote: > > > On Fri, Dec 26, 2008 at 8:06 PM, Misha

Is no one else seeing this? (I've been seeing it for a few days) In file included from /usr/local/google/home/blaikie/dev/llvm/src/utils/unittest/googletest/gtest-all.cc:39: In file included from /usr/local/google/home/blaikie/dev/llvm/src/utils/unittest/googletest/include/gtest/gtest.h:57: In file included from