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

[David Blaikie]

On Thu, Sep 6, 2012 at 12:01 PM, Sean Silva <silvas at purdue.edu> wrote:
>> 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.

>From my configure/make + git build clang -v gives me:

./Release+Asserts/bin/clang -v
clang version 3.2 (trunk 163003) (llvm/trunk 163002)
Target: x86_64-unknown-linux-gnu
Thread model: posix

I'm not sure if this is the same as what a configure/make + svn build
would provide, but looks close/good enough. I dont' have an svn-based
build at the moment so you could make one yourself to check.

- David

>
> --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