libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.


From: Charles Wilson
Subject: Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Date: Wed, 21 Jan 2009 15:42:40 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666

Ralf Wildenhues wrote:
> * Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET:
>> Part of my tendency to include minor -- easy to review -- changes with
>> larger ones is due to (a) see it, fix it, otherwise it'll be forgotten
>> and (b) EVERY separate patchset requires an independent full testsuite
>> run.
> 
> Ah, ok.  I can feel the pain.  Let's relieve that a wee bit, without
> compromising quality too much:
> (a) can be addressed with git.  Really, git's is flexible enough to
> allow for doing many many small commits, even ugly ones, and cleaning up
> afterwards.  AIUI git is available for Cygwin and MinGW.

Yep. I'm using it on cygwin. For mingw stuff I usually make dist on
cygwin, and send the tarball across to mingw.

> (b) There is no need for full testsuite runs for every patch.  If two
> patches are clearly independent, then one run with both of them should
> suffice.  If you have a (not too huge) patch series, where things belong
> together, and the end point passes the testsuite, then while that is not
> ideal, it is still a lot better than nothing; in that case, please note
> this, and we can still ask for results of intermediate states if
> necessary.

Well that'd be easier.

> Which however makes testsuite additions all the more important: that
> way, at least, when we run the suite before a release, we can find
> potential regressions.  Think of testsuite additions as a way to shift
> some of the testing grunt work from yourself over to other users.

This only matters if an full and successful testsuite run is not
required after each patch (sequence?), or if all you're worried about is
when patchA (submitted for unix, or cygwin) might break mingw but the
original submitter only tested on "his" platform. Which is an important
case, of course.

But if you're fixing a cygwin bug, you need to test on cygwin (full
testsuite? see below...)

> Just to be sure: you are aware of limiting the testsuite runs to just
> those bits that you are adding?
> old suite:
>   make check TESTSUITEFLAGS=-V TESTS="tests/foo.test tests/bar.test" \
>              VERBOSE=yes
> new suite:
>   make check-local TESTSUITEFLAGS='-v -d -x 27-33'

Sure, but how do you then *know* that your change didn't break something
else? At some point you still have to run the full testsuite before
committing to master, at least on the platform for which you're fixing a
bug. These shortcuts can speed up development while coding the fix, but
not the final submission/review process for the change.

--
Chuck




reply via email to

[Prev in Thread] Current Thread [Next in Thread]