monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] pcrewrap.cc vs pcre_config.h


From: Stephen Leake
Subject: [Monotone-devel] pcrewrap.cc vs pcre_config.h
Date: Tue, 30 Oct 2007 08:11:38 -0400
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.1 (windows-nt)

We have two conflicting needs in pcrewrap.cc.

mtn log pcrewrap.cc shows:

| |   Revision: 9bcc5db83aec83c2328bdb0ffa6ddd73d2c02605
| |   Ancestor: ef2de17663a2463d3ac24cb789bc2a1895017409
| |   Author: address@hidden
| |   Date: 2007-10-26T12:24:22
| |   Branch: net.venge.monotone
| |   
| |   Modified files:
| |           pcrewrap.cc
| |   
| |   ChangeLog: 
| |   
| |   * pcrewrap.cc: Don't include pcre_config.h.  This is a built-time file 
that
| |     is not available in system-wide installations of pcre.
| o   (Revision: ef2de17663a2463d3ac24cb789bc2a1895017409)
|/|   
| o   -----------------------------------------------------------------
| |   Revision: b944a918857ef9b7a777c300c9126fcf47ef23d1
| |   Ancestor: b04cd584f3b674059f12afd49cad71a03915871b
| |   Author: address@hidden
| |   Date: 2007-10-21T09:13:06
| |   Branch: net.venge.monotone
| |   
| |   Modified files:
| |           pcrewrap.cc
| |   
| |   ChangeLog: 
| |   
| |   Fix link error with pcre when configure with '--without-system-pcre'.
| |   
| |       * pcrewrap.cc : add '#include "pcre_config.h"'
| o   (Revision: b04cd584f3b674059f12afd49cad71a03915871b)

On a system using the bundled pcre, pcrewrap.cc _must_ include
pcre_config.h, so that PCRE_STATIC is set to 1, and therefore pcre.h
sets PCRE_EXP_DECL to 'extern "C"'.

On the other hand, when using a pre-installed pcre library, apparently
pcre_config.h is _not_ available.

I think this is a bug in the pcre packaging, but I guess we have to
work around it.

We need a way for pcrewrap.cc to set PCRE_STATIC, based on the choice
made by configure.

Monotone has its own 'config.h'; we could add PCRE_STATIC there. A
one-line change in m4/pcre.m4 does that (autoconf is quite convenient,
once you stop being scared of it :):

#
# old_revision [79b93098c156a680ed471248734a2c40385d752e]
#
# patch "m4/pcre.m4"
#  from [5d624345448654c16fdf198240cf542c65da0d3b]
#    to [b970b93d32a13a3be9741ffcaf28840f3e37b223]
#
============================================================
--- m4/pcre.m4  5d624345448654c16fdf198240cf542c65da0d3b
+++ m4/pcre.m4  b970b93d32a13a3be9741ffcaf28840f3e37b223
@@ -5,7 +5,7 @@ AC_DEFUN([MTN_LIB_PCRE],
      [use a system-provided copy of libpcre instead of the default bundled
       copy. (To use a specific installed version, use the environment
       variables PCRE_CFLAGS and/or PCRE_LIBS.)]),
-   [case "$withval" in 
+   [case "$withval" in
       (""|yes) with_system_pcre=yes ;;
       (no)     with_system_pcre=no  ;;
       (*)      AC_MSG_ERROR([--with(out)-system-pcre takes no argument]) ;;
@@ -15,6 +15,7 @@ AC_DEFUN([MTN_LIB_PCRE],
    MTN_FIND_PCRE
  fi
  if test $with_system_pcre = no; then
+   AC_DEFINE([PCRE_STATIC],[1],[Define if using bundled pcre])
    AC_MSG_NOTICE([using the bundled copy of PCRE])
  fi
  AM_CONDITIONAL([INCLUDED_PCRE], [test $with_system_pcre = no])

(the 'case' line is a whitespace change)

This works for MinGW with the bundled pcre (it links, and the only
test failures are not pcre related). Could someone test with a system
pcre? Remember to do 'autoreconf -i' to effect this change. If it
still works, please commit this change.


As a matter of etiquette, I think it is better to discuss this kind of
problem here, rather than simply undoing a fix someone has put in.

-- 
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]