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

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Fri, Sep 10, 2010 at 12:35:59AM CEST:
> Den 2010-09-09 22:05 skrev Charles Wilson:
> > On 9/9/2010 3:56 PM, Ralf Wildenhues wrote:
> >> Secondly, I can help with unsupervised git bisect if you need.  In
> >> <http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00006.html>,

> I adjusted both reconfdirs and TESTS. You tend to learn how to do that
> quickly in windows-land. The payoff for that learning curve is almost
> instantaneous.

Hehe.

> > I'll take a look, but it may actually be faster to do it old-school:
> > just trace thru the failing case in git master-NOW, figure out what's
> > going wrong, and fix it.
> 
> In my current setup it's hard to automate, as I do git and bootstrap on
> Cygwin only, then test Cygwin and when that is done I switch to MSYS and
> test there too.

Ok, so the payoff for changing that will be noticeable then, too.
Install msysgit (someplace else), make sure the git program is found
in PATH in your normal MSYS installation.  Profit.

> I have version mismatches for automake and autoconf in
> MSYS and Cygwin, so if I'm not careful things go belly up. I should
> perhaps try to have matching autotools, but I'm used to not having them
> at all in MSYS, and I'm not sure if things will be screwed up with paths
> leaking in from the other posix world if I mix, so I'm just doing it in
> a way that I know works.

Sure.  I have current autotools in $HOME/local in MSYS, put that early
in PATH, profit (also because it executes a bit faster than Cygwin).

> Watch out, rant coming up. You have been warned.
> 
> My problem(?) is that libltdl issues are the hardest to fix, so there
> are multiple issues that are not fixed for MSVC. That, and that most
> libltdl tests are too wide for my liking, so the libltdl part of the
> testsuite tend to either be all failing or all failing even if you have
> made an improvement. Which makes it hard to use the testsuite to
> determine if you have made any progress when you are testing something.

Fully agreed.  I already mentioned that improving ltdl coverage would be
paramount for any rewriting in that area, this is just another reason.

> It is also hard to deduce if you have caused some spectacular new fail
> with a patch, if the test in question fails before it got to the newly
> introduced badness.

So are you saying we should have compile+link-only ltdl tests?
Which ones are likely to fail early?

> Even if the the new fail happens before the old
> fail, it's still harder to discriminate fail:63 from fail:67 than it is
> to discriminate fail:63 from ok. It also doesn't really help that I'm
> not using libltdl for anything real: I'm not really familiar with what
> the expected behavior is and it tends to not be that important and
> "itchy" to me.

What would help here, though?  More descriptive comments in the test
sources?

> And then, as always, there's the wall clock issue.

Yep.  Dunno what to do about that.

> stresstest is now ok for MSVC, so it is finally really useful in
> detecting regressions, and no longer a "masking failure rat hole".

Cool.

Thanks,
Ralf