This is WIP, it doesn't quite work yet. On my dawin machine, I think it is picking up the system libc++abi, rather than the just-built one (maybe I've got the default backwards? not sure).
@danalbert, what do you think? Am I missing anything big?
Should improve test times significantly, since you seem to have deleted all of them ;)
I'm assuming you renamed them with .pass.cpp and forgot to add the new names (git mv is your friend). As I said in IRC, I don't really like building metadata in to the test name. I'd rather see // XCOMPILE-FAIL or similar added to the test runner instead.
Looks much better. I'm especially liking all the red. I'll try cherry-picking this tomorrow to see if it meets all my needs, but it looks like it should.
I thought obj_root was supposed to be the build output directory.
os.path.join (and anywhere else you've done this)
config_module = importlib.import_module(config_module_name)
I would have done that when I wrote it the first time but I had thought we bumped the minimum version to 2.6, not 2.7.
Did I see a patch to libc++ that added this to libcxx.test.config.Configuration earlier? I assume that's why this isn't needed any more.
Is this actually used for anything? If it is it's in the libc++ side of this, but I can't think of what we'd actually be using it for...
I svn mv'd all the files to their *.pass.cpp equivalents. Not sure why they aren't showing up in the diff.
I could go either way on the metadata thing. Or do both, and have checks that the extension matches the metadata. Don't really have a preference.
Copy-pasta from the libc++ config. That's just a default for when it can't find the right thing from cmake. I'm not sure what else to default it to.
That was something @EricWF added to turn off measuring the durations of things like the demangler tests.
The guard is named differently between libc++abi and libc++.
You're right, enable_exceptions, enable_rtti, and enable_shared aren't useful for libc++abi. Good catch.
Diffs in this file bring libc++abi's version of this file most of the way in sync with libc++'s. I'm not too familiar with cmake to know whether 'add_custom_target' vs 'add_lit_testsuite' is better here. I suspect the change should be going the other way?
this seems like a reasonable default now. I should delete this comment.
What prevents us from continuing to use add_lit_testsuite? If I'm reading the definition correctly, the function will automatically use LLVM_LIT_ARGS (used indirectly in add_lit_target). That also keeps the FindPythonInterp` stuff delegated to the LLVM cmake code.
os.path.join (The leading slash isn't necessary with os.path.join. I'd like to believe Windows will handle that gracefully, but I don't actually know.)