Re: merging msvc in branch-1.11

[Peter Rosin]

Peter Rosin skrev 2011-11-08 21:48:
> [dropping address@hidden
> 
> 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