On Wed, Jan 02, 2002 at 11:50:45PM -0600, John E. Malmberg wrote: > Dave Dykstra wrote: > > > On Tue, Jan 01, 2002 at 06:45:59PM -0600, John Malmberg wrote: > > > >>Compaq C 6.5 > >>OpenVMS Alpha 7.3 > >> > > ... > > > >>A second issue, is the line: > >> > >>#undef socklen_t > >> > >>It is not in the standard format for the other lines in the configure > >>script. > >> > >>It would be helpful for it to be: > >> > >>#undef HAVE_SOCKLEN_T > >> > >>And then somewhere else, where the defintion is used, or in rsync.h > >> > >>#ifndef HAVE_SOCKLEN_T > >>typedef socklen_t size_t > >>#endif > >> > > > > > > That's not enough because it needs to figure out what value to use to > > define socklen_t; the current logic in aclocal.m4 tries > > int size_t unsigned long "unsigned long" > > until it gets one to compile. > > > Depending on the compile options selected or defaulted, and if standard > headers are selected or not, a C compiler may not produce the expected > results from one of the test programs in a configure script. > > One of the main reasons that the configure scripts do not work well off > of a UNIX platform is that some UNIX library functions have multiple > implementations for mapping to native operating system features. > > There are a number of cases where a programmer needs to select at > compile time which behavior is correct. Or if the compiler is to > conform to new standard or library routine behavior change or to be > backwards compatable. > > So even if I were to obtain a UNIX compatable shell for OpenVMS like > GNV, the configure results would likely still be misleading. > > For an autoconfigure to be truly cross platform, it must be table > driven, so that a family of similar Operating systems like the *NIX > could share common scripts, but non-*NIX operating systems can supply > scripts that are specific to them.
You seem to have misunderstood me; I wasn't talking about getting configure to work on OpenVMS, only to get it to work on *NIX operating systems while making it friendly for you to scan config.h.in. I'm saying we can't just use "typedef socklen_t size_t" because the value is not always size_t and has to be calculated on *NIX systems and presumably set in some other #define. We could just make up a name for that other #define, but does that help you? Is there some standard format that would make it easy for your DCL procedure to recognize it? > After this I ran into the ALLOCA mess. :-( ... > > Is there some other syntax that the procedure accepts to allow passing a > > value through? > > The procedure is basically looks for symbols in the libraries. Sort of > like using grep to look things up in the header files instead of doing the > test files. > > > If it does not get a match from reading the config.h.in file, it then > scans the configure. file to see if there is a simple assignment in it like: > > symbol = n > > If so, it then does a #define symbol n > > The DCL procedure has some special cases coded into it. I can place an > additional one for socklen_t, now that I know about it. But it is still > better to use the HAVE_SOCKLEN_T indicate if a substitution is needed. > > Basically I will put in a special case that if it sees > "#undef HAVE_SOCKLEN_T", and it does not find it in the standard > header files, it will insert a "#define HAVE_SOCKLEN_T 1" and then the > needed typedef for socklen_t. Oh, ok, that could work. When you've got everything finished submit a patch. ... - Dave Dykstra
