On Wed, January 21, 2015 12:32, Derick Rethans wrote: > On Wed, 21 Jan 2015, Anatol Belski wrote: > > >> On Wed, January 21, 2015 11:57, Anatol Belski wrote: >> >>> On Wed, January 21, 2015 11:17, Derick Rethans wrote: >>> >>> >>>> On Wed, 21 Jan 2015, Anatol Belski wrote: >>>> >>>> >>>>> I'll backport it to 5.6. Also would add the Pierre's suggestion >>>>> so those defines are only used when it's not inside PHP, as under >>>>> circumstances it could lead to different defines or conflicts. >>>>> This is easy done through the timelib_config.h include as that >>>>> file is already being generated by configure. >>>> >>>> timelib really should not have references to PHP - it should never >>>> have been in timelib_config.h either. Is there something else we can >>>> do here? At some point, I'd like to change the bundling to a GIT >>>> submodule perhaps. >>>> >>> i'd suggest to wrap it like >>> >>> #ifdef HAVE_TIMELIB_CONFIG_H >>> # include "timelib_config.h" >>> #endif >>> >>> >>> It allows PHP or anything external to override the configs. >>> >> >> Ah, I see now, in your project on github nothing even bothers with >> generating timelib_config.h . But that's a common practice to include >> some config.h, will be needed anyway to include correct headers. >> >> So probably worth to just wrap it as mentioned above and let it to be >> overriden by something external or let it to be generated by some build >> system when timelib is used as a separate project. > > Yes - I think that's the plan. But the int types of course do need to > "work" out of the box. > > > cheers, Derick > > I did it this way now. The PHP's timelib uses the global config, the standalone timelib will have to generate it to have thingies like HAVE_STDINT_H and others.
Regards anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
