On Mon, Feb 26, 2007 at 12:47:11AM -0500, Daniel Richard G. wrote:
> > } > This seems like a nice simplification. Any cost to making this
> > } > change?
> > }
> > } Just the effort in renaming them.
> >
> > OK, it seems like there's consensus to consider this one later, then.
>
> There is one issue that arises, however---another manifestation of
> Autoconf's crazy out-of-order execution, that I'd forgotten about till now.
> I want to run this by everyone before making any change.
>
> The boilerplate code associated with --enable-foo or --with-foo is near the
> top of the configure script. When you invoke either such option, enable_foo
> or with_foo is set at that point, before any of your code in the script.
> Which means that you can't have a section assigning default values for all
> the (enable|with)_foo variables, because then you're blowing away the
> user's chosen values.
>
> The upside is, we would need to use argument 4 of AC_ARG_ENABLE/WITH to
> express the default value for an option, e.g.
>
> AC_ARG_ENABLE(cpp,
> AS_HELP_STRING(...),
> ,
> enable_cpp=yes)
>
> (We can leave arg 3 empty, because 'enable_cpp="$enableval"' is already
> done for us.)
>
> Technically speaking, this is the "correct" way in Autoconf of specifying
> the default value for an option (arg 4 is invoked if neither the positive
> nor negative form of the option is given). It's a bit more of a change than
> we've originally discussed, however; what do y'all think?
I support this change. You are correct, it should have been done this
way.
> On Fri, 2007 Feb 23 08:57:43 -0500, Bob Rossi wrote:
> > > A similar issue closely tied to the build system. If the file is named
> > > ucptable.c, then Automake will want to compile it separately, which fails.
> >
> > Why didn't I see this?
>
> Because ucptable.c wasn't mentioned at all in your Makefile.am :-) (This
> was part of getting "make dist" to work)
What I was really asking is, why did I not need this file to compile
pcre? Why does the file exist. If you are now compiling it, what does it
get linked into? why?
> > > > > +#ifdef HAVE_CONFIG_H
> > > > > +# include <config.h>
> > > > > +#endif
> > > >
> > > > Same comment here. In fact, why are we adding the #include here?
> > >
> > > IIRC, I got a compile error without it. Eventually, all the *.c files will
> > > need to have this bit added---that's the convention for the config header.
> >
> > I don't get a compiler error with out it. What's changed on your end?
>
> I think it was because I used -ansi, which hid some functionality used by
> pcregrep (restored by _GNU_SOURCE). There are other cases where the source
> won't compile without config.h, e.g. if the compiler doesn't understand
> "inline" as a keyword and config.h contains "#define inline" or "#define
> inline __inline__", etc.
OK, so this is going to be removed until you get back to the -ansi
patch?
> > > This output is from a pcregrep -L -r command, which gives a list of files
> > > as output. The list, alas, is not sorted, and the test was failing for me
> > > as I was getting a different file order than the reference. So I re-sorted
> > > the list to proper lexical order ('8' < 'x') and added a sort(1) command to
> > > RunGrepTest.in so that the output is always sorted.
> >
> > Does the test fail with pcre-7.0 as well? I wouldn't want to improve the
> > test suite in this patch if it was failing before as well.
>
> Well, the failure had nothing to do with the test in itself---it all came
> down to the matter of how files were ordered on the filesystem.
Thanks, I understand. Nice catch!
Bob Rossi
