Re: [pcre-dev] Creating a distribution

On Thu, 8 Mar 2007, Daniel Richard G. wrote:

> (I would rename it to "maint", however... more precedent for that :-)

OK, I'll do that, but I'm not doing any more renaming now.

> I'd keep pcre.h.in/pcre.h as is. As for config.h.manual... one other thing
> to consider is that, in the Autotools canon, config.h.in is really supposed
> to serve that purpose. That's why we go to the trouble of putting nice
> comments into it. Are you imagining a "config.h for by-hand builders" that
> is significantly better than config.h.in?

Too late (for now). Yesterday I sorted it all out so that we have
pcre.h.generic and config.h.generic in the distribution. And I
documented all of this. Changing names now means going back and re-doing
the documentation, which takes a significant amount of time. (That's the
problem with providing comprehensive documentation - you have to do
comprehensive editing. For example, there's a list of distributed files
in the README that has to be kept correct when file names change.)

And yes, config.h.generic is significantly better than config.h.in. The
former (as now constructed) contains sections like this:

/* The value of LINK_SIZE determines the number of bytes used to store links
as offsets within the compiled regex. The default is 2, which allows for
compiled patterns up to 64K long. This covers the vast majority of cases.
However, PCRE can also be compiled to use 3 or 4 bytes instead. This allows
for longer patterns in extreme cases. On systems that support it,
"configure" can be used to override this default. */
#ifndef LINK_SIZE
#define LINK_SIZE 2
#endif

whereas the latter has this:

/* The value of LINK_SIZE determines the number of bytes used to store links
as offsets within the compiled regex. The default is 2, which allows for
compiled patterns up to 64K long. This covers the vast majority of cases.
However, PCRE can also be compiled to use 3 or 4 bytes instead. This allows
for longer patterns in extreme cases. On systems that support it,
"configure" can be used to override this default. */
#undef LINK_SIZE

Even without the #ifndef stuff, the former version is better because the
user won't have to edit *everything*.

> > I don't know in detail - people have emailed me from time to time about
> > the weird and wonderful special-purpose environments they use, but I
> > haven't kept records. I may be imagining it but perhaps one was an OS
> > used on cell phones. That kind of thing. I myself still have an old
> > Acorn computer at home - no longer used, but years ago I did put PCRE on
> > it "by hand", and there are still people using those systems.
>
> Interesting :) Could you say if a Make program was a common thread between
> most of these systems? I wonder if e.g. AcornOS is like Windows in this
> respect (which has NMAKE but no POSIX to speak of).

Acorn's RISC OS has "make" (and, hooray, hooray, many years ago they
recognized that you don't *need* to start lines with tabs - whitespace
can be used instead and is compatible), but nothing like a Unix shell.
At least, it didn't. It's 10 years or more since I had a new version; no
doubt there have been changes.

Incidentally, for the record (as this mailing list will be archived),
the original implementation of PCRE was done at home on the Acorn in the
summer of 1997. I did it at home rather than at work so as to have no
distractions while figuring out how the heck to implement it.

> You know, I'm not so sure that these little "shortcuts" we've been
> discussing, to facilitate non-Autotools/non-CMake builds, are ultimately
> worth the effort. The user would still have to assemble (by hand) the moral
> equivalent of a makefile, and the favors we're doing him/her are trifles in
> comparison.

(1) pcre.h.generic gives the PCRE release number.
(2) config.h.generic gives a default set of #define values.

That's all we are doing! (2) saves people who are unfamiliar with
autoconf from having to dig the defaults out of configure.ac.

On Thu, 8 Mar 2007, Craig Silverstein wrote:

> I think there's a third category, which is distribution maintainers.
> I guess one goal of the .tar.gz is that it's easy for the debian
> maintainer (say) to download it and make a good .deb file out of it.
> They won't want to make a new release, but they may want to do tweaks.

Good point. I hadn't thought of that.

> I vote for config.h.in and pcre.h.

See my comments above; config.h.in isn't as useful as you think.

> But really, I think everything we're doing now is pretty minor. No
> matter what choices we make, folks will be fine with it, and if not
> it's not so critical it can't wait until the next release. I don't
> think any of these decisions really need to be holding up making a new
> release. (Not saying they are, just saying they shouldn't start :-) ).

That's why I'm not going to change again now.

> In that case, I think protecting stuff in config.h with '#ifdef' is
> unnecessary.

I disagree. With the files the way they now are, I could (if I so
wished) build it on my old Acorn by renaming pcre.h.generic and
config.h.generic and then using -D on the cc command line to make config
tweaks such as enabling UTF-8 support. This could all be encapsulated in
a script that could then be re-used for the next release. No file
editing required.

I was, in fact, recently asked to put in the #ifndef stuff. It was
already on my list of things to do for the next release. So it isn't
just a theoretical idea. :-)

Philip

--
Philip Hazel, University of Cambridge Computing Service.