https://github.com/hemmecke/fricas/network
Semantic should (hopefully) be the same.
AFAICS it changes time of error checking: currently if no of
AF_LOCAL and AF_UNIX is defined we get error message from
C compiler.
Well, of course, I wanted that this way. Clearly that counts as a
semantic change.
In my opinion, it is the task of the configure step to check the system
in such a way that it tells you in advance whether the build-process
will not succeed. So I deliberately moved the error into the configure
process.
Also, currently AXIOM_AF_LOCAL can be understood looking at C files
only. After change C programmer would have to look at configure.ac
to know what it means.
Well, in this simple case, it would certainly be enough to move that
into a comment at the place where AXIOM_AF_LOCAL is used. Or we call
this variable AF_LOCAL_OR_AF_UNIX.
Well, I probably would not make such a change: gain form earlier
error checking is minimal because if host supports sockets it
is supposed to define one of AF_LOCAL or AF_UNIX. For purpose
of understanding C code 'sockio.c' would loose a few lines but
actually would be more complicated because of dependency on
AXIOM_AF_LOCAL (note that AF_LOCAL and AF_UNIX are standard
symbols so programmer is expected to understand them).
Counting the number of programmers and the number of times that somebody
looks at this code (in FriCAS), I don't think your argument is a very
strong one. I, myself, had to look up what AF_LOCAL/AF_UNIX is at all.
BTW: We are in (slow) process of changing AXIOM* to FRICAS*.
Oh, I just left AXIOM_AF_LOCAL in order to split the the renaming of
variables patch from the actual shift of the error notification to the
configure process.
AFAICS the HAVE_... variables are the "autoconf way" of doing things.
I do not know original motivation for such style,
Maybe Gaby knows best, why he did it that way.
- autoconf needs a lot of variables, so it is natural to name its
variables in systematic way even if application code needs to
rename them
Sorry, I don't agree. The HAVE_ form is seemingly used a lot for the
predefined AC_-tests.
http://www.gnu.org/s/hello/manual/autoconf/Generic-Headers.html
http://www.gnu.org/s/hello/manual/autoconf/Generic-Functions.html
But defining symbols in via configure.ac is not bound to the HAVE_ form
http://www.gnu.org/s/hello/manual/autoconf/Defining-Symbols.html#Defining-Symbols
- having a single name for aspect as interface between autoconf
and other code reduces coupling between configure and other
code (which is good). Note that HAVE_... names are self-explanatory
and consequently as long as configure works correctly C programmer
has little need to look at configure.ac.
True, the HAVE_... names are self-explanatory, but so would be the use
of config.h (instead of axiom-c-macros.h).
Renaming that generated file axiom-c-macros.h into the default filename
config.h would also remove the axiom/fricas issue here. config.h should
be included before other include's.
- autoconf folks nowadays want to mechanically generate 'configure.ac'
and because of this want the code to be as repetitive as possible,
in particular want systematically build names.
Generate configure.ac? If I run autoscan on a file just containing
#if HAVE_AF_LOCAL
# define AXIOM_AF_LOCAL AF_LOCAL
#elif HAVE_AF_UNIX
# define AXIOM_AF_LOCAL AF_UNIX
#else
# error needs one of AF_LOCAL or AF_UNIX
#endif
then there is nothing in configure.scan that relates to AF_LOCAL. In
fact, I can even remove the HAVE_ prefix and the output of autoscan
doesn't change.
In fact, why HAVE_AF_LOCAL at all? Wouldn't the following do the same?
#if AF_LOCAL
# define FRICAS_AF_LOCAL AF_LOCAL
#elif AF_UNIX
# define FRICAS_AF_LOCAL AF_UNIX
#else
# error needs one of AF_LOCAL or AF_UNIX
#endif
Interestingly, autoscan generates
=============
# Checks for library functions.
AC_FUNC_MALLOC
AC_CHECK_FUNCS([dup2 memset select socket])
=============
and we currently don't have this in our configure.ac.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
