Eric Blake wrote:
...
>> If anything, this issue shows that the Automake::XFile module (and
>> other similar modules as well) should live in their own git
>> repository, which both Autoconf and Automake should use as a
>> submodule -- and which (for $DEITY's sake!), should be unit-tested.
>> Any vo
[SNIP]
Eric Blake wrote:
>>>
>>> Alas, my perl-fu is weak enough that I'm not sure how good my
>>> unit-testing attempts would be. But moving the files to a common
>>> repository seems doable (how about gnulib?).
I replied:
>>
>> This could be a good "interim" solution, as I the paperwork in pla
On 04/26/2012 05:12 AM, Stefano Lattarini wrote:
> Hi Eric, sorry for the delay.
>
> On 04/25/2012 01:25 AM, Eric Blake wrote:
>>
>> Actually, this appears to make _all_ the XFile uses work; all that
>> remains broken is places such as bin/autoupdate.in calling raw open
>> instead of using XFile.
Hi Eric, sorry for the delay.
On 04/25/2012 01:25 AM, Eric Blake wrote:
>
> Actually, this appears to make _all_ the XFile uses work; all that
> remains broken is places such as bin/autoupdate.in calling raw open
> instead of using XFile.
>
>>>
>>> diff --git i/lib/Autom4te/XFile.pm w/lib/Autom4t
On 04/24/2012 05:17 PM, Stefano Lattarini wrote:
> Hi Eric, Russ.
>
> On 04/25/2012 01:08 AM, Eric Blake wrote:
>> On 04/24/2012 04:50 PM, Russ Allbery wrote:
>>> Eric Blake writes:
>>>
Help! I can't release autoconf 2.69 until I figure out how to work
around this patch. After updatin
Hi Eric, Russ.
On 04/25/2012 01:08 AM, Eric Blake wrote:
> On 04/24/2012 04:50 PM, Russ Allbery wrote:
>> Eric Blake writes:
>>
>>> Help! I can't release autoconf 2.69 until I figure out how to work
>>> around this patch. After updating to the latest shared files, as well
>>> as applying this p
On 04/24/2012 04:50 PM, Russ Allbery wrote:
> Eric Blake writes:
>
>> Help! I can't release autoconf 2.69 until I figure out how to work
>> around this patch. After updating to the latest shared files, as well
>> as applying this patch, I'm now stuck with output going to a literal
>> file named
Eric Blake writes:
> Help! I can't release autoconf 2.69 until I figure out how to work
> around this patch. After updating to the latest shared files, as well
> as applying this patch, I'm now stuck with output going to a literal
> file named '-' instead of going to stdout. I suspect that the
> * lib/Automake/XFile.pm: Update comments and POD documentation to
> suggest a more idiomatic/modern usage.
> (open): Be more robust in detecting whether the created file handle
> is being opened for writing.
> * lib/Automake/FileUtils.pm (update_file, contents): Call the
> 'Automake::XFile' and '
