Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> Charles G Waldman <cgw(a)pgt.com> writes:
>> On a more general note, why is HAVE_FSYNC being handled the way it
>> is (in src/sysfile.h) instead of by the configure script? The
>> existing logic seems convoluted - since Linux #defines USG, sysfile
>> decides not to #define HAVE_FSYNC, even though Linux has fsync. Am
>> I misunderstanding the purpose/meaning of the HAVE_FSYNC symbol?
>> What does USG have to do with it?
Hrvoje> Only Martin is truly competent to answer this, but if I had to guess,
Hrvoje> I'd say it's a remnant of the pre-configure period, when all the
Hrvoje> HAVE_* symbols were handles by s/m files. If we want to use
Hrvoje> HAVE_FSYNC, we should simply check it via Autoconf.
Martin here.
There are still s&m files that include usg-*.h. I'd like to nuke
them, but am afraid.
HAVE_FSYNC looks like something that ought to be autoconfiscated, but
I don't know enough about fsync().
In the dark ages before autoconf, everything was hard-coded into the
s&m files. At that time, it looked pretty clever to have a usg5-4.h
`subroutine'.
One could just add fsync to the list of functions on that long
AC_CHECK_FUNCS line in configure.in, and add
#undef HAVE_FSYNC
to src/config.h.
This brings up a question I have always had about the XEmacs autoconf
support. Why is it that you cannot simply do `autoreconf'. Touching
config.h.in by hand is gross. I completely thrashed a XEmacs source tree
once when I did an autoreconf - the config.h.in it produced was unusable.
Also, if you do it in the current tree I get the oh-so-helpful error from
autoreconf. :)
/usr/bin/autoreconf: test: src/config.h: binary operator expected
How close are we to being able to lose Makefile.in.in completely?
-Bill P.