[LLVMdev] LNT: failing to parse compiler info: what am I doing wrong?

[Sean Silva]

> And it doesn't match probably because of one of two things (& I forget
> which of the two, if either, have been addressed/workaround):
>
> 1) using cmake instead of configure/make
> 2) using git instead of svn
>
> One or both of these create versions that lnt doesn't understand
> (because they don't include the SVN revision number in the clang
> version info) - if I recall correctly.

Yup, that sounds like the problem. I'm using CMake AND git :)

> Yes, LNT could probably be improved not to completely fall over on
> this, and/or the different build systems/vcs could be improved to play
> more nicely by providing better version info.

I'll see if I can patch it up. For reference, can you give me an
example of the output that it is expecting (e.g clang -v)? I can kind
of make it out from the regexes that it is matching, but it would be
nice to see a "-v" output that works. It looks like it also is reading
'-###' output, but it's kind of spewy and I don't think that's the
problem.

This is what clang -v gives for me:

clang version 3.2
Target: x86_64-unknown-linux-gnu
Thread model: posix

It looks like it wants the version line to be something like the form

clang version (r123456) 3.2

or something like that.

--Sean Silva

On Thu, Sep 6, 2012 at 12:58 AM, David Blaikie <dblaikie at gmail.com> wrote:
> On Wed, Sep 5, 2012 at 7:23 PM, Sean Silva <silvas at purdue.edu> wrote:
>> Hi, I'm trying to use LNT to run the test-suite. I followed the
>> instructions on <http://lnt.llvm.org/quickstart.html>. When I run it I
>> get this error:
>>
>> (mysandbox)sean:~/pg/others/llvm % lnt runtest nt --sandbox mysandbox
>> --cc ~/pg/others/llvm/release/bin/clang --test-suite test-suite
>> nt.py:1185: note: inferred C++ compiler under test as:
>> '/home/sean/pg/others/llvm/release/bin/clang++'
>> 2012-09-06 02:03:16: checking source versions
>> compilers.py:81: error: unable to determine compiler version:
>> '/home/sean/pg/others/llvm/release/bin/clang': 'clang version 3.2 '
>> Traceback (most recent call last):
>>   File "/home/sean/pg/others/llvm/mysandbox/bin/lnt", line 9, in <module>
>>     load_entry_point('LNT==0.4.1dev', 'console_scripts', 'lnt')()
>>   File "/home/sean/pg/others/llvm/lnt/lnt/lnttool/main.py", line 281, in main
>>     commands[cmd](cmd, args[1:])
>>   File "/home/sean/pg/others/llvm/lnt/lnt/lnttool/main.py", line 149,
>> in action_runtest
>>     report = test_instance.run_test('%s %s' % (name, test_name), args)
>>   File "/home/sean/pg/others/llvm/lnt/lnt/tests/nt.py", line 1288, in run_test
>>     report = run_test(nick, opts, None, report_dir)
>>   File "/home/sean/pg/others/llvm/lnt/lnt/tests/nt.py", line 645, in run_test
>>     target_flags)
>>   File "/home/sean/pg/others/llvm/lnt/lnt/testing/util/compilers.py",
>> line 82, in get_cc_info
>>     cc_name,cc_version_num,cc_build_string,cc_extra = m.groups()
>> AttributeError: 'NoneType' object has no attribute 'groups'
>>
>> I took a look at the code and basically it's doing some nasty ad-hoc
>> regex parsing to try to figure out the compiler version and when the
>> regex doesn't match,
>
> And it doesn't match probably because of one of two things (& I forget
> which of the two, if either, have been addressed/workaround):
>
> 1) using cmake instead of configure/make
> 2) using git instead of svn
>
> One or both of these create versions that lnt doesn't understand
> (because they don't include the SVN revision number in the clang
> version info) - if I recall correctly.
>
> Yes, LNT could probably be improved not to completely fall over on
> this, and/or the different build systems/vcs could be improved to play
> more nicely by providing better version info.
>
>> the re library returns None, which it later dies
>> on. I'm no stranger to Python and would be happy to hack around this,
>> but I find it strange that a vanilla Clang is causing this to barf,
>> since presumably clang is the most heavily used; and there's even code
>> in there for pulling out versions from GCC and ICC!
>>
>> Am I doing something wrong? It certainly feels like I'm doing
>> something wrong. If not I'll hack around it and send in a patch.
>>
>> I'd be glad to provide clang output (e.g. -v) if it would help to
>> understand the problem; just let me know what you want, since I'm not
>> sure exactly what would be most helpful.
>>
>> Another thing: aren't those calls to `error()` in compilers.py
>> supposed to abort the processing immediately? I mean, it does a None
>> check, calls `error()` and prints an error message, and then barfs
>> executing code that assumes that the match object is not None. The
>> C/C++ equivalent would be:
>>
>> if (p == NULL)
>>   error("p is NULL"); // Just prints, doesn't longjmp or throw an
>> exception or anything.
>> do_something(p->foo);
>>
>>
>> --Sean Silva
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev