On 2009/08/09 19:30:28, jat wrote: > I haven't taken a look at this closely (I had read Aaron Boodman's blog about > the approach at
http://www.aaronboodman.com/2009/07/bundling-multiple-versions-of-binary.html > previously), but I am not sure this can detect all the cases we need to > differentiate. Thanks for the link. I hadn't read the blog post. > For example, on Fedora Core 10 FF3.0.11, the plugin needs to be linked against > different libraries (the ff3+ entry there now), and it isn't clear how we can > differentiate that in the JS stub from other FF3.0.11 builds that require the > ff3 libraries. We can still build a separate XPI for 64-bit FC 10 by invoking Make with the appropriate arguments. We can also include the libraries for all versions of Firefox for that platform in that XPI. > Also, given the other things that we need to get done for GWT 2.0 MS1, I am > leery of making such a major change that might distract from getting those > things done. Okay, but the changes are not as big as they might seem from the CL. Mostly it's just deleting unused files. The modifications and additions are pretty much: components/stub.js: the loader from Gears Makefile: outputs libraries in lib/<platform>/<ff-version> instead platform/<platform>. config.mk: one-line change to always build universal binaries on the mac > So, my inclination would be to wait on this until after all the other > OOPHM-related pieces are done for MS1 and if there is time left then we can > pursue it further. What are the OOPHM-related goals for MS1? I've found that having a single XPI made making changes to OOPHM much easier, since you can install a single extension and test on all versions of Firefox. That said, if you want to hold off on this, I can understand. http://gwt-code-reviews.appspot.com/56808 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
