On 9/9/2010 3:19 AM, Peter Rosin wrote: > Den 2010-09-09 06:18 skrev Charles Wilson: >> Peter, a question about your current patch series: with it only >> partially committed, do you expect errors? Are we waiting for some >> other change upon which the current series depends, before it all "just >> works" again...or are things fubared now? > > I wouldn't knowingly have committed anything half-assed like that. I > expected things to be better now that they were before.
Sorry, I just lost track of the thread of the various conversations. When you presented a chain of 7 patches, and then they weren't all committed simultaneously, I started to wonder (1-4, then later 5, then even later 6, and 7 still hasn't been). >> Right now, I'm seeing a regression just building libltdl. It builds >> correctly "the first time" -- but when I try to run the old test suite, >> a rule gets triggered to rebuild libltdl.al: >> >> I suspect that there is a mismatch between the targets (and deps) in the >> Makefile (and the .deps/*.P files), and the new pre-converted filenames >> being generated by $to_tool_file_cmd. > > That might very well be the cause, as I didn't think of that case at all. > > Well, it was broke, you just didn't notice that low max_cmd_len failed > in more ways than you assumed. That part is fixed. You're right. I didn't mean to sound so accusatory... >> I'm wondering if, when $build=MSYS, we could turn off all of the libtool >> to_tool_file_cmd stuff, EXCEPT when generating the contents of an @file. > > I agree, we should implement some kind of "lazy" strategy for MSYS, so > that we don't do any needless conversions. (I like lazy. Lazy is good.) >> You know, just fix the broken stuff....without breaking other, >> previously working, stuff? ...like this. At first, I thought *every* -exec test was broken, and I was quite flummoxed. But that was PIBKAC. After a clean rebuild, I saw that it was "only" the ever-painful mdemo-*-exec tests that were failing (along with new mdemo-*-make test failures). So, it wasn't nearly as bad as I originally thought...but I didn't revise my entire partially composed message to suit the new facts. Sorry about that. >> (I mean, you're basically removing the whole >> point of msys; why not just use cygwin instead, if you're not going to >> let msys do for you what it was designed to do?) > > You know, I did think that was what I was doing, fixing broken stuff > without breaking other previously working stuff. I have been running > the testsuite to death lately and can't understand how this failure > has gone undetected. But it's clearly there. My bad, and sorry for the > inconvenience. No, I should have done more testing and validation of your patch series in its new incarnation. I just didn't have time with all the sysroot testing in 57 varieties (plus building and rebuilding multiple cross compiler and sys-root contents...for multiple $host/$build combinations...), then my latest gigantopatch, ... And besides, I *had* tested an earlier incarnation, hadn't I? Surely that was good enough. I mean, nothing could possibly have changed in libtool over two years that would cause a working patch series to regress after a simple rebase -- or, as in your case, a 95% rewrite -- correct? Not. Sigh. It's my own fault; I should have done more testing earlier. -- Chuck