I am AFK and this is quite clearly not a trivial failure for me to fix
I added a few new functions to the SWIG wrapper and that seems to confuse the windows build
Ideas?
Taking a look right now. I have about 30 minutes to spare tonight, if it takes longer than that I might ask that we revert for now, but I will get on it in the morning.
Well the git clone appears out of sync with the svn master. Not really sure what to do about that but when I pull, the most recent revision is from 12:30 this morning.
So I can’t even pull your revision to test it. I forced a clean of the builder, I will check it in a little bit to see if that fixed the issue. If it didn’t I will probably need to revert until we figure out what’s going on.
Of course I am not very excited about a revert
It’s not a big deal, but alas I still will need help getting this to work on Windows in the morning, and it seems having the patch applied would be as good a starting point as any
With that said, I did break the build, so I don’t really get to complain 
I did manage to get synced to tip. I’m still not sure what the deal is with the git clone, but in any case I can repro the problem now. So now I will take a look for real
Ok now that I managed to repro it, I think my solution of cleaning will actually work. The problem appears to be that in the CMake, we don’t have python-wrapper.swig as a dependency on re-generating LLDBWrapPython.cpp. So you changed python-wrapper.swig and it didn’t re-generate the cpp file. The clean will take care of it for now, and I’ll try to fix the CMake tomorrow.
I’m still not sure who to talk to about the git repository though, maybe it’ll work itself out by tomorrow.
Thanks for looking!
The Linux configure+make builders are also broken. Do you think a clean build will help there?
Most likely. My make skills are pretty non-existant, but I don’t see anything that looks like it would have created a dependency between the swig input file and running the generation script. All I see is this:
LLDBWrapPython.cpp lldb.py: $(PROJ_SRC_DIR)/$(LLDB_LEVEL)/scripts/Python/modify-python-lldb.py
$(wildcard $(PROJ_SRC_DIR)/$(LLDB_LEVEL)/scripts/Python/interface/*.i)
$(Echo) Generating LLDBWrapPython.cpp
$(Verb) “$(PROJ_SRC_DIR)/$(LLDB_LEVEL)/scripts/build-swig-wrapper-classes.sh” “$(PROJ_SRC_DIR)/$(LLDB_LEVEL)” “$(PROJ_OBJ_DIR)” “$(PROJ_OBJ_DIR)” “$(PYTHON_DIR)” -m $(if $(DISABLE_AUTO_DEPENDENCIES),-M)
$(Verb) “$(PROJ_SRC_DIR)/$(LLDB_LEVEL)/scripts/finish-swig-wrapper-classes.sh” “$(PROJ_SRC_DIR)/$(LLDB_LEVEL)” “$(PROJ_OBJ_DIR)” “$(PROJ_OBJ_DIR)” “$(PYTHON_DIR)” -m
If you want to force a clean, then on the web interface for the builder, there will be boxes that say Property 1, Property 2, Property 3, etc. For Property 1 use set the property name to clean and the value to True
Thanks - I just did this for the FreeBSD build, which broke in the same way.
Unfortunately it seems it didn't work. I'll take another look if it
still fails after the explicit dependency is there.
We’re now also getting a compiler warning in the generated code:
tools/lldb/scripts/LLDBWrapPython.cpp:63676:20: warning: implicit conversion of NULL constant to 'bool' [-Wnull-conversion]
Any idea how to clear that up?
For the warning, you will need to silence it since we can’t control the generated code.
For Ed, it’s possible your builder doesn’t support the “clean” property? Because cleaning definitely should fix it if it’s the same error. Anyway I’ll try to fix the cmake later
It's possible I suppose, but the builder was set up by Galina and I
suspect should be the same as others.
It does use configure+make though, and is still broken -- I suspect we
need an explicit dependency in a Makefile as you did for cmake. I'm at
a conference now and probably won't have a chance to address it the
short term, but will take a look later if nobody beats me to it.