Re: [pcre-dev] PCRE 7.3 release candidate for testing

Página superior
Eliminar este mensaje
Autor: Daniel Richard G.
Fecha:  
A: pcre-dev
Asunto: Re: [pcre-dev] PCRE 7.3 release candidate for testing
Almost missed this one :]

On Thu, 2007 Aug 16 14:08:53 +0100, Philip Hazel wrote:
> >
> > config.h.generic is currently created by the PrepareRelease script (as a
> > lightly processed copy of config.h), but it should really be handled by a
> > makefile rule. The dist/distcheck targets should be usable without needing
> > to invoke a separate script.
>
> I take your point, but I think this is something for thinking about
> after the 7.3 release for three reasons: (a) I'm only fixing bugs now, and
> don't want to disturb things, (b) as you yourself say, this isn't a
> complete solution,


Fair enough.

> and (c) I don't think your patch is right anyway. As far as I can see,
> your patch just runs the Perl step of making config.h.generic from
> config.h, but that's not good enough. You have to run ./configure first,
> with no parameters, to ensure that you have a config.h made with the
> default settings. This is currently part of the PrepareRelease script.
> (If you don't, you run the risk of picking up a config.h that was
> previously made with non-default parameters.)


I think it's reasonable to have the semantic that whatever the current
configuration is, that's what gets put into config.h.generic. Keep in mind
that this already applies to parameters relating to system features (e.g.
HAVE_MEMMOVE). Unless config.h.generic is maintained by hand, you can't
really divorce it from the environment surrounding the invocation of "make
dist".

Not that it should be a problem for official PCRE releases, of course---
you'd already be configuring the tree in the default mode anyhow.

> Ideally, I suppose, "make dist" should run PrepareRelease before doing
> anything else - and we could then move the detrailing into the Makefile
> if we wanted.


The PrepareRelease script performs actions that are outside the scope of
"make dist", like the de-trailing. (Which would also fail, if the source
tree happens to be read-only.) The dist/distcheck targets really should be
able to operate independently of the script.

Philip, why not recast the PrepareRelease script as a higher-level wrapper
to "make dist"? That way, it can configure the tree in the correct
(default) manner, and delegate the generation of config.h.generic et al. to
the makefile rules. This approach would embody a proper division of
responsibilities, IMO.


--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)