Bruno Haible wrote:
>> > my suggestion implied to rename the function as well, not
>> > only the module :-)
>>
>> At which point _all_ clients would instantly be exposed to the rename in
>> C code
>
> If we decide to rename get_date() to parse_datetime(), we can add a
> #define get_date parse_da
Eric,
> > my suggestion implied to rename the function as well, not
> > only the module :-)
>
> At which point _all_ clients would instantly be exposed to the rename in
> C code
If we decide to rename get_date() to parse_datetime(), we can add a
#define get_date parse_datetime
for one year o
On 09/30/2010 03:35 PM, Bruno Haible wrote:
Eric Blake wrote:
I went with get_date, and not Bruno's parse-datetime. Afterall,
parse-duration supplies the parse_duration function, and
get_date supplies the get_date function.
Well, my suggestion implied to rename the function as well, not
only
Eric Blake wrote:
> I went with get_date, and not Bruno's parse-datetime. Afterall,
> parse-duration supplies the parse_duration function, and
> get_date supplies the get_date function.
Well, my suggestion implied to rename the function as well, not
only the module :-)
> lib/{getdate.y => get_d
Eric Blake wrote:
> Note: getdate.h is not renamed, to minimize client impact.
> Besides, whenever we eventually add getdate-posix, we'll
> want to use getdate.m4 and getdate.c for the implementation,
> but don't need to worry about getdate.h since getdate() uses
> for its header.
>
> * modules/ge
Note: getdate.h is not renamed, to minimize client impact.
Besides, whenever we eventually add getdate-posix, we'll
want to use getdate.m4 and getdate.c for the implementation,
but don't need to worry about getdate.h since getdate() uses
for its header.
* modules/getdate: Mark obsolete. Move old
