<div><br></div><div>| Do you have any information about how people are setting up their</div>| projects? I ask because there are different ways to set up a project<br>| to depend on LLVM.<div><br></div><div>No, I don't have that kind of information.  All I know is that it is quite difficult to find a working version on the trunk.  I think this especially hit those that are new to LLVM and yet want to play around with the bleeding edge version.</div>
<div><br></div><div>I think you are right about extracting the last green build using the JSON API instead of a LKG tarball.  I didn't know it existed and hardly know what it means.  JSON is some Java technology?  Is there any documentation of this anywhere?</div>
<div><br></div><div>Perhaps somebody will volunteer to write up a few pages on how to extract the last green build like you say?  That would be most helpful.</div><div><br><div class="gmail_quote">2012/11/5 Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Why is the LKG build so important?  Because in software development in<br>
> general, you want to reduce the "granularity" of the process as much as<br>
> possible, approximating a kurve rather than a series of steps.  If people<br>
> adopt LLVM v3.1 and then have to wait one year for another update (v3.2) in<br>
> which LOTS and LOTS of things have changed, they are in for a tough ride<br>
> when they want to upgrade to the new version.  If, on the other hand, they<br>
> can get a bi-weekly LKG build (assuming the entire build process on all<br>
> platforms only succeeds twice a week), they can adopt their code in very<br>
> small steps.<br>
<br>
</div>Do you have any information about how people are setting up their<br>
projects? I ask because there are different ways to set up a project<br>
to depend on LLVM.<br>
<br>
Probably the most robust is how the Rust language<br>
<<a href="https://github.com/mozilla/rust" target="_blank">https://github.com/mozilla/rust</a>> does it, which is to set up a git<br>
submodule which is pinned on a particular git commit; the revision<br>
that it is pinned on is actually for a fork<br>
<<a href="https://github.com/brson/llvm" target="_blank">https://github.com/brson/llvm</a>> of LLVM's main development which the<br>
Rust developers have made specifically for this purpose. I don't<br>
really track Rust, but from a quick browse, it looks like what they<br>
are doing is to periodically sync with upstream or cherry-pick<br>
specific bugfixes; they also put in some little fixes of their own. My<br>
impression is that this is really robust and flexible, since it allows<br>
them to sync with upstream at any granularity they want.<br>
<br>
Another possibility that a lot of projects do is to just rely on the<br>
"installed" version of LLVM, and just say 3.0+ or 3.1+. As you<br>
mentioned, this really is not very good, since LLVM really has no<br>
backwards compatibility policy they are in for a really rough ride<br>
when the next version comes out.<br>
<br>
One benefit of the Rust-style setup is that it allows you to easily<br>
set up a job on your own servers that automatically pulls the last<br>
green LLVM release (the buildbots have JSON API's which should allow<br>
extracting this) and merges it in and then tries to build your project<br>
with that. That way, you can stay up to date in a relatively automated<br>
fashion and can ping the list for help with migrating to new APIs near<br>
the time that the APIs are changed and not months later. Personally I<br>
think this is a better alternative than an LKG tarball.<br>
<br>
Overall, what you are hitting against is just a product of how LLVM is<br>
developed (very fast moving, straight-line SVN, highly-volatile trunk,<br>
with no backwards compatibility). Even though the code is nicely<br>
modularized and loosely-coupled so that in theory it is very nice and<br>
modular and easy to use as a library, the reality is that there is a<br>
very strong *developer coupling*, in that you have to really be aware<br>
of what is happening in the LLVM codebase or else your project will<br>
bitrot extremely quickly. Since LLVM doesn't maintain any kind of<br>
"migration guide" for its changes, you basically have to be an LLVM<br>
developer to fight the bitrot, or else have some kind of automated<br>
thing which will allow you to squawk on the mailing list for migration<br>
help while the change is still fresh.<br>
<br>
-- Sean Silva<br>
<div><div class="h5"><br>
On Sun, Nov 4, 2012 at 4:33 AM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org">mikael@lyngvig.org</a>> wrote:<br>
> Hi,<br>
><br>
> I have several times over the past three months tried to retrieve the trunk<br>
> version of LLVM/Clang/Compiler-RT from Subversion and then tried to build it<br>
> on Windows: Without success.  Also, I occasionally get emails from people<br>
> who ask me why LLVM/Windows does not build (they find my name in the mailing<br>
> list archive).<br>
><br>
> This has made me ponder the issue and I came up with the following scheme to<br>
> ensure that there is a high probability that we Windows users can actually<br>
> build the most recent version of LLVM:<br>
><br>
> 1. Every night, an automated build builds LLVM & Co. on all the supported<br>
> host platforms and runs the test suite to completion.<br>
> 2. IF the automated build succceds on ALL supported host platforms AND the<br>
> test suite succeeds, the build is marked as "Last Known Good" and<br>
> automatically published to the website so that people can download it<br>
> without using Subversion.  There should always only be one and only one Last<br>
> Known Good (LKG) build - which is sort of equivalent to a "daily tarball",<br>
> albeit it is known to build properly on all platforms.<br>
><br>
> I believe step 1 is already in place, but perhaps the project's build<br>
> master, or I, can put together some Python scripts to automate the process<br>
> of making a LKG build.<br>
><br>
> Why is the LKG build so important?  Because in software development in<br>
> general, you want to reduce the "granularity" of the process as much as<br>
> possible, approximating a kurve rather than a series of steps.  If people<br>
> adopt LLVM v3.1 and then have to wait one year for another update (v3.2) in<br>
> which LOTS and LOTS of things have changed, they are in for a tough ride<br>
> when they want to upgrade to the new version.  If, on the other hand, they<br>
> can get a bi-weekly LKG build (assuming the entire build process on all<br>
> platforms only succeeds twice a week), they can adopt their code in very<br>
> small steps.<br>
><br>
><br>
> Cheers and have a great day!<br>
><br>
> Mikael Lyngvig<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
</blockquote></div><br></div>