Hi guys, sorry I couldn't send this out last night....
On Sun, 2007 Feb 25 22:50:04 -0800, Craig Silverstein wrote:
> } 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?
>
> My vote: let's leave things as they are for now, and revisit this one
> later.
Well, this would be the time for it---Autotools stuff now, source code
later....
On Mon, 2007 Feb 26 09:44:33 +0000, Philip Hazel wrote:
> On Mon, 26 Feb 2007, Daniel Richard G. wrote:
>
> Yes. I think there are just two lines, aren't there? The first should be
>
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 88- 95 */
>
> and the second
>
> 0x00,0x00,0x00,0x80,0x80,0x80,0x00,0x00, /* 88- 95 */
Aye, those are the only two. With these edits, all the PCRE source is now
7-bit-ASCII safe.
> Not many people are familiar with EBCDIC code. I happen to be, because
> for many years I programmed IBM mainframes.
Incidentally, has anyone ever actually run the test suite on a mainframe
system? (I assume the test input files would have to be converted to EBCDIC
first, among others?)
On Mon, 2007 Feb 26 09:01:30 -0500, Bob Rossi wrote:
> >
> > 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.
Sorry I didn't remember this sooner :]
> > On Fri, 2007 Feb 23 08:57:43 -0500, Bob Rossi wrote:
> >
> > 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?
See my reply to Philip's last message below.
> > 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?
Well, my point was, it's not just about -ansi; it's anything that might
appear in config.h that makes the source play nice with the compiler. I
added the #include bits so that the source would compile, and left them in
since they related directly to changes in the build system....
On Mon, 2007 Feb 26 16:55:16 +0000, Philip Hazel wrote:
>
> > I don't necessarily need to know the details, but the answer to the
> > above question will help me understand what we should do with this file.
>
> Oh dear. The has caused far too much confusion for such a small issue!
> Daniel wants to rename it as ucptable.h because it is #included. I am
> happy to go along with this. It seems that there will be less confusion
> all round.
I heartily concur :]
> I originally called it ucptable.c because it contains compileable code,
> not the kind of definitions and so on that you normally get in a .h
> file. There doesn't seem to be a standard file extension for "this is
> code that is #included rather than compiled as a file on its own". It's
> probably just me thinking of .h as "heading stuff" rather than
> "#included stuff".
Small nit: "...not the kind of _declarations_ and so on that you normally
get in a .h file." Definitions are what usually go in .c files....
Anyway, this is true; what it ultimately boils down to is Automake's
rigorously mechanistic take on the idea: ".c files are things to compile;
.h files I leave alone, but if I make a tarball, those need to be copied in
(or else the .c files won't compile)."
> > It just struck me as odd that a patch to add 'make dist' support would
> > change the build system to start compiling a new file ....
>
> I don't know the answer to this, but my surmise is that the changes
> Daniel had for 'make dist' caused the automated system to think that it
> should be compiling ucptable.c because it ended with .c, and that
> renaming it as ucptable.h solved the issue.
The relevant change here was adding ucptable.c to the list of source files
in Makefile.am. (There was no mention of it before.) This caused Automake
to roll the file into the dist tarball, but at the same time, because it
was a .c file, Automake would try to compile it during a build---and
failed.
The build worked previously because (as Philip already noted) ucptable.c
was already #included by another .c file---one that was already known to
Automake---and ucptable.c was present in the source directory (thanks to a
pcre-7.0.tar.bz2 tarball that wasn't generated using "make dist".)
Will be sending out the next patch shortly!
--Daniel
--
NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef?
EMAIL1 = skunk@??? ## don't smell bad--- (/o|o\) /
EMAIL2 = skunk@??? ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
--
(****** = site not yet online)
