This change:
- Adds a check for the doxygen program to configure.
- Moves the Doxyfile from src/Doxyfile to doc/Doxyfile.in.
- Generates a doc/Doxyfile from doc/Doxyfile.in inserting
an absolute path to the source directory, so that it
also works when builddir != srcdir.
- Adds `make api` rule for running doxygen; it depends on
api/doxygen file which is never created to force the rule
to always run.
Previously, an empty string as spidermonkeydir or luadir meant
that the LIBS and CFLAGS variables should be used unchanged. A few
commits ago however, the configure script was changed to require
test -f "$spidermonkeydir$spidermonkeyinclude/jsapi.h" and
test -f "$luadir/include/lua$suffix/lua.h" to succeed. These
commands interpret spidermonkeydir="" and luadir="" as the root
directory. This behaviour was inconsistent with the part that
decides whether to add the directory to *_LIBS and *_CFLAGS or not.
The inconsistency could be solved in two ways. Either (a) add an
exception so that the test -f is skipped if the variable is empty,
or (b) treat an empty string as the root directory throughout.
Because the Makefile of SpiderMonkey always installs to a subdirectory
of the specified include directory, and ELinks uses #include <jsapi.h>
without specifying that subdirectory in source code, it seems unlikely
that the SpiderMonkey header files would ever be in the default
include path. I am therefore implementing solution (b) here.
I suppose similar considerations apply to Lua but did not check that
carefully.
The SpiderMonkey support in ELinks now uses JS_GetReservedSlot,
which was added in SpiderMonkey 1.5 RC3a, released on 2001-05-11.
So ELinks no longer supports earlier versions of SpiderMonkey.
However, be careful not to claim that ELinks needs "SpiderMonkey
1.5 RC3a or later", because we haven't tested 1.5 RC3a.
(I guess we didn't test zlib 1.2.0.2 either... oh, well.)
I'm not sure if JS_GetReservedSlot exists in all versions of the SpiderMonkey.
IMHO the configure script should check for JS_GetReservedSlot.
The patch in the attachment.
It was reported at elinks-dev on 2007-06-03 that Solaris 10 comes with
zlib 1.1.4, which does not include gzclearerr(), which ELinks nowadays
requires. It would be possible to rewrite the decompression support
to use deflate() directly and avoid stdio, in which case gzclearerr()
would not be needed. That will take some time however, so I'm not
attempting it for ELinks 0.12.0. Instead, I'm just disabling gzip
decompression entirely if zlib is too old.
The configure script checks whether it is possible to compile a use of
POPpx without an n_a variable; if not, the source code then defines
those variables. This is slower than including Perl's patchlevel.h
and comparing the version numbers to 5.8.8 but I expect this to be
more reliable as well.
CPPFLAGS was dropped[1] back on 2004-04-24. Then a workaround was
introduced by commit 6d7e9bfe5b to fix
compilation on FreeBSD that used CPPFLAGS to store iconv related flags.
The use of CPPFLAGS with respect to the COMPILE "macro" reappeared in
40e257bedd on 2006-08-05.
This commit makes configure.in print CPPFLAGS and LDFLAGS. Before,
CPPFLAGS and CFLAGS was mixed together in the feature summary. It also
restores the use of CPPFLAGS storing iconv related flags but keeps the
use of the SAVE/RESTORE_FLAGS in the iconv macro.
Reported by Daniel E. Macks <dmacks@netspace.org> on 2005-11-22 in a mail
to elinks-users with the ID: <slrnem7tjs.lvk.dmacks@happy.netspace.org>.
[1] http://pasky.or.cz/gitweb.cgi?p=elinks-history.git;a=commit;h=ebad0e71572b41dac5376e148fe4b1b5cb9ccc33
