Le 13/09/2015 04:14, Sean DuBois a écrit :
That sounds good to me!
That would double build times though, is that going to be a concern?
This won't hurt development time though, since you would dev in zstrict,
and then switch to non-zstrict when running/testing?
Why would it double build times ? This is an optional tool, developers
will run a zstrict build when they want to check their code against API
'best practices'. Some will do it more often than others, but that's
their choice. Some ext devs will probably never use it, that's their
decision.
The only constraint will be for core developers. If travis runs in
zstrict mode, every non-zstrict code will cause it to fail. So, core
changes will need to be 'strict'. That's why this decision needs a vote.
A +1 for me would be to find a helpful way to tell extension
developers what the 'proper form' would be. So if I do a
(zend_string *) foo->val I would be hinted to the proper API.
The only way I imagine is by adding comments near the struct
declaration. This is far from perfect because it implies finding the
declaration and looking into the code. If someone sees a mechanism to
display a helpful message at compile time, I'm all for it.
Another +1 would be warnings for an entire code base, hopefully the
build doesn't just bail on the first error/file a lot of 'bug fixing'
development depends on stuff like syntastic.
I'm not sure I understand what you mean here, but using 'make -k'
compiles everything it can and doesn't stop at the first failing file. I
will add this to travis/compile.sh because it is better if travis
results show every compile error.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
