[pcre-dev] Thoughts about build systems

OK, it's the weekend. Time for me to think while digging the garden.
Here is where I've got to:

I took a step back. Way back at the start of the year, it took Bob and
Daniel some time to convince me that changing to a "standard" build was
the right way to go. Eventually I decided that, since PCRE is used by
many free software projects, and there is a convention about build
systems, I should move to that system. This was not the only reason.
There had been problems with my home-brewed build system, and some of
them were maintenance issues - that is, adding new stuff usually broke
it for somebody. Another consideration was my impending retirement. This
is now looming - I am retiring from my job at the end of this month.
Though I will continue to maintain PCRE for a while (but not Exim,
incidentally), eventually it will have to pass to somebody else, and
having it use the same kind of build system that many other projects use
seems like a good thing for when that happens.

I realised at the time that there would be things I did not like about
the "standard" build approach, but that I would have to live with them.
That is the price of compatibility. There are things I don't like about
the way Perl handles regexes (the arcane rules about \6 or \11 for
example), but in the interests of compatibility I copied them. Now I
think I must apply the same reasoning to the build system.

THEREFORE:

1. I accept that the HAVE_CONFIG_H macro will have to stay the way it is.

Daniel wrote:

> #2 is strictly a technical issue. If you use "", and you're doing an
> out-of-source-tree build, and the source tree has a config.h file, then
> your build will incorrectly use the source tree's config.h instead of
> your own (because "" first looks in the same directory as the source
> file being compiled, even if your -I directives specify otherwise).
>
> It is unfortunate that <> gives the impression that config.h is some
> kind of system/installed header file. But I argue that this bit of
> semantic weirdness is the lesser evil, compared to doing the absolute
> wrong thing in the above scenario. And that, I believe, is what is
> behind the same recommendation in the Autoconf manual.

A look at my (admittedly ancient) C standard doesn't help. It
essentially says that both <> and "" semantics are implementation
defined. I myself was previously caught with <> for pcre.h picking up a
system-installed header rather than the local one - but that was when
compiling Exim with included PCRE files. There is no -I. there.

Now, we don't distribute config.h - just config.h.generic - so the
danger Daniel describes will happen only if somebody configures within
the source directory, and then re-configures and tries to build outside
the source directory. How likely is that?

I can't please everyone here, that is clear. There will be gotchas
either way. Which of these two is more likely?

(a) Somebody using the autotools configures inside the source directory,
then reconfigures (differently) and builds outside the source directory
(without having done a "make distclean" in the source directory). With
"", they get the config.h from the source directory.

(b) Somebody not using the autotools does not use -I. on the compiler.
(I discount the possibility that there is a compiler without the -I.
option.) With <>, if there is a file called config.h somewhere in the
standard include directories, they get that. If not, they get a "not
found" error.

My view is that (a) is likely to be rarer than (b), but that there may
well be more people using the autotools than not. So how can I balance
that up and make a choice?

I think I should change <> back to "". For two reasons: not only the
above, but it also makes it clear when reading the source that it really
is a local header file - that's always been my interpretation of <> vs
"" and I suspect many people think the same.

In other words, I disagree with Daniel on this point.

I wasn't planning on a 7.4 soon ... but maybe there will have to be one.
See also my next message.

Philip

--
Philip Hazel, University of Cambridge Computing Service.