Moving this back over to the list since I’m sure others have some input here. Also +lldb-dev since it has more visibility than lldb-commits.
Stepping one step back further in the thread …
Nothing concrete at the moment; however, it could be interesting to look at the clang community and see what could be done for llvm-based language implementations. The angle that I think would be interesting would be if we can generate bindings more effectively based on the in-depth understanding of the language that is afforded by languages built on top of LLVM. This is probably less interesting for Python (particularly since we have a functioning solution) and more interesting for languages built on LLVM or clang.
Honestly, though, I haven’t spent much time on that.
For the time being, I am going to not change the path for everyone on swig, and only use a static binding if swig cannot be found. This will be minimal impact for everyone and doesn’t interfere with anyone using a specific version of swig. We can revisit larger questions about who/what/when on static bindings after we gain some experience with enabling them for those who don’t have swig. We can review and adjust based on our collective experience. The two files this seems like it will be are the LLDBWrapPython.cpp and the lldb.py file that comes out of python. I hope to have this working in the next day or so.
that comes out of python
that comes out of swig, rather (i.e. the binding generation output).
Usage of static bindings for the prepare_bindings.py script went in here: r253448.
Only Xcode provides the flag to use it. The commit description indicates how it works in this incarnation. Essentially it only uses the static Python binding if and only if a swig isn’t specified or cannot be found.
I’ll be testing this on Ubuntu 14.04 and 15.10 in the morning. Once I have that working, I’ll provide a cmake flag to vector over to it, defaulting to not do so.
-Todd
Nothing concrete at the moment; however, it could be interesting to look at the clang community and see what could be done for llvm-based language implementations. The angle that I think would be interesting would be if we can generate bindings more effectively based on the in-depth understanding of the language that is afforded by languages built on top of LLVM. This is probably less interesting for Python (particularly since we have a functioning solution) and more interesting for languages built on LLVM or clang.
Honestly, though, I haven’t spent much time on that.
For the time being, I am going to not change the path for everyone on swig, and only use a static binding if swig cannot be found. This will be minimal impact for everyone and doesn’t interfere with anyone using a specific version of swig. We can revisit larger questions about who/what/when on static bindings after we gain some experience with enabling them for those who don’t have swig. We can review and adjust based on our collective experience. The two files this seems like it will be are the LLDBWrapPython.cpp and the lldb.py file that comes out of python. I hope to have this working in the next day or so.
To try this another way, I really would like to voice my opinion very very strongly for moving away from having different ways of doing things for different platforms / build configurations / etc unless it is required to support a hard requirement of someone’s environment.
Here’s our current configuration matrix.
Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)
Build Systems: CMake, Xcode
SWIG version: 1.3x, latest
Python version: None, 2.7, 3.x (in progress)
SWIG Binding Generation: on-the-fly, static (proposed)
In all of these cases (except the proposed), the matrix choices are justifiable because they are there to support a hard requirement of someone’s environment, and I do not think we should grow for anything that is not also a hard requirement of someone’s environment. We definitely should not grow it out of convenience, and especially not if it’s only a minor convenience. So I still am looking for a clear answer regarding what problem this is solving. Is not having a swig binary on every machine a hard requirement? You said
We can revisit larger questions about who/what/when on static bindings after we gain some experience with enabling them for those who don’t have swig"
And my question is, who doesn’t have swig? Maybe there is a legitimate use case, I just want to understand what that is before we add more different ways of building.
I mentioned earlier that one way there would be a definite tangible benefit is if we could use these static bindings in conjunction with a swig bot that would automatically generate swig on a remote server and send you back the result. This way we could remove one item from the configuration matrix, which I think we all agree is a good thing based on the fact that the original idea was to get everyone on 1.3x (which isn’t possible since it doesn’t work well with Python 3.5). Compare:
Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)
Build Systems: CMake, Xcode
SWIG version: 1.3x, latest
Python version: None, 2.7, 3.x (in progress)
SWIG Binding Generation: on-the-fly, static
with
Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)
Build Systems: CMake, Xcode
Python version: None, 2.7, 3.x (in progress)
The latter is much better, right? Can we discuss whether this swig server is a viable solution for getting to a single system that works for everyone? Again, I’m willing to do the brunt of the work getting it up and running if it is (I can probably reuse the portion of work you’ve already done related to running swig on the input files)
If the goal is just some kind of cleanup where it would be nice to not have to install swig, I’m specifically arguing against that, because I don’t think that’s a strong enough case to add one item to the configuration matrix.
+1
Checking in the static bindings is no different than projects checking in autoconf config baked scripts so that the vast majority of people don’t need to run autoconf just to get a setup that rarely changes. There is precedent for this going back a long way on open source projects.
I’m backing off having anyone else use them if they don’t want, and we (Apple) will keep those up to date. Nobody else will use them. Totally fine.
On the swig-as-a-service front, I think the idea is interesting but there are several practical holes with that:
-
What does one do when the server is unavailable? Needs to be a local-only backup. So whatever service that provides isn’t a guaranteed working solution (think on an airplane, network outage, other server outage, etc.)
-
Security: building code that has other code injected in it by another server. Safe? Attack vector? I could argue so is a git/svn repo susceptible to this, so maybe this isn’t a huge deal, but it’s big enough and smells enough like “introduce random unvetted code that can’t be reviewed as easily as a VCS tag” that I doubt we would ever use this in practice.
-
Security 2: what is the service really running? Not obvious on the build machine accessing the service.
In all of these cases (except the proposed), the matrix choices are justifiable because they are there to support a hard requirement of someone’s environment, and I do not think we should grow for anything that is not also a hard requirement of someone’s environment.
I’m going to call that overreaching. We are not in the business of dictating that one of the developers of the code “should not do something unless there is a hard requirement.” Apple wants to eliminate the need for people to require swig. The goal there is reducing the build requirements for the average person building lldb, not growing it.
Saying that “you hit a server for bindings as part of the build” is way different and more onerous than saying “hey we don’t want you to require to have swig to build lldb.” Those are miles apart.
And my question is, who doesn’t have swig? Maybe there is a legitimate use case, I just want to understand what that is before we add more different ways of building.
Swig is not a component that comes pre-installed on most public systems. Almost nobody has it unless something they do says “you need to have this.” So for a casual developer who is not a hardcore lldb developer, on a new system/VM, they are not going to just have swig. On OS X, it is a pain to get unless you install homebrew/macports/fink. On Linux, you’ll need to do an apt-get or yum install.
So I would flip that question around and say “who has swig unless something requires it?” And I’m creating a way to not require it. That sounds a lot more like a reduction in requirements for most build scenarios and most people who would download and build lldb.
So for the more common, casual lldb build environment where the developer is not touching SB API, help me understand how reducing the need for swig (without introducing the need for hitting another server) is increasing the requirement load? (Especially if we — our local dev group sitting by me — maintains those static bindings)?
On OS X, it is a pain to get unless you install homebrew/macports/fink. On Linux, you’ll need to do an apt-get or yum install.
And I should add that installing home-brew (the most common way of picking up extra goodies, as I know I do it on home machines) is also one of the most common ways to prevent lldb from building correctly and usably on OS X. (Particularly with the way its introduction of an alternative python and its placement on the lookup path will totally bork a system or hand-built lldb).
Checking in the static bindings is no different than projects checking in autoconf config baked scripts so that the vast majority of people don’t need to run autoconf just to get a setup that rarely changes. There is precedent for this going back a long way on open source projects.
I’m backing off having anyone else use them if they don’t want, and we (Apple) will keep those up to date. Nobody else will use them. Totally fine.
On the swig-as-a-service front, I think the idea is interesting but there are several practical holes with that:
- What does one do when the server is unavailable? Needs to be a local-only backup. So whatever service that provides isn’t a guaranteed working solution (think on an airplane, network outage, other server outage, etc.)
Security: building code that has other code injected in it by another server. Safe? Attack vector? I could argue so is a git/svn repo susceptible to this, so maybe this isn’t a huge deal, but it’s big enough and smells enough like “introduce random unvetted code that can’t be reviewed as easily as a VCS tag” that I doubt we would ever use this in practice.
Security 2: what is the service really running? Not obvious on the build machine accessing the service.
The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py that you check into the repo. You still have a chance to diff this source code against the repository’s copy before committing, same as you would if you had swig locally. Vast majority of changes to SB interfaces are going to be the addition of a couple methods, or maybe a class, and the diff should be very easy to look at and understand.
In all of these cases (except the proposed), the matrix choices are justifiable because they are there to support a hard requirement of someone’s environment, and I do not think we should grow for anything that is not also a hard requirement of someone’s environment.
I’m going to call that overreaching. We are not in the business of dictating that one of the developers of the code “should not do something unless there is a hard requirement.”
I’m not saying you shouldn’t do anything if there’s not a hard requirement. I agree that’s overreaching. I’m saying we should not increase the number of ways of doing the same thing unless there is a hard requirement. Especially if one of the ways of doing the same thing exists solely to save someone from running one command to install the package (sorry if I’m not doing justice to how difficult it is on OSX, the last time I did something on OSX it seemed fairly easy to install macports, and I thought it’s a wildly common thing for people to already have installed). For example, wouldn’t people need to already have macports in order to install CMake – a necessary component of building LLVM?
Apple wants to eliminate the need for people to require swig. The goal there is reducing the build requirements for the average person building lldb, not growing it.
I agree, which is why it is so important to keep the number of different ways of building to a minimum. It’s the same reason that the autoconf build is being removed wholesale from LLVM and people have decided that CMake is the one true way. Because even if it isn’t perfect for everyone, it works for everyone. And there is inherent simplicity in having fewer ways to do things, as well as reducing maintenance cost.
So for the more common, casual lldb build environment where the developer is not touching SB API, help me understand how reducing the need for swig (without introducing the need for hitting another server) is increasing the requirement load? (Especially if we — our local dev group sitting by me — maintains those static bindings)?
Well, we would need to disable static bindings on the OSX buildbots for starters, otherwise when someone not using static bindings makes a change, the buildbots break, and we cannot leave buildbots in a broken state. So I assume that will still be possible. So now you don’t have a buildbot testing the static binding configuration.
Secondly, LLDB already has a problem (IMHO) of having too many things that only work for a few people, instead of having things that work for everyone. It’s gotten better, and even your work right now to port the Xcode build over to these new python scripts is helping to make that better. So regardless of the outcome here, the end result will still be an improvement over before when Xcode build was using the shells cripts and CMake build was using python scripts.
But I still think it’s important to take a hardline against introducing new build configurations. Static vs on-the-fly bindings are going to need different logic for getting the resulting code into the place where it can be compiled / imported, different logic for creating the symlinks, etc. And now we’re duplicating effort when one person changes the logic on their side but not the other side.
I guess if this entire thing is hidden away in the Xcode build and everyone using the Xcode build wants things to work this way then I can’t really argue with that, but I don’t think we should provide the option to use static bindings in the CMake build. (If anyone who uses the CMake build disagrees though, please speak up)
Checking in the static bindings is no different than projects checking in autoconf config baked scripts so that the vast majority of people don’t need to run autoconf just to get a setup that rarely changes. There is precedent for this going back a long way on open source projects.
I’m backing off having anyone else use them if they don’t want, and we (Apple) will keep those up to date. Nobody else will use them. Totally fine.
On the swig-as-a-service front, I think the idea is interesting but there are several practical holes with that:
- What does one do when the server is unavailable? Needs to be a local-only backup. So whatever service that provides isn’t a guaranteed working solution (think on an airplane, network outage, other server outage, etc.)
Security: building code that has other code injected in it by another server. Safe? Attack vector? I could argue so is a git/svn repo susceptible to this, so maybe this isn’t a huge deal, but it’s big enough and smells enough like “introduce random unvetted code that can’t be reviewed as easily as a VCS tag” that I doubt we would ever use this in practice.
Security 2: what is the service really running? Not obvious on the build machine accessing the service.
The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py that you check into the repo. You still have a chance to diff this source code against the repository’s copy before committing, same as you would if you had swig locally. Vast majority of changes to SB interfaces are going to be the addition of a couple methods, or maybe a class, and the diff should be very easy to look at and understand.
In all of these cases (except the proposed), the matrix choices are justifiable because they are there to support a hard requirement of someone’s environment, and I do not think we should grow for anything that is not also a hard requirement of someone’s environment.
I’m going to call that overreaching. We are not in the business of dictating that one of the developers of the code “should not do something unless there is a hard requirement.”
I’m not saying you shouldn’t do anything if there’s not a hard requirement. I agree that’s overreaching. I’m saying we should not increase the number of ways of doing the same thing unless there is a hard requirement. Especially if one of the ways of doing the same thing exists solely to save someone from running one command to install the package (sorry if I’m not doing justice to how difficult it is on OSX, the last time I did something on OSX it seemed fairly easy to install macports, and I thought it’s a wildly common thing for people to already have installed). For example, wouldn’t people need to already have macports in order to install CMake – a necessary component of building LLVM?
CMake vends binary packages on OS X, along with installation instructions, so actually, you don’t need hombrew to get CMake on OS X. On my work machines, I actually don’t have it installed at all.
Apple wants to eliminate the need for people to require swig. The goal there is reducing the build requirements for the average person building lldb, not growing it.
I agree, which is why it is so important to keep the number of different ways of building to a minimum. It’s the same reason that the autoconf build is being removed wholesale from LLVM and people have decided that CMake is the one true way. Because even if it isn’t perfect for everyone, it works for everyone. And there is inherent simplicity in having fewer ways to do things, as well as reducing maintenance cost.
So for the more common, casual lldb build environment where the developer is not touching SB API, help me understand how reducing the need for swig (without introducing the need for hitting another server) is increasing the requirement load? (Especially if we — our local dev group sitting by me — maintains those static bindings)?
Well, we would need to disable static bindings on the OSX buildbots for starters, otherwise when someone not using static bindings makes a change, the buildbots break, and we cannot leave buildbots in a broken state. So I assume that will still be possible. So now you don’t have a buildbot testing the static binding configuration.
Secondly, LLDB already has a problem (IMHO) of having too many things that only work for a few people, instead of having things that work for everyone. It’s gotten better, and even your work right now to port the Xcode build over to these new python scripts is helping to make that better. So regardless of the outcome here, the end result will still be an improvement over before when Xcode build was using the shells cripts and CMake build was using python scripts.
But I still think it’s important to take a hardline against introducing new build configurations. Static vs on-the-fly bindings are going to need different logic for getting the resulting code into the place where it can be compiled / imported, different logic for creating the symlinks, etc. And now we’re duplicating effort when one person changes the logic on their side but not the other side.
I guess if this entire thing is hidden away in the Xcode build and everyone using the Xcode build wants things to work this way then I can’t really argue with that, but I don’t think we should provide the option to use static bindings in the CMake build. (If anyone who uses the CMake build disagrees though, please speak up)
lldb-dev mailing list
lldb-dev@lists.llvm.org
lldb-dev Info Page
Thanks,
- Enrico
egranata@.com 
27683
Checking in the static bindings is no different than projects checking in
autoconf config baked scripts so that the vast majority of people don't
need to run autoconf just to get a setup that rarely changes. There is
precedent for this going back a long way on open source projects.I'm backing off having anyone else use them if they don't want, and we
(Apple) will keep those up to date. Nobody else will use them. Totally
fine.On the swig-as-a-service front, I think the idea is interesting but there
are several practical holes with that:* What does one do when the server is unavailable? Needs to be a
local-only backup. So whatever service that provides isn't a guaranteed
working solution (think on an airplane, network outage, other server
outage, etc.)* Security: building code that has other code injected in it by another
server. Safe? Attack vector? I could argue so is a git/svn repo
susceptible to this, so maybe this isn't a huge deal, but it's big enough
and smells enough like "introduce random unvetted code that can't be
reviewed as easily as a VCS tag" that I doubt we would ever use this in
practice.* Security 2: what is the service really running? Not obvious on the
build machine accessing the service.The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py
that you check into the repo.
Ah, I see. That definitely sounds like an improvement from my
interpretation 
You still have a chance to diff this source code against the repository's
copy before committing, same as you would if you had swig locally.
Yeah, non-issue at that point.
Vast majority of changes to SB interfaces are going to be the addition of
a couple methods, or maybe a class, and the diff should be very easy to
look at and understand.
Yes.
> In all of these cases (except the proposed), the matrix choices are
justifiable because they are there to support a hard requirement of
someone's environment, and I do not think we should grow for anything that
is not also a hard requirement of someone's environment.I'm going to call that overreaching. We are not in the business of
dictating that one of the developers of the code "should not do something
unless there is a hard requirement."I'm not saying you shouldn't do *anything* if there's not a hard
requirement. I agree that's overreaching. I'm saying we should not
increase the number of ways of doing *the same thing* unless there is a
hard requirement. Especially if one of the ways of doing the same thing
exists solely to save someone from running one command to install the
package (sorry if I'm not doing justice to how difficult it is on OSX, the
last time I did something on OSX it seemed fairly easy to install macports,
and I thought it's a wildly common thing for people to already have
installed). For example, wouldn't people need to already have macports in
order to install CMake -- a necessary component of building LLVM?
In the case of cmake, no. The cmake website provides a simple-to-add binary
that doesn't depend on anything else. (Okay, I'm long winded here so
Enrico just beat me to the punch).
For swig, the solution is homebrew/macports. The challenge with systems
like homebrew and macports is that they will install other packages that
are dependencies (sometimes build-time, sometimes runtime), typically get
them added to various paths, and (during the process), unintentionally hide
system libraries. It is not uncommon for us to see crash reports on OS X
where Xcode or lldb is picking up the wrong python or other component that
was built by one of these package managers. They're often good about
saying "this might cause trouble" in some obvious cases, but less so in
less obvious cases (like, a swig installing python bindings, which installs
a new shiny python, which hides the system one, which breaks the lldb
bindings). It really is messier there.
Apple wants to eliminate the need for people to *require* swig. The
goal there is reducing the build requirements for the average person
building lldb, not growing it.I agree, which is why it is so important to keep the number of different
ways of building to a minimum.
Glad to hear the intent here.
It's the same reason that the autoconf build is being removed wholesale
from LLVM and people have decided that CMake is the one true way.
(Coincidentally - I am in the process of trying to eliminate the old
make-swig-bindings.sh, which is still used by the Makefile/autoconf build
of lldb, and I saw the nice banner from llvm saying autoconf support is
going out for 3.9 while testing the replacement).
Because even if it isn't perfect for everyone, it works for everyone.
Unless you can't get swig on your system in a way that doesn't break other
items. And then it doesn't work (as things stand now).
And there is inherent simplicity in having fewer ways to do things, as
well as reducing maintenance cost.So for the more common, casual lldb build environment where the developer
is not touching SB API, help me understand how reducing the need for swig
(without introducing the need for hitting another server) is increasing the
requirement load? (Especially if we --- our local dev group sitting by me
--- maintains those static bindings)?Well, we would need to disable static bindings on the OSX buildbots for
starters, otherwise when someone not using static bindings makes a change,
the buildbots break, and we cannot leave buildbots in a broken state. So I
assume that will still be possible. So now you don't have a buildbot
testing the static binding configuration.
I was actually going to add a verifier stage to the public OS X buildbot.
Secondly, LLDB already has a problem (IMHO) of having too many things that
only work for a few people, instead of having things that work for
everyone. It's gotten better, and even your work right now to port the
Xcode build over to these new python scripts is helping to make that
better. So regardless of the outcome here, the end result will still be an
improvement over before when Xcode build was using the shells cripts and
CMake build was using python scripts.But I still think it's important to take a hardline against introducing
new build configurations. Static vs on-the-fly bindings are going to need
different logic for getting the resulting code into the place where it can
be compiled / imported, different logic for creating the symlinks, etc.
Yep - it was in the vicinity of 25 lines of python. An extra option to say
"okay, only try this if there is no swig found", a few lines around "if we
can't find a swig, and we say it's okay to copy the static bindings, then
do it, otherwise fail", and a method to copy over the LLDBWrapPython.cpp
and lldb.py files.
And now we're duplicating effort when one person changes the logic on
their side but not the other side.
I'll offer again that we'll take care of the static bindings. It's on us
if they're broken.
I guess if this entire thing is hidden away in the Xcode build and
everyone using the Xcode build wants things to work this way then I can't
really argue with that, but I don't think we should provide the option to
use static bindings in the CMake build. (If anyone who uses the CMake
build disagrees though, please speak up)
My intent here is to only provide the --allow-static-binding option on
cmake if it is explicitly turned on. And it will be off by default.
Tell me more about the service idea. How would you envision it working?
I know, but I don’t really like adding options that nobody is going to use, because it makes maintaining the build files more difficult, and when people ask questions on the list about how to use various options, chances are nobody is going to know because there’s nobody maintaining that codepath. So I lean on the side of not even having the option. There’s already a bunch of paths in the CMake build that don’t even work because they’re not maintained and nobody uses them. I’d actually like to go through and remove that complexity from the CMake build at some point.
Well, pretty much like I described earlier. I write a python script, called swig-bot.py. You run it like this (I’ve fabricated an example of what the output of the tool might look like):
~/lldb$ scripts/swig-bot.py --lang Python --outdir scripts/Python/bindings scripts/lldb.swig
swig-bot packaging up input files
scripts/lldb.swig
scripts/SBAddress.i
scripts/SBAttachInfo.i
scripts/SBBlock.i
scripts/SBBreakpoint.i
scripts/SBBreakpointLocation.i
scripts/SBBroadcaster.i
scripts/SBCommandInterpreter.i
scripts/SBCommandReturnObject.i
scripts/SBCommunication.i
scripts/SBCompileUnit.i
scripts/SBData.i
scripts/SBDebugger.i
…
transmitting input files…
awaiting response…
Generation
Output: scripts/Python/bindings/LLDBWrapPython.cpp
Output: scripts/Python/bindings/lldb.py
Now you add the 2 output files to your CL, diff them to verify sanity, and submit.
Is that a real issue that people on OSX are facing now? Because I thought having SWIG installed on your system has been a requirement for the past N years. Did something change recently that now makes it impossible to install swig in a way that doesn’t break something?
I’m not sure I follow this point. What would your verifier stage do? I’m imagining the following scenario:
I check in some changes to SWIG interface files at like 10PM. Ignoring the fact that you and Jason are usually up firing commits away until the wee hours of the morning, let’s pretend nobody sees this until the morning. So the build bot has been broken all night. Is this something that is going to happen under this scenario?
(This is originally from a thread on lldb-commits, but it seems more appropriate here, so I’m responding here.
Because even if it isn't perfect for everyone, it works for everyone.
Unless you can't get swig on your system in a way that doesn't break
other items. And then it doesn't work (as things stand now).Is that a real issue that people on OSX are facing now? Because I thought
having SWIG installed on your system has been a requirement for the past N
years. Did something change recently that now makes it impossible to
install swig in a way that doesn't break something?
This is changing for a large class of people.
And there is inherent simplicity in having fewer ways to do things, as
well as reducing maintenance cost.So for the more common, casual lldb build environment where the
developer is not touching SB API, help me understand how reducing the need
for swig (without introducing the need for hitting another server) is
increasing the requirement load? (Especially if we --- our local dev group
sitting by me --- maintains those static bindings)?Well, we would need to disable static bindings on the OSX buildbots for
starters, otherwise when someone not using static bindings makes a change,
the buildbots break, and we cannot leave buildbots in a broken state. So I
assume that will still be possible. So now you don't have a buildbot
testing the static binding configuration.I was actually going to add a verifier stage to the public OS X buildbot.
I'm not sure I follow this point. What would your verifier stage do? I'm
imagining the following scenario:I check in some changes to SWIG interface files at like 10PM. Ignoring
the fact that you and Jason are usually up firing commits away until the
wee hours of the morning, let's pretend nobody sees this until the
morning. So the build bot has been broken all night. Is this something
that is going to happen under this scenario?
You can more or less ignore that point.
The intent is to alert those who update the static bindings (i.e. Apple
LLDB team) that the bindings generated and post processed from swig are not
matching the static ones. This would just get sent to an internal group
over here since I'm not hearing definite resistance to moving to a
static-by-default model. (If we had gone static-by-default, and made it
clean and explicit when modifying the SB API surface area by requiring an
update-the-binding step, there would have been no way to test the bindings
without having done the "update the bindings" step. Since we won't be
doing that, then I need some way to ensure I know bindings are stale).
That's really a detail you won't need to worry about, though, since you
will not be using static bindings ever, and won't have to address any time
they go stale. The fact that it happens on a public builder is not very
interesting either. I worded it in a way that made it sound like others
externally would see the staleness alert, but that's not what I meant.
(I may automate that later, but not until I make sure it works manually up
front).
Because even if it isn't perfect for everyone, it works for everyone.
Unless you can't get swig on your system in a way that doesn't break
other items. And then it doesn't work (as things stand now).Is that a real issue that people on OSX are facing now? Because I
thought having SWIG installed on your system has been a requirement for the
past N years. Did something change recently that now makes it impossible
to install swig in a way that doesn't break something?This is changing for a large class of people.
But more importantly, swig has never been easy to get on OS X except via
macports/fink. Apple's internal toolchain has an ancient swig available
that we use, but we don't distribute that one.
(This is originally from a thread on lldb-commits, but it seems more
appropriate here, so I'm responding here.BTW if you cook up something on the swig-as-a-service end that ends up
working to eliminate the need for swig, I'll be happy to remove the static
binding support at that point.-Todd
Err, rewind. If we have the swig as a service, then I think the static
binding does have value.
Yes, but in the context of what is useful for that workflow. Not
necessarily the way I'm doing it. (Or maybe so).
Because I don't want to hit the network every single time I build, so it
mostly solves the issue you mentioned about network connectivity, because
building LLDB doesn't require a network connection unless you touch a swig
interface file.The thing I would like some guidance on from the Apple side is this: If I
make the swig service, can you (and will you) use code generated by swig
3.x? If not, there's no value in the swig service.
We have no issue using code that has no additional licensing requirements
last time I verified. And there are no additional licensing requirements
added by swig 3.x generation from what their website says (and my
non-official interpretation of it). So I am pretty confident we can get
the answer here to be yes.