Peter Rosin skrev 2011-11-08 21:48:
> [dropping automake@]
>
> Stefano Lattarini skrev 2011-11-04 11:37:
>> Reference:
>> <http://lists.gnu.org/archive/html/automake/2011-10/msg00031.html>
>>
>> [Adding automake-patches]
>>
>> On Tuesday 01 November 2011, Stefano Lattarini wrote:
>>> Hi Peter.
>>>
>>> On Sunday 30 October 2011, Peter Rosin wrote:
>>>>
>>>> [SNIP]
>>>>
>>>> Sorry for the confusion, but the latest commit from the msvc branch
>>>> currently merged into master is 38846c5f, which was apparently merged
>>>> via the tests-init branch. That was right before the recent round of
>>>> AM_PROG_AR commits. And 38846c5f is just a few "obvious" changes
>>>> after a change to the compile script, so it is a sensible point to
>>>> merge into maint should it not be desirable to merge msvc wholesale.
>>>> (However, from my POV, I think it is indeed desirable to just merge
>>>> msvc into maint/branch-1.11 before the release. Of course.)
>>>>
>>> I mostly agree that we should just merge msvc into branch-1.11 before
>>> the release (then we should "freeze" that branch but for bug-fixes,
>>> and start doing lots of tests).
>>>
>>> *BUT*, I don't like the idea that a "mere" bug-fixing version will
>>> introduce new warnings enabled by `-Wall' and fatal under `-Werror'
>>> (even if I've already agreed that doing so for 1.12 is perfectly
>>> fine -- a statement that I'm not recanting!).
>>>
>>> Here is waht we should do IMHO:
>>>
>>> 1. Merge latest maint into msvc and master, merge msvc into master.
>>>
>> Done (see relevant recent messages on automake-patches).
>
> I'll add some comments there later...
>
>>> 2. Create a new public branch `msvc-for-1.11', based off of
>>> `msvc'.
>>>
>> I've instead based `msvc-for-1.11' on a merge of `branch-1.11'
>> and `msvc'.
>
> The history is a maze. It's very hard to follow what's going on. Is it
> really desired to merge back maint and master into the work branches
> with such extreme frenzy?
>
>>> 3. Commit a change in this new branch, ensuring that either:
>>> [3a] the `extra-portability' warnings are *not* fatal, even
>>> with `Werror'; or that:
>>> [3b] the `extra-portability' warnings are *not* enabled by
>>> `-Wall'.
>>> And we should also tweak the NEWS file accordingly (but not
>>> the docuemntation IMHO).
>>> This change is *not* to be merged into either master or msvc,
>>> obviously.
>>>
>> I went for [3b]. Attached is what I've pushed.
>
> The below patch (pushed as obvious) takes care of a couple of lapses.
>
>>> 4. Merge `msvc-for-1.11' into `branch-1.11'.
>>>
>> Will do once we I have some ACK from Peter or Ralf, or in a week
>> for now if no objection nor regression crops up.
>
> msvc-for-1.11 seems to work ok here. Testsuite still running though.
And it stumbled on extra-portability2.test for similar reasons as
with ar-lib{3,4}.test but I'm not sure if the "sanity check" should
just be removed or what? The "sanity check" is:
# Make sure the test is useful.
AUTOMAKE_fails
but this doesn't fail since extra-portability isn't activated by -Wall.
Another snag in the testsuite is that branch-1.11:tests/ltinit.test needs
the below hunk (or similar) from testsuite-work in order to not fail on
MinGW.
Cheers,
Peter
@@ -57,7 +57,7 @@ $AUTOMAKE -a
cwd=`pwd`
./configure --prefix="$cwd/inst" >stdout || { cat stdout; Exit 1; }
cat stdout
-grep '^checking.*dlopen' stdout
+grep '^checking.*dlfcn\.h.* no$' stdout || grep '^checking.*dlopen' stdout
$MAKE
$MAKE install
