After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 671519 - Self-test relies on nonportable (GNU enhanced) 'date' command
Self-test relies on nonportable (GNU enhanced) 'date' command
Status: RESOLVED FIXED
Product: gtk-doc
Classification: Platform
Component: general
1.18
Other Mac OS
: Normal minor
: 1.21
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2012-03-07 03:01 UTC by Daniel Macks
Modified: 2014-02-20 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Macks 2012-03-07 03:01:13 UTC
Building gtk-doc-1.18 on a stock OS X machine (I tried both 10.6 and 10.7) with dependencies supplied via fink, I get several sections of output like this:

make  check-local
(standard_in) 1: illegal character: N
(standard_in) 1: illegal character: N
date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
  DOC   : Scanning header files
(standard_in) 1: illegal character: N
(standard_in) 1: illegal character: N
date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
  DOC   : Introspecting gobjects
(standard_in) 1: illegal character: N
(standard_in) 1: illegal character: N
date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
  DOC   : Building XML
(standard_in) 1: illegal character: N
(standard_in) 1: illegal character: N
(standard_in) 1: illegal character: N
(standard_in) 1: illegal character: N
date: illegal option -- -
date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
  DOC   : Building PDF
  DOC   : Building HTML


If I install GNU's 'date' command, those errors are cleared and instead this section of output is:

make  check-local
  DOC   00:00:00.007023000: Scanning header files
  DOC   00:00:00.246919000: Introspecting gobjects
  DOC   00:00:00.965939000: Building XML
  DOC   00:00:01.038525000: Building PDF
  DOC   00:00:01.038525000: Building HTML


Several of the recipes in docs/gtk-make.doc are using format-strings with %N (nanosecond resolution), which is a GNU extension/enhancement. The /bin/date in OS X is the simple POSIX-compliant one, which does not support that. I'm guessing this level of granularity isn't critical to anything, so I can just use %s (whole seconds)? Assuming so, seems like this feature would be an easy autoconf test, and then easy to use a less precise `date` call if the more precise isn't available.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2012-03-07 08:01:31 UTC
Yes, it is just a poor mans way of benchmarking the execution times. Doing an autoconf check and exporting the format string would b the right thing to do.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2013-05-30 18:25:20 UTC
Daniel, if you do date +%s.%N where the %N is not supported, whats the exit code of the command? That'd allow me to write the check.

date +%s.%N; echo $?
Comment 3 Daniel Macks 2013-05-30 18:34:12 UTC
# simple POSIX from apple
$ /bin/date +%s.%N; echo $?
1369938716.N
0

# GNU from fink
$ /sw/bin/gdate +%s.%N; echo $?
1369938730.161349000
0
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2013-06-03 14:13:39 UTC
Another idea: does this work on your mac?

perl -e 'use Time::HiRes qw(gettimeofday); ($s, $ms) = gettimeofday(); print "$s.$ms\n";'
Comment 5 Daniel Macks 2013-06-03 15:21:01 UTC
1370272582.613848

Time::HiRes first became available in perl-5.7.3, which means it would be available on Apple's vendor-supplied perl back to OS X 10.3.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2013-06-04 07:55:35 UTC
Ok, went for the configure check and simply omit the %N if it does not work. Thanks for the help.

commit 057663ace1d088579890fa7465a45df33839dc65
Author: Stefan Sauer <ensonic@users.sf.net>
Date:   Tue Jun 4 07:54:54 2013 +0200
Comment 7 Daniel Macks 2013-07-09 07:42:05 UTC
Still broken. That commit (now in gtk-doc-1.19) greps for "%N" but the output to match is just "N". Apparently "percent-sign [unknown-fmt-char]" eats the percent-sign rather than outputting it verbatim along with unknown-fmt-char.
Comment 8 Daniel Macks 2013-07-09 08:13:36 UTC
...but even fixing that (Comment #7), there is still a problem. The "illegal character: N" are cleared but

date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

remains. That comes from the next line in the makefiles, where date is called again:

	echo "  DOC   `date --utc --date @0$$tsd +%H:%M:%S.%N`: All done"

Neither --utc nor --date are recognized flags. -u is our "Display or set the date in UTC (Coordinated Universal) time." which sounds like --utc. But there's nothing like --date (to just format the given date value)...all I see in my manpage is the ability to *set* the kernel clock.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2013-08-18 14:14:26 UTC
Fixed the qouting issue in git. What is the date --help output. I could use that to check for --utc and --date and if not present simply echo the time-delta.
Comment 10 Daniel Macks 2013-08-18 15:58:44 UTC
It really is a crippled/non-GNU implementation...

$ /bin/date --help
/bin/date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
Comment 11 Stefan Sauer (gstreamer, gtkdoc dev) 2013-08-18 16:39:37 UTC
Can "-f fmt date" be used to format the date?
Comment 13 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-08 20:15:35 UTC
Daniel, would this work on macos?
perl -e 'use POSIX qw/strftime/;print strftime("%s.0", localtime)."\n"';

unfortunately "strftime" has no support for %N either :/
Comment 14 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-08 20:20:42 UTC
please also check:
perl -MTime::HiRes -e 'print int(1000 * Time::HiRes::gettimeofday),"\n"'
Comment 15 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-14 09:06:29 UTC
commit a5155312facec5859c51a9448688e6aa792e6747
Author: Stefan Sauer <ensonic@users.sf.net>
Date:   Fri Feb 14 10:04:41 2014 +0100

    make: check if date can format dates
    
    Don't use date to format date-stamps in tests unless it is supported.
    Fixes #671519

commit 541a498ee69001a5515a7589989666bd5c9f8944
Author: Stefan Sauer <ensonic@users.sf.net>
Date:   Fri Feb 14 09:52:24 2014 +0100

    make: also set a date format string to format elapsed time
Comment 16 Daniel Macks 2014-02-19 15:31:49 UTC
The autoconf test in 1.20 is still broken per my Comment #7. It's looking for a literal '%N' (with percent) as evidence that that format token is unknown, but the dateformat '%N' outputs just a literal 'N' in that situation (at least in darwin's flavor of `date`):

$ /bin/date +%s.%N
1392823757.N

therefore...

checking whether date can output nanoseconds... yes

even though that's not true. Easy fix in configure.ac:

-date +%s.%N | grep -q '%N'
+date +%s.%N | grep -q 'N'
Comment 17 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-19 18:23:44 UTC
Your date command seems to bbe severly crippled and buggy too :7
> date +%s.%Q
1392833975.%Q

It would have been easier if you could have send a patch. Can we try that next time? This bugs is not worth the time I already spend on it :/

commit 31936ea8c47433eb73c3441fc73ec158f32f41f4
Author: Stefan Sauer <ensonic@users.sf.net>
Date:   Wed Feb 19 19:22:45 2014 +0100

    configure: more tweaks for the macosx date command
    
    Fixes #671519 again.
Comment 18 Daniel Macks 2014-02-20 13:13:38 UTC
Sorry about that. Bugzilla was timing out when I tried to attach files.