On 18-09-14 19:46, Diego Novillo wrote:
> On Thu, Sep 18, 2014 at 10:56 AM, Yury Gribov <y.gribov@samsung.com> wrote:
>>
>> On 08/04/2014 12:14 PM, Tom de Vries wrote:
>>>
>>> On 04-08-14 08:45, Yury Gribov wrote:
>>>>
>>>> Thanks! My 2 (actually 4) cents below.
>>>>
>>>
>>> Hi Yuri,
>>>
>>> thanks for the review.
>>>
>>>>   > +if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq
>>>> "--inline")) {
>>>>   > +    $diff = $ARGV[1];
>>>>
>>>> Can we shift here and then just set $diff to $ARGV[0] unconditionally?
>>>>
>>>
>>> Done.
>>>
>>>>   > +    if ($diff eq "-") {
>>>>   > +            die "Reading from - and using -i are not compatible";
>>>>   > +    }
>>>>
>>>> Hm, can't we dump ChangeLog to stdout in that case?
>>>> The limitation looks rather strange.
>>>>
>>>
>>> My original idea here was that --inline means 'in the patch file', which
>>> is not possible if the patch comes from stdin.
>>>
>>> I've now interpreted it such that --inline prints to stdout what it
>>> would print to the patch file otherwise, that is, both log and patch.
>>> Printing just the log to stdout can be already be achieved by not using
>>> --inline.
>>>
>>>>   > +    open (FILE1, '>', $tmp) or die "Could not open temp file";
>>>>
>>>> Could we use more descriptive name?
>>>>
>>>
>>> I've used the slightly more descriptive 'OUTPUTFILE'.
>>>
>>>>   > +    system ("cat $diff >>$tmp") == 0
>>>>   > +        or die "Could not append patch to temp file";
>>>>   > ...
>>>>   > +    unlink ($tmp) == 1 or die "Could not remove temp file";
>>>>
>>>> The checks look like an overkill given that we don't check for result
>>>> of mktemp...
>>>>
>>>
>>> I've added a check for the result of mktemp, and removed the unlink
>>> result check. I've left in the "Could not append patch to temp file"
>>> check because the patch file might be read-only.
>>>
>>> OK for trunk?
>>>
>>> Thanks,
>>> - Tom
>>>
>>
>> Pinging the patch for Tom.
>
>
> Apologies for the delay. Could someone post the latest patch. I see
> it's gone through a cycle of reviews and changes.
>
>

Hi Diego,

here it is.

I've followed up on the explanation by Segher about 2.15 File module version and 
fixed the comment.

I've not added the 2.15 file module version check on copy Segher also mentioned, 
since I'm not sure about that one. AFAIU the tradeoff is:
- without the check the mklog still works ok for older versions of perl, apart
   from the permissions (the situation we're in for all versions of perl without
   the patch)
- with the check the script won't work at all for older perl version.
So it's a question of predictability (always do the same or do nothing) vs. 
robustness (do as much as you can given the circumstances). I'm not sure which 
one is better in this case.

Thanks,
- Tom