Menu
▾
▴
octave-dev
|
From: Dmitri A. S. <das...@gm...> - 2005-04-13 07:10:02
|
using 2005.04.12 cvs snapshot.
./configure reports
...
Perl compatible regular expresions: pcre.h not found
^^^^^^^^^^^^(sic!)
pcre.h is in /usr/include/pcre/pcre.h
Configure apparently checks for <pcre.h> (and not for <pcre/pcre.h>) .=20
I do not know what is really broken here, and what is the
proper way of fixing it. (I also cannot figure out
where did "expresions" is coming from, may be this is an autoconf=20
typo.)
Sincerely,
Dmitri.
--
|
|
From: Paul K. <pki...@us...> - 2005-04-13 11:35:27
|
The spelling error is in: main/strings/configure.add I don't know what the proper solution to pcre/pcre.h is off hand. - Paul On Apr 13, 2005, at 3:09 AM, Dmitri A. Sergatskov wrote: > using 2005.04.12 cvs snapshot. > > ./configure reports > > ... > > Perl compatible regular expresions: pcre.h not found > ^^^^^^^^^^^^(sic!) > > pcre.h is in /usr/include/pcre/pcre.h > > Configure apparently checks for <pcre.h> (and not for <pcre/pcre.h>) . > I do not know what is really broken here, and what is the > proper way of fixing it. (I also cannot figure out > where did "expresions" is coming from, may be this is an autoconf > typo.) > > Sincerely, > > Dmitri. > -- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real=20 > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev > |
|
From: Stefan v. d. W. <st...@su...> - 2005-04-13 13:03:01
|
How about the following patch, as well as renaming pcregexp.cc to
pcregexp.cc.in and doing a variable substitution:
#include <@PCRE_H@>
If you think this will do the job I can apply the patch.
It's a pity we arn't use subversion: svn move instead of delete (lose
history), rename, commit.
Regards
Stefan
Index: configure.add
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/octave/octave-forge/main/strings/configure.add,v
retrieving revision 1.2
diff -u -r1.2 configure.add
--- configure.add 1 Mar 2005 16:33:33 -0000 1.2
+++ configure.add 13 Apr 2005 12:57:00 -0000
@@ -5,7 +5,13 @@
else
AC_SUBST(HAVE_PCRE)
- AC_CHECK_HEADER(pcre.h, HAVE_PCRE=3Dyes, HAVE_PCRE=3Dno)
+ AC_SUBST(PCRE_H)
+
+ AC_CHECK_HEADER(pcre.h, [HAVE_PCRE=3Dyes;PCRE_H=3Dpcre.h], HAVE_PCRE=
=3Dno)
+ if test $HAVE_PCRE =3D no ; then
+ AC_CHECK_HEADER(pcre/pcre.h, [HAVE_PCRE=3Dyes;PCRE_H=3Dpcre/pcre.h=
], HAVE_PCRE=3Dno)
+ fi
+
if test $HAVE_PCRE =3D yes ; then
OF_CHECK_LIB(pcre, pcre_compile, HAVE_PCRE=3Dyes, HAVE_PCRE=3Dno)
if test $HAVE_PCRE =3D no ; then
@@ -16,7 +22,8 @@
else
STATUS=3D"pcre.h not found"
fi
-
+
+ AC_OUTPUT(main/strings/pcregexp.cc)
fi
STATUS_MSG=3D"$STATUS_MSG
On Wed, Apr 13, 2005 at 07:35:14AM -0400, Paul Kienzle wrote:
> The spelling error is in:
>=20
> main/strings/configure.add
>=20
> I don't know what the proper solution to pcre/pcre.h
> is off hand.
>=20
> - Paul
>=20
> On Apr 13, 2005, at 3:09 AM, Dmitri A. Sergatskov wrote:
>=20
> >using 2005.04.12 cvs snapshot.
> >
> >./configure reports
> >
> >...
> >
> >Perl compatible regular expresions: pcre.h not found
> > ^^^^^^^^^^^^(sic!)
> >
> >pcre.h is in /usr/include/pcre/pcre.h
> >
> >Configure apparently checks for <pcre.h> (and not for <pcre/pcre.h>) .
> >I do not know what is really broken here, and what is the
> >proper way of fixing it. (I also cannot figure out
> >where did "expresions" is coming from, may be this is an autoconf
> >typo.)
> >
> >Sincerely,
> >
> >Dmitri.
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
|
|
From: Dmitri A. S. <das...@gm...> - 2005-04-13 14:33:32
|
On 4/13/05, Stefan van der Walt <st...@su...> wrote: > How about the following patch, as well as renaming pcregexp.cc to > pcregexp.cc.in and doing a variable substitution: >=20 ... At this moment I am not even sure that this is not a bug with the pcre-deve= l package. Perhaps, they should have made a symlink pcre.h -> pcre/pcre.h ? Sincerely, Dmitri. -- |
|
From: Stefan v. d. W. <st...@su...> - 2005-04-13 20:52:12
|
On Wed, Apr 13, 2005 at 08:33:22AM -0600, Dmitri A. Sergatskov wrote: > On 4/13/05, Stefan van der Walt <st...@su...> wrote: > > How about the following patch, as well as renaming pcregexp.cc to > > pcregexp.cc.in and doing a variable substitution: > > > ... > > At this moment I am not even sure that this is not a bug with the pcre-devel > package. Perhaps, they should have made a symlink > pcre.h -> pcre/pcre.h ? I think that Debian (and some other distros) modify the path to pcre.h. I notice now that there is a `pcre-config' available. Maybe we should rather use that to determine compiler flags. Regards Stefan |
|
From: Stefan v. d. W. <st...@su...> - 2005-04-13 21:14:12
Attachments:
configure.add.diff
Makefile.diff
|
Attached is a much simpler patch that should resolve the situation, irrespective of any shuffling done by distros. I think it is safe to assume that pcre.h is present if pcre-config is? Otherwise we can explicitly check, using the output from `pcre-config --cflags` Regards Stefan On Wed, Apr 13, 2005 at 10:52:06PM +0200, Stefan van der Walt wrote: > On Wed, Apr 13, 2005 at 08:33:22AM -0600, Dmitri A. Sergatskov wrote: > > On 4/13/05, Stefan van der Walt <st...@su...> wrote: > > > How about the following patch, as well as renaming pcregexp.cc to > > > pcregexp.cc.in and doing a variable substitution: > > > > > ... > > > > At this moment I am not even sure that this is not a bug with the pcre-devel > > package. Perhaps, they should have made a symlink > > pcre.h -> pcre/pcre.h ? > > I think that Debian (and some other distros) modify the path to > pcre.h. I notice now that there is a `pcre-config' available. Maybe > we should rather use that to determine compiler flags. > > Regards > Stefan > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev |
|
From: Paul K. <pki...@us...> - 2005-05-30 03:47:21
|
I'll apply this patch, but I'm not too thrilled about relying on the existence of pcre-config. Do we need a fallback which will search for pcre.h and libpcre if pcre-config is not present? Thanks, - Paul On Apr 13, 2005, at 5:14 PM, Stefan van der Walt wrote: > Attached is a much simpler patch that should resolve the situation, > irrespective of any shuffling done by distros. > > I think it is safe to assume that pcre.h is present if pcre-config is? > Otherwise we can explicitly check, using the output from > > `pcre-config --cflags` > > Regards > Stefan > > On Wed, Apr 13, 2005 at 10:52:06PM +0200, Stefan van der Walt wrote: >> On Wed, Apr 13, 2005 at 08:33:22AM -0600, Dmitri A. Sergatskov wrote: >>> On 4/13/05, Stefan van der Walt <st...@su...> wrote: >>>> How about the following patch, as well as renaming pcregexp.cc to >>>> pcregexp.cc.in and doing a variable substitution: >>>> >>> ... >>> >>> At this moment I am not even sure that this is not a bug with the >>> pcre-devel >>> package. Perhaps, they should have made a symlink >>> pcre.h -> pcre/pcre.h ? >> >> I think that Debian (and some other distros) modify the path to >> pcre.h. I notice now that there is a `pcre-config' available. Maybe >> we should rather use that to determine compiler flags. |
|
From: Dmitri A. S. <das...@gm...> - 2005-05-30 04:03:25
|
Paul Kienzle wrote: > I'll apply this patch, but I'm not too thrilled about relying on the > existence of pcre-config. Do we need a fallback which will search > for pcre.h and libpcre if pcre-config is not present? > > Thanks, > > - Paul > It looks to me that it is rather safe to assume that pcre.h is in standard include directory -- after some googling it looks to me that many other packages depend on it (number of reports in redhat's bugzilla also confirm that). Dmitri. -- |
|
From: Paul K. <pki...@us...> - 2005-05-30 04:39:03
|
On May 30, 2005, at 12:03 AM, Dmitri A. Sergatskov wrote: > Paul Kienzle wrote: >> I'll apply this patch, but I'm not too thrilled about relying on the >> existence of pcre-config. Do we need a fallback which will search >> for pcre.h and libpcre if pcre-config is not present? >> Thanks, >> - Paul > > It looks to me that it is rather safe to assume that pcre.h is in > standard include directory -- after some googling it looks to me > that many other packages depend on it > (number of reports in redhat's bugzilla also confirm that). So we don't need to rely on the existence of pcre-config, and I shouldn't apply the patch? - Paul |
|
From: Dmitri A. S. <das...@gm...> - 2005-05-30 04:56:55
|
Paul Kienzle wrote: > > So we don't need to rely on the existence of pcre-config, and I > shouldn't apply the patch? I do not know. I assume the following sequence would be good: -- check for pcre-config failing that, check for <pcre.h> failing that -- bail out. No, I do not have a patch :) > > - Paul > Dmitri. -- |
|
From: Paul K. <pki...@us...> - 2005-05-30 05:33:43
|
On May 30, 2005, at 12:56 AM, Dmitri A. Sergatskov wrote: > Paul Kienzle wrote: > >> So we don't need to rely on the existence of pcre-config, and I >> shouldn't apply the patch? > > I do not know. > I assume the following sequence would be good: > > -- check for pcre-config > failing that, check for <pcre.h> > failing that -- bail out. > > No, I do not have a patch :) > I did the other order. Let me know if it works. - Paul |
|
From: Dmitri A. S. <das...@gm...> - 2005-04-13 21:16:55
|
Stefan van der Walt wrote: > > I think that Debian (and some other distros) modify the path to > pcre.h. I notice now that there is a `pcre-config' available. Maybe > we should rather use that to determine compiler flags. > Yes we can use that: [dima@localhost ~]$ pcre-config --cflags -I/usr/include/pcre But it also means that actual source files should also have ugliness like #ifdef __HAVE_PCRE__ #include <pcre.h> #elsif __HAVE_PCRE_PCRE__ #include <pcre/pcre.h> ... It also appears that RH is switching back to normal location (at least pcre package from development tree has headers in /usr/include). So may be we just leave it as it is, perhaps add a warning that pcre.h should be symlinked to a standard location? > Regards > Stefan > Dmitri. -- |
|
From: Stefan v. d. W. <st...@su...> - 2005-04-13 21:57:49
|
On Wed, Apr 13, 2005 at 03:16:47PM -0600, Dmitri A. Sergatskov wrote: > Stefan van der Walt wrote: > > > > >I think that Debian (and some other distros) modify the path to > >pcre.h. I notice now that there is a `pcre-config' available. Maybe > >we should rather use that to determine compiler flags. > > > > Yes we can use that: > > [dima@localhost ~]$ pcre-config --cflags > -I/usr/include/pcre > > But it also means that actual source files should also have ugliness like > > #ifdef __HAVE_PCRE__ > #include <pcre.h> > #elsif __HAVE_PCRE_PCRE__ > #include <pcre/pcre.h> This shouldn't be necessary if we specify -I/usr/lib/pcre Regards Stefan |
|
From: Dmitri A. S. <das...@gm...> - 2005-04-13 23:24:58
|
Stefan van der Walt wrote: > On Wed, Apr 13, 2005 at 03:16:47PM -0600, Dmitri A. Sergatskov wrote: > ... >> >>But it also means that actual source files should also have ugliness like >> >>#ifdef __HAVE_PCRE__ >> #include <pcre.h> >>#elsif __HAVE_PCRE_PCRE__ >> #include <pcre/pcre.h> > > > This shouldn't be necessary if we specify -I/usr/lib/pcre > Right you are. > Regards > Stefan > Dmitri. -- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X