This is an archive of the discontinued LLVM Phabricator instance.

Embed swig version into lldb.py in a different way
ClosedPublic

Authored by labath on Feb 13 2019, 3:45 AM.

Details

Summary

Instead of doing string chopping on the resulting python file, get swig
to output the version for us. The two things which make slightly
non-trivial are:

  • in order to get swig to expand SWIG_VERSION for us, we cannot use %pythoncode directly, but we have to go through an intermediate macro.
  • SWIG_VERSION is a hex number, but it's components are supposed to be interpreted decimally, so there is a bit of integer magic needed to get the right number to come out.

I've tested that this approach works both with the latest (3.0.12) and
oldest (1.3.40) supported swig.

Diff Detail

Repository
rLLDB LLDB

Event Timeline

labath created this revision.Feb 13 2019, 3:45 AM
labath updated this revision to Diff 186676.Feb 13 2019, 8:25 AM

Include a basic test for this functionality I forgot to add

Long term, I wonder if we can just delete this entire modify-python-lldb.py script. it seems like the entire purpose is to make sure that the SB methods support iteration, equality, and some other basic stuff, and it does this by inserting lines of python code into the actual __init__.py file. It seems like we could just have the swig file say %pythoncode%{import sb_iteration}, then write a file called sb_iteration.py which we ship alongside the __init__.py, and have it dynamically add all of the things it needs at runtime. Then, we don't even need a a post processing step at all, which seems like a definite improvement.

As for this particular change, another option is to just say:

%pythoncode%{
  swig_version = VERSION
}

There's no real reason we have to do the parsing here, we could do it in our dotest.py decorators. I don't have a strong preference on which is better though.

Yes, my long term plan is to try to get rid of this file altogether. Doing the hotpatching at runtime is an interesting idea. I may resort to that, but I think it would be better to add all of these as regular blocks of inline %pythoncode%, as that's how swig is meant to be used. However, i haven't looked at that too closely yet. I am trying to dismantle this one step at a time.

%pythoncode%{
  swig_version = VERSION
}

There's no real reason we have to do the parsing here, we could do it in our dotest.py decorators. I don't have a strong preference on which is better though.

Originally I thought this was a proper api that we deliberately wanted to export, and only later found out that this was added only to support test decorators. However, this gets exported as a public api nonetheless, and it sounds like the kind of thing that might be useful to somebody, so I think it's good to spend a bit of effort to present it in a nicer format. Besides, we're going to need to put the funny parsing code somewhere anyway, and putting it close to the source means we won't have to parse it twice.

zturner accepted this revision.Feb 14 2019, 11:19 AM
This revision is now accepted and ready to land.Feb 14 2019, 11:19 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2019, 11:42 PM