[PATCH] D29030: [LNT] Add cross-compilation support to 'lnt runtest test-suite'

[Chris Matthews via llvm-commits]

I agree that dropping all the client side tools would be (REALLY) nice.  The proxied test-suite approach adds conceptual and implementation complexity.

lnt runtest test-suite is still doing a lot, it is not by any means a thin wrapper.  I’d love to see a concrete proposal how we can migrate that into the test suite.

Also at the same time, I think the test-suite would start to need its own testing.
On January 25, 2017 at 1:40:03 AM, Kristof Beyls via Phabricator (reviews at reviews.llvm.org) wrote:

kristof.beyls marked an inline comment as done.  
kristof.beyls added a comment.  



>>> As for the rest of the commit: Using a toolchain file looks like just passing a -D flag which is already supported. As for picking up the compiler, couldn't you simply extract that from CMakeCache.txt? And if that doesn't work, shouldn't we rather upstream the changes to CMakeLists.txt that print the compiler instead of having LNT mess around with them?  
>>  
>> I'm trying to eliminate as many not-needed command line options as possible, e.g. --llvm-arch, --cross-compiling, ... . There are already more than enough command line options to lnt runtest, reducing the amount of them probably would make it simpler to use.  
>> Indeed, just using a -D flag to enable cross-compiling instead of having a separate lnt runtest command line option for it would be preferable (and then documenting how to use it to do cross-compiling).  
>> But then, doesn't the same argument apply to dropping lnt runtest -cflags or lnt runtest -cppflags: they also both could be set using -D?  
>> Anyway, let's not go there as part of this patch; I'll first look into whether I can eliminate the need for opts.cc and opts.cxx also for the non-cross-compiling case. In that case, I indeed no longer see the need for a separate option so that lnt is aware we're cross-compiling, and instead we can just use -D.  
>  
> My argument would be to drop the whole "lnt runtest" mode and let users do the cmake/ninja/lit sequence themselfes and teach "lnt submit" to just submit the results. That way you are never limited by missing or confusing options in lnt runtest, have one layer less to debug and we have one thing less to maintain and keep up to date. Though we may need to write more documentation about the cmake/lit test-suite.  

Interesting idea, I like it! When I explain others (non-LLVM-developers) about what lnt is, the first thing I explain is that it is both a tool to run the LLVM test-suite (which mostly isn't interesting to the non-LLVM-developers) and a server/database/analysis engine to keep track of code generation quality of a code generator (which is interesting to non-LLVM code generator developers). At least from this point of view, it'd be nice if lnt was "one thing" rather than "two things".  
Maybe 'lnt submit' could also be dropped, and users could upload the produced json after a lit run using e.g. curl? On one hand, submitting jsons to the server could be classified as being part of the "server/database/analysis engine" functionality. OTOH, it might remove the need for lnt on the client/test machine side completely?  


https://reviews.llvm.org/D29030  



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170125/7e32d827/attachment.html>