On Mar 23, 2012, Xiaofan Chen <[email protected]> wrote: > > > On Sat, Mar 24, 2012 at 4:05 AM, P. Martin <[email protected]> wrote: > > > > Ahh, I didn't notice the two branches. Now I see what's happened. > > Thank you for explaining that. In the case where a fix that exists in > > head won't be backported to stable, the Homebrew maintainers > > will wait for a new version that does work. > > What do you mean by that? You can always pick the patch > and include that with your homebrew formula, right?
If the python bindings are not desirable, then we can drop all this and let Homebrew just use configure. But the problem is that you have python bindings, and I'm under the impression that you want those to work. Those only work when I build with cmake, not configure. I'm also under the impression that the 0.2x branch is the main one that people use, it's current, and it's good. So yes, I could figure out the three patches it takes to fix lib64 in your cmake build scripts, or I could make my own patch. Five months ago, that is what I did. I submitted a pull request to upgrade libftdi from 0.17 to 0.19, switch from configure to cmake, add python support, fix lib64, and install the docs. My request was left open for four months, during which time the Homebrew admins waited for a new version. https://github.com/mxcl/homebrew/pull/8351 The new version came out at 0.20, with no fixes. They decided to go with the current formula that uses configure and to not use my formula. Configure can't compile the python bindings, but at least it's smart enough not to try to install to lib64. So what they got was a formula that builds with no changes to the formula other than the tarball and sha1. https://github.com/mxcl/homebrew/pull/10132 But I feel the formula is not correct because configure fails to build the python bindings. If I patch the formula to change from configure to cmake so it can build the python bindings, and patch it to fix lib64, the request will sit open for another half a year while they wait to see if someone mentions the fix works or doesn't, or for a new stable with the patch. There is very little incentive for them to accept my pull request in the absence of any 'make check' to prove it works and the absence of proper hardware to test it themselves. So what they have is a formula that compiles, and they have no complaints about python bindings missing. It's all me who thinks your software should work as well as it can because I have a degree in Physics with A's in Analog Electronics, Digital Electronics, and Computer Interfacing. In Homebrew's opinion my changes are extreme, unproven, and annoying. Why are they annoying? It's because my patches have to be tested on Lion with 2 compilers, Snow Leopard with three compilers in 64bit or 32bit mode, and Leopard with three different compilers 32bit mode. That's a total of 11 different test phases for each option I put in the formula. The formula has an option to brew your python bindings or not. So that's two options on top of 11 tests, meaning 22 times this has to be reviewed, none of which times can we prove to ourselves it works, all on top of a working formula nobody is complaining about. Add to that people could use the system python or build their own Homebrew python is another two options. So now we are at 44 test runs. So faced with 'it just works and no complaints' versus 44 test phases only to have the patches break in a few months and have to start this all over again, the admins will continue to do what they have already done. Put my pull request on the bottom of 213 other open ones that are not in demand, complex, hard to test, or bound to break in a few months when the patches no longer apply correctly. Or libftdi could be fixed in 5 minutes by a few vcs commands. Maybe you see why I rewrote this 6 times over two days where it never comes out well. It's enormously complex on Homebrew's end to do what you think is just apply a patch. And even if we do, how does that help other people who don't use Homebrew? It doesn't. So it's not proper, and it's nearly impossible to explain that to developers. > If not, please update the Homebrew formula with a HEAD > option so that git head can be used. Thanks. > BTW, it seism the 0.20 formula has already been in. > I just ran "brew update" and fount out that. Yes indeed. I should probably take that as a clue to not try to alter the formula again, seeing as they chose that over my formula that enhanced libfti. Now that I think about it, I'm pretty sure I'm done with this. Homebrew doesn't care if I patch 0.2x, and libftdi doesn't care to either. -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
