develooper Front page | perl.perl5.porters | Postings from November 2016

Re: [Encode] 2.87 released!

Thread Previous | Thread Next
From:
pali
Date:
November 2, 2016 17:04
Subject:
Re: [Encode] 2.87 released!
Message ID:
201611021803.53742@pali
On Wednesday 02 November 2016 09:32:56 demerphq wrote:
> On 1 Nov 2016 7:37 p.m., <pali@cpan.org> wrote:
> > On Tuesday 01 November 2016 18:59:15 Steve Hay wrote:
> > > On 1 November 2016 at 17:42,  <pali@cpan.org> wrote:
> > > > Hi Steve!
> > > > 
> > > > Sorry, but I cannot reproduce 3. That test
> > > > ext/XS-APItest/t/utf8.t passes and even it does not use
> > > > Encode...
> > > > 
> > > > Can you provide steps to reproduce problem 3?
> > > 
> > > Sorry, I hadn't realized, but this test is failing for me even
> > > without the Encode upgrade.
> > > 
> > > So as far as Encode goes we should be good to go with a 2.08
> > > release including the fixes for 1 and 2 that Dan already
> > > committed.
> > 
> > Ok. If you find any problem let me know.
> > 
> > > > Btw, how it is possible that you got compile failures? Encode
> > > > 2.87 passed all compile & unit tests on all perl versions 5.8
> > > > -- 5.24, see:
> > > > https://travis-ci.org/dankogai/p5-encode/builds/171292122
> > > 
> > > Presumably the compiler used by Travis isn't a picky one like MS
> > > Visual C++ (which I use), which doesn't allow code before
> > > declarations (C89-style).
> > 
> > Current version of gcc which is used on linux supports C11 with GNU
> > extensions which is 20 years newly as C89. And probably gcc's C89
> > mode is with GNU extensions too which supports code before
> > variable declarations. For me it looks like that C89 is really
> > pre-historic...
> 
> If you work on Perl c code then you have to deal with the fact that
> many of our target platforms are c89 only.  There is nothing anyone
> on this list can do about it so there is no point in complaining
> about it either.

Understood, reason why I asked question below ↓

> > But, question is: how to prevent to happen this situation again?
> > Compile errors are already handled by travis when making pull
> > requests but looks like this is not enough...
> 
> There are build options for gcc that will help you catch most of the
> common patterns that break c89.

It is possible to configure travis-ci for github encode repository to 
use it? Or do you have any other idea of automated tests (ideally for 
those platforms which are c89 only)?

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About