> > > 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. >
Sure. However, expressing something with code is better because code does not lie, while comment may be incorrect. > > 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. > I do not know why Gaby used 'axiom-c-macros.h' as a name, but at first glance changing it to 'config.h' looks reasonable (unless there is some technical difficulty). > 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 > No. The above is wrong in general and bad style when works: it tests if a preprocessor symbol is 0. If AF_LOCAL is defined to 0 the snippent above treats it as undefined. And if AF_LOCAL is undefined it works only because C preprocessor replaces undefined symbol by 0. The correct form would be: #if defined(AF_LOCAL) # define FRICAS_AF_LOCAL AF_LOCAL #elif defined(AF_UNIX) # define FRICAS_AF_LOCAL AF_UNIX #else # error needs one of AF_LOCAL or AF_UNIX #endif Note however that 'defined' is part of ANSI C and may be absent in pre-ANSI C compilers. We require ANSI C anyway so for us 'defined' is not a problem, but 'HAVE_...' style was developed at time where support for non-ANSI C compilers was important. > 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. > 'malloc' is part of C standard, it may be absent only in subset implementation which is anyway unsuitable for FriCAS. So I do not think we should check for presence of 'malloc'. I recall a few cases where we do not test for presence of functions. Basically speaking once other tests succeed it is quite unlikely that the function is absent and most cases absence of a function is a fatal error anyway. -- Waldek Hebisch [email protected] -- 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.
