Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

[Charles Wilson]

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