Re: getdate fails to build

[Eric Blake]

On 09/29/2010 12:13 PM, Sam Steingold wrote:

On Wed, Sep 29, 2010 at 1:44 PM, Paul Eggert  wrote:

Renaming the module to get_date would avoid
confusion like Sam's in the future.  Presumably
getdate.h would be renamed to get_date.h as well.


yes, please do!


I see no reason to rename the header; "getdate.h" does not conflict with 
any standard header, and we already have other cases of headers whose 
names do not match any of their contents (think "c-ctype.h", where - is 
impossible in a C name).  Renaming the header causes needless instant 
churn in gnulib clients, while renaming _just_ the module can be done by 
obsoleting (but keeping) the getdate module name for a transition period.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: getdate fails to build

[Sam Steingold]

On Wed, Sep 29, 2010 at 1:44 PM, Paul Eggert  wrote:
> Renaming the module to get_date would avoid
> confusion like Sam's in the future.  Presumably
> getdate.h would be renamed to get_date.h as well.

yes, please do!

thanks for your explanations!


-- 
Sam Steingold 

Re: getdate fails to build

[Paul Eggert]

On 09/29/10 09:46, Sam Steingold wrote:
> posix does not require "getdate.h".
> gnulib shouldn't either.

As a historical note, the Gnulib getdate code base
is derived from the same ancestor of the SVR4 spec
that led to the POSIX specification.  To some extent
the POSIX folks horned in on historical practice
that was considerably different and had (and has)
good reasons to diverge from what POSIX requires.

At some point we renamed the Gnulib getdate function to
get_date to avoid code-level compatibility issues,
but we didn't bother to change the module name.
Renaming the module to get_date would avoid
confusion like Sam's in the future.  Presumably
getdate.h would be renamed to get_date.h as well.

Re: getdate fails to build

[Eric Blake]

On 09/29/2010 11:31 AM, Eric Blake wrote:


It may make sense to rename the current getdate module to get_date to
reflect the fact that it is providing a completely different interface.


It might also make sense to write a getdate-posix function that provides 
getdate() (which is a completely different beast than get_date()).  At 
any rate, gnulib/doc/posix-functions/getdate.texi is completely clear 
that although getdate() is missing on several platforms, gnulib does not 
(yet) have a module to provide it.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: getdate fails to build

[Eric Blake]

On 09/29/2010 10:46 AM, Sam Steingold wrote:

 Does glibc have a getdate.h include file?


posix does not require "getdate.h".
gnulib shouldn't either.


If you want getdate(), then you are correct that you want .

But gnulib's getdate module provides get_date(), which is NOT the same 
beast as getdate().


It may make sense to rename the current getdate module to get_date to 
reflect the fact that it is providing a completely different interface.



 which means that getdate.y is compiled unconditionally.
 Whereas platform-dependent compilations are usually triggered
 through AC_LIBOBJ.


this is a bug in gnulib.


No, it is not - if you are using the gnulib module getdate, it is 
assumed that you want get_date(), which glibc does NOT provide.




this is another gnulib bug: it should have detected bad YACC at
configure time and failed then.


Patches welcome.


the bottom line is:
gnulib has no business requiring YACC on linux


Unless of course you are compiling the gnulib get_date() function, in 
which case YACC is a necessity.



gnulib has no business replacing glibc functions on linux


It is NOT replacing the glibc getdate(), it is providing get_date().

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: getdate fails to build

[Sam Steingold]

Bruno,

On Wed, Sep 29, 2010 at 12:33 PM, Bruno Haible  wrote:
> Sam,
>
>> why is getdate built at all on the latest ubuntu?
>> isn't glibc enough there?!
>
> Take a look at the module description (modules/getdate):
>
>  1) It says
>
>       Include:
>       "getdate.h"
>
>     Does glibc have a getdate.h include file?

posix does not require "getdate.h".
gnulib shouldn't either.

every time you replace some glibc functionality, it is a bug.
either in gnulib, or in glibc.


>  2) It says
>
>       Makefile.am:
>       lib_SOURCES += getdate.y
>
>     which means that getdate.y is compiled unconditionally.
>     Whereas platform-dependent compilations are usually triggered
>     through AC_LIBOBJ.

this is a bug in gnulib.

>> /bin/bash /home/sds/src/clisp/current/build-g//build-aux/ylwrap
>> /home/sds/src/clisp/current/modules/syscalls/gllib/getdate.y \
>>                                        y.tab.c getdate.c \
>>                                        y.tab.h getdate.h \
>>                                        y.output getdate.output \
>>                                        -- byacc   && \
>>          mv getdate.c getdate.c-t && \
>>          mv getdate.c-t
>> /home/sds/src/clisp/current/modules/syscalls/gllib/getdate.c
>> byacc: e - line 277 of
>> "/home/sds/src/clisp/current/modules/syscalls/gllib/getdate.y", syntax error
>> %pure-parser
>> ^
>> make[2]: *** [getdate.c] Error 1
>
> The getdate module comes with an autoconf macro gl_GETDATE, which requires
> gl_BISON, found in m4/bison.m4. This macro has a comment
> "# getdate.y works with bison only.", and sets the default value of YACC
> to 'bison -y'. Probably you had YACC set by another macro, and it ended
> up being 'byacc'. Since your package now includes getdate.y, it relies
> on bison. So you can ditch your other macro that determined YACC in a
> more relaxed way, and use bison.m4 instead.

this is another gnulib bug: it should have detected bad YACC at
configure time and failed then.

the bottom line is:
gnulib has no business requiring YACC on linux
gnulib has no business replacing glibc functions on linux

-- 
Sam Steingold 

Re: getdate fails to build

[Bruno Haible]

Sam,

> why is getdate built at all on the latest ubuntu?
> isn't glibc enough there?!

Take a look at the module description (modules/getdate):

  1) It says

   Include:
   "getdate.h"

 Does glibc have a getdate.h include file?

  2) It says

   Makefile.am:
   lib_SOURCES += getdate.y

 which means that getdate.y is compiled unconditionally.
 Whereas platform-dependent compilations are usually triggered
 through AC_LIBOBJ.

> /bin/bash /home/sds/src/clisp/current/build-g//build-aux/ylwrap 
> /home/sds/src/clisp/current/modules/syscalls/gllib/getdate.y \
>y.tab.c getdate.c \
>y.tab.h getdate.h \
>y.output getdate.output \
>-- byacc   && \
>  mv getdate.c getdate.c-t && \
>  mv getdate.c-t 
> /home/sds/src/clisp/current/modules/syscalls/gllib/getdate.c
> byacc: e - line 277 of 
> "/home/sds/src/clisp/current/modules/syscalls/gllib/getdate.y", syntax error
> %pure-parser
> ^
> make[2]: *** [getdate.c] Error 1

The getdate module comes with an autoconf macro gl_GETDATE, which requires
gl_BISON, found in m4/bison.m4. This macro has a comment
"# getdate.y works with bison only.", and sets the default value of YACC
to 'bison -y'. Probably you had YACC set by another macro, and it ended
up being 'byacc'. Since your package now includes getdate.y, it relies
on bison. So you can ditch your other macro that determined YACC in a
more relaxed way, and use bison.m4 instead.

Bruno

getdate fails to build

[Sam Steingold]

/bin/bash /home/sds/src/clisp/current/build-g//build-aux/ylwrap 
/home/sds/src/clisp/current/modules/syscalls/gllib/getdate.y \

  y.tab.c getdate.c \
  y.tab.h getdate.h \
  y.output getdate.output \
  -- byacc   && \
mv getdate.c getdate.c-t && \
mv getdate.c-t 
/home/sds/src/clisp/current/modules/syscalls/gllib/getdate.c
byacc: e - line 277 of 
"/home/sds/src/clisp/current/modules/syscalls/gllib/getdate.y", syntax error

%pure-parser
^
make[2]: *** [getdate.c] Error 1

why is getdate built at all on the latest ubuntu?
isn't glibc enough there?!

thanks
Sam