NetWare curlbuild.h settings depend on whether LIBC or CLIB is used.
The NetWare specific Makefile is capable of knowing which target is being built.
So, finally, the NetWare Makefile will take care of generating curlbuild.h
CVS checked out curlbuild.h.dist as curlbuild.h for any non-configure target
when host system is not running buildconf.bat.
All the curlbuild.h stuff was done taking in consideration that no adjustment
would be needed in non-configure makefiles.
As it is documented, when trying to build on non-configure capable systems or on
systems which for any reason don't run the true configure script, it is required
to have the proper curlbuild.h in place before calling any makefile.
Due to the hardcore memory debugging stuff c-ares enabled debug builds also need
the file in the proper place before attempting to build c-ares.
http://sources.redhat.com/automake/automake.html#Extending-aclocal documents
that starting with Automake 1.8, aclocal will warn about all underquoted calls
to AC_DEFUN due to the fact that in a single aclocal run it might include more
than once all .m4 files which it finds available, this includes .m4 files from
other software packages.
If the first argument to AC_DEFUN is underquoted and the same macro is included
more than once, successive inclusions after the first one will expand the macro
instead of assuming it is the same as the first one included.
1) The maketgz script does not insert the timestamp in curlver.h,
it actually updates it. For CVS versions it is the "CVS" string.
2) testcurl.pl will always print the "date" string which represents
the moment the test build is run.
3) testcurl.pl may not print the "timestamp" string since the script
may end before it is printed out. (i.e. unable to update from CVS)
4) The "timestamp" string printed will be the same as the "date" one
unless one of the following conditions is met.
*) It is a tarball-based build. Timestamp will be creation time.
*) CVS update has been done. Timestamp will be end of CVS update.
for tarball-based tests and builds, the maketgz script inserts it when
the tarball is created. For CVS-based tests and builds the timestamp we
show is the current UTC build time as it is the CVS version timestamp.
In this way, all builds will have a valid source code timestamp which
isn't related to the moment the tests and build is performed, with the
exception of CVS-based ones which have the same "date" and "timestamp"
stdout, since I've found cases on Solaris where the second output mixes with
the first and thus the big check-script doesn't properly find the first
string in the output stream.
Yang Tse