cscope-devel

Re: [Cscope-devel] Source Tagged v15_0_bl2

[Joshua U. <uz...@li...>]

* Petr Sorfa <pe...@sc...> [000509 09:43]:
> Just one thing, a chap called  Peeter J. sent me an updated spec file,
> so I guess we should use that. I'll add a new directory called packages
> with the spec file. Any packaging info should be placed in their as well
> (e.g. UW7 pkg scripts, etc..) I'll send some e-mail out when its setup.

Cool... send i to me... or I might even urge distributing spec files
(or the like) so as to make it easier for people to build packages for
themselves.  Very few packages do this, and I'd like to set an example.

> > Via Jes Sorensen? :)
> Err, been working with the IA64 for almost 3 years.

Ahh, well, Jes has been for a while as well... he was bitching (as
he always does, but that's why we love him) to me that he wanted a
ia64 rpm and was pondering sending you one. :)

-- 
Joshua Uziel, Senior Linux Consultant, Linuxcare, Inc.
415.354.4878 tel, 415.701.7457 fax
uz...@li..., http://www.linuxcare.com/
Linuxcare. Support for the revolution.

[Cscope-devel] Developer Notes

[Petr S. <pe...@us...>]

Hi All,

It may seem a little pedantic, but here are a couple of developer notes to
make things easier for all of us:

- Whenever any change is made to CVS, please update the ChangeLog file
- Whenever any change is made to CVS, please e-mail cscope-devel, even
  if mention was made of the change in another e-mail. I'm looking
  at automating this process, but sourceforge places quite a few restrictions
  on CVS functionality
- If you wish to create/delete any directories or files, please ask me first
- If you wish to preform any special CVS functions, like tagging or branch
  creation, please ask me first
- If you are not a hundred percent sure about the changes you have made
  rather e-mail the changes to the cscope-devel mailing list for
  review

Thanks for all the great work and effort.

Petr

Re: [Cscope-devel] flex/yacc finding: why not use automake?

[Petr S. <pe...@sc...>]

Hi All,

Folks please hold off submitting code changes. Lets get bl2 out the door
before anything else.

Petr
> > On Mon May 08,2000 (06:19:30PM +0200), br...@ph...(Hans-Bernhard Broeker) wrote:
> [...]
> > > the experience of the FSF, as found in automake? They provide a script
> > > 'ylwrap' that sort of automatically finds and uses the right tools for the
> > > job.
> >
> > How does it define 'right tools for the job' ?
> 
> Well, on second reading of its spec, it doesn't. Sorry for spreading
> misinformation. But my original point was: cscope is by far not the first
> program on the open software market to be using lex and yacc, so I find it
> hard to believe it really should be necessary to roll our own autoconf
> macros to do that.
> 
> AFAICS, our current setup has three main differences to the default
> behaviour of automake/autoconf:
> 
> 1) we search for -ll or -lfl in /usr/local/lib, too
> 2) added 'configure' option --with-{name} for selecting an incarnation
>    of lex or yacc.
> 3) we always call 'flex' with the '-l' option.
> 
> For all three of these, I found existing or alternative means more
> 'natural' to either my usual compilation setup, or autoconf'ed
> package building.
> 
> 1) If you build packages remotely regularly, your compiler should already
>    be set up to find libraries in /usr/local/lib, without any need for
>    extra -L flags on the linking command line. This is what LIBRARY_PATH
>    exists for. Having no 'root' access, I have it containing
>    $HOME/alpha/lib:/usr/local/lib, e.g.
> 
> 1/2) Environment variables. E.g. if you want 'configure' to use 'lex',
>     'byacc', 'cc', and need to pass an additional library
>      path, setup the environment for 'configure', appropriately:
> 
>     env CC=cc LEX=lex YACC=byacc LDFLAGS=-L/usr/local/lib ./configure
> 
>     I cannot really see the need for extra configure code, down that
>     road.
> 
> 3) Instead of checking if LEX==flex, just to get the '-l' option
>    added to it, I just added a line %array to the scanner.l file.
>    That makes the one truly important change implied by the '-l'
>    option, already (yytext is forced to be an array).
> 
> Hans-Bernhard Broeker (br...@ph...)
> Even if all the snow were burnt, ashes would remain.
> 
> _______________________________________________
> Cscope-devel mailing list
> Csc...@li...
> http://lists.sourceforge.net/mailman/listinfo/cscope-devel

-- 
--------------------------------------------------------
Petr Sorfa                  Software Engineer
Santa Cruz Operation (SCO)  (908) 790 2376
430 Mountain Ave.           http://www.sco.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

Re: [Cscope-devel] flex/yacc finding: why not use automake?

[Hans-Bernhard B. <br...@ph...>]

On Mon, 8 May 2000, Mike Hopkirk(hops) wrote:

> On Mon May 08,2000 (06:19:30PM +0200), br...@ph...(Hans-Bernhard Broeker) wrote:
[...]
> > the experience of the FSF, as found in automake? They provide a script
> > 'ylwrap' that sort of automatically finds and uses the right tools for the
> > job.
> 
> How does it define 'right tools for the job' ? 

Well, on second reading of its spec, it doesn't. Sorry for spreading
misinformation. But my original point was: cscope is by far not the first
program on the open software market to be using lex and yacc, so I find it
hard to believe it really should be necessary to roll our own autoconf
macros to do that.

AFAICS, our current setup has three main differences to the default
behaviour of automake/autoconf:

1) we search for -ll or -lfl in /usr/local/lib, too
2) added 'configure' option --with-{name} for selecting an incarnation
   of lex or yacc.
3) we always call 'flex' with the '-l' option.

For all three of these, I found existing or alternative means more
'natural' to either my usual compilation setup, or autoconf'ed
package building.

1) If you build packages remotely regularly, your compiler should already
   be set up to find libraries in /usr/local/lib, without any need for
   extra -L flags on the linking command line. This is what LIBRARY_PATH
   exists for. Having no 'root' access, I have it containing 
   $HOME/alpha/lib:/usr/local/lib, e.g.

1/2) Environment variables. E.g. if you want 'configure' to use 'lex',
    'byacc', 'cc', and need to pass an additional library
     path, setup the environment for 'configure', appropriately:

    env CC=cc LEX=lex YACC=byacc LDFLAGS=-L/usr/local/lib ./configure

    I cannot really see the need for extra configure code, down that
    road.

3) Instead of checking if LEX==flex, just to get the '-l' option
   added to it, I just added a line %array to the scanner.l file.
   That makes the one truly important change implied by the '-l'
   option, already (yytext is forced to be an array).

Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Cscope-devel] Seems I fixed -q for 64bit Alpha.

[Petr S. <pe...@sc...>]

Hi Hans,

> Guarded by a suspicion that at least part of the roadblocking problems
> with -q I observed on DEC alpha, I sat down and tried to remove at least
> some of those problems --- with success, or so it seems to my
> inexperienced eye. I've just checked in the result: as version 1.7 of
> invlib.c, and version 1.2 of invlib.h. I would have made it a branch off
> v15_0_bl2, but for some reason SourceForge CVS doesn't let me do that :-(
Err, no branches please. May be useful for severe differences but not
here.

> I've crosschecked on an ix86 Linux-glibc1 box, and the changes don't seem
> to have broken anything, there, either. So, please, if you observed any -q
> problems, re-check them with this version.
Will do.

> The code is still a bit dirty. See the 'FIXME' comments I added where I
> think things will have to be polished even further.
Thanks,

Petr

> 
> Have fun with it
> Hans-Bernhard Broeker (br...@ph...)
> Even if all the snow were burnt, ashes would remain.
> 
> _______________________________________________
> Cscope-devel mailing list
> Csc...@li...
> http://lists.sourceforge.net/mailman/listinfo/cscope-devel

-- 
--------------------------------------------------------
Petr Sorfa                  Software Engineer
Santa Cruz Operation (SCO) 
430 Mountain Ave.           http://www.sco.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

Re: [Cscope-devel] Source Tagged v15_0_bl2

[Petr S. <pe...@sc...>]

Hi Joshua,

> > Petr: src.rpm, src.tar, Redhat 6.2 i386.rpm, UW7 pkg
> > Mike: OSR5 custom
> > Uzi: Sparc?, ?
> > Hans: Alpha?, ?
> 
> Ok... gimme the src.rpm so I don't have to reinvent the wheel. :)
> I'll see about a Solaris package maaaaaaaaaaaaaybe... or maybe I'll
> just make a tarball.  Sparc/Linux is no problem.
Just one thing, a chap called  Peeter J. sent me an updated spec file,
so I guess we should use that. I'll add a new directory called packages
with the spec file. Any packaging info should be placed in their as well
(e.g. UW7 pkg scripts, etc..) I'll send some e-mail out when its setup.

> > I may also make available an ia64.rpm
> 
> Via Jes Sorensen? :)
Err, been working with the IA64 for almost 3 years.

Petr
> 
> --
> Joshua Uziel, Senior Linux Consultant, Linuxcare, Inc.
> 415.354.4878 tel, 415.701.7457 fax
> uz...@li..., http://www.linuxcare.com/
> Linuxcare. Support for the revolution.

-- 
--------------------------------------------------------
Petr Sorfa                  Software Engineer
Santa Cruz Operation (SCO)  
430 Mountain Ave.           http://www.sco.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

[Cscope-devel] Seems I fixed -q for 64bit Alpha.

[Hans-Bernhard B. <br...@ph...>]

Hello, all

Guarded by a suspicion that at least part of the roadblocking problems
with -q I observed on DEC alpha, I sat down and tried to remove at least
some of those problems --- with success, or so it seems to my
inexperienced eye. I've just checked in the result: as version 1.7 of
invlib.c, and version 1.2 of invlib.h. I would have made it a branch off
v15_0_bl2, but for some reason SourceForge CVS doesn't let me do that :-(

I've crosschecked on an ix86 Linux-glibc1 box, and the changes don't seem
to have broken anything, there, either. So, please, if you observed any -q
problems, re-check them with this version.

The code is still a bit dirty. See the 'FIXME' comments I added where I
think things will have to be polished even further.

Have fun with it
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Cscope-devel] Source Tagged v15_0_bl2

[Joshua U. <uz...@li...>]

* Petr Sorfa <pe...@us...> [000508 15:01]:
> Package assignments:
> 
> Petr: src.rpm, src.tar, Redhat 6.2 i386.rpm, UW7 pkg
> Mike: OSR5 custom
> Uzi: Sparc?, ?
> Hans: Alpha?, ?

Ok... gimme the src.rpm so I don't have to reinvent the wheel. :)
I'll see about a Solaris package maaaaaaaaaaaaaybe... or maybe I'll
just make a tarball.  Sparc/Linux is no problem.

> I may also make available an ia64.rpm

Via Jes Sorensen? :)

-- 
Joshua Uziel, Senior Linux Consultant, Linuxcare, Inc.
415.354.4878 tel, 415.701.7457 fax
uz...@li..., http://www.linuxcare.com/
Linuxcare. Support for the revolution.

[Cscope-devel] Source Tagged v15_0_bl2

[Petr S. <pe...@us...>]

Hi Folks,

The source tree has been tagged ad v15_0_bl2.

Please starting preparing the packages for distribution.

Also provide release notes for platform problems.

Package assignments:

Petr: src.rpm, src.tar, Redhat 6.2 i386.rpm, UW7 pkg
Mike: OSR5 custom
Uzi: Sparc?, ?
Hans: Alpha?, ?

I may also make available an ia64.rpm

The -q problems are ok with the current source, but I think when you
rebuild from the .am and .in files problems arise. Needs further investigation
in bl3

Many thanks,

Petr

Re: [Cscope-devel] flex/yacc finding: why not use automake?

[Mike Hopkirk(hops) <ho...@sc...>]

On Mon May 08,2000 (06:19:30PM +0200), br...@ph...(Hans-Bernhard Broeker) wrote:
> Hello, all.
> 
> Seeing all the problems about locating the right lex or yacc
> automatically, I wonder if there is any particular reason we aren't using
> the experience of the FSF, as found in automake? They provide a script
> 'ylwrap' that sort of automatically finds and uses the right tools for the
> job.

How does it define 'right tools for the job' ? 
especially where theres the possibility of several of the tools being 
available..

The discussion of ylwrap I skimmed in automake-1.4 seems to indicate its more
for supporting several yacc invocations in a single binary than 
discovery of the 'right' lerxer/yakkity-yaccer

>  Our current method smells like we're reinventing a wheel, to me.

What does that give you that the current probing-with-overide does not ?

-- 
- hops

Everything disclaimed (including disclaimer)
------<ho...@sc...>--------------------------------------
Mike Hopkirk (hops)  |       Whenever possible steal code.
SCO Inc              |          Tom Duff. (ex) Bell Labs

[Cscope-devel] -q problems still exist

[Petr S. <pe...@us...>]

Hi Folks,

Sorry about this, but it looks like the -q options is still bust.

I'm going to try and fix it, but if it fails I'll back out some of the
source code changes until it works again.

Petr

Re: [Cscope-devel] flex/yacc finding: why not use automake?

[Joshua U. <uz...@li...>]

* Hans-Bernhard Broeker <br...@ph...> [000508 10:59]:
> Seeing all the problems about locating the right lex or yacc
> automatically, I wonder if there is any particular reason we aren't using
> the experience of the FSF, as found in automake? They provide a script
> 'ylwrap' that sort of automatically finds and uses the right tools for the
> job. Our current method smells like we're reinventing a wheel, to me.

Heh... our autoconf/automake setup was my first time mucking with
those tools... I used the method I found documented in the various
online tutorials.  If you know a better way, then by all means,
feel free to fix it. :)

-- 
Joshua Uziel, Senior Linux Consultant, Linuxcare, Inc.
415.354.4878 tel, 415.701.7457 fax
uz...@li..., http://www.linuxcare.com/
Linuxcare. Support for the revolution.

[Cscope-devel] bl2 release schedule

[Petr S. <pe...@us...>]

Hi Folks,

At 4pm EST I'll tag the current source as v15_0_bl2. We can then
prepare the packages for release.

I'm looking at making the packages available thursday or friday, giving
folks enough time to make the packages up and any high priority necessary
fixes.

If any fixes go in before we make the packages available, I'll retag the
affected files as bl2.

Thanks for a job well done to all,

Petr

Re: [Cscope-devel] flex/yacc finding: why not use automake?

[Petr S. <pe...@sc...>]

Hi Hans,

> Seeing all the problems about locating the right lex or yacc
> automatically, I wonder if there is any particular reason we aren't using
> the experience of the FSF, as found in automake? They provide a script
> 'ylwrap' that sort of automatically finds and uses the right tools for the
> job. Our current method smells like we're reinventing a wheel, to me.
Ok, we can look at this for bl3.

Petr
-- 
--------------------------------------------------------
Petr Sorfa                  Software Engineer
Santa Cruz Operation (SCO)  
430 Mountain Ave.           http://www.sco.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

Re: [Cscope-devel] Src seems stable

[Petr S. <pe...@sc...>]

Hi Hans,

Thanks for looking at the problem. I guess we can not worry about the -q
option for the Alpha.

Thanks,

Petr
> > It seems that the src is stable with Mike's changes. It seems that the
> > -q problem went away with the changes made to the autoconf files.
> >
> > Can everybody please confirm this?
> 
> Although I'm not exactly what the difference between normal operation and
> '-q' mode of cscope is supposed to feel like, there definitely is a
> remaining problem, here.
> 
> The same code version (current top-of-tree) working nicely in -q mode on a
> Linux-glibc1/x86 machine behaves noticeably different on an Alpha box
> running Digital Unix. On the Alpha, no symbol search in -q mode ever seems
> to succeed. I don't think this ever worked, on that machine, actually. Let
> me show some example output:
> 
> acaxp6-broeker cscope/alpha/src> ./cscope -ql ../../src/*.[chly]
> >> 0main
> Unaligned access pid=14141 <cscope> va=0x140041664 pc=0x1200179b8
> ra=0x120017998 inst=0xa4090008
> cscope: 0 lines
> >> 1main
> Unaligned access pid=14141 <cscope> va=0x140041664 pc=0x1200179b8
> ra=0x120017998 inst=0xa4090008
> cscope: 0 lines
> >> q
> 
> The 'pc' of that unligned access warning is the 'return' statement of
> invterm(), so this may well be related to the '-q' misbehaviour.
> I managed to trace this back to the return type of invterm(). The
> structure element it's accessing is of type 'long':
> 
> typedef struct  {
>         short   offset;         /* offset in this logical block */
>         unsigned char size;     /* size of term */
>         unsigned char space;    /* number of longs of growth space */
>         long    post;           /* number of postings for this entry */
> } ENTRY;
> 
> The address calculation for the the pointer 'entry' in invterm looks more
> than suspicious, to me. Esp. that 'magic number' 12 being added to some
> 'char *' field of another structure looks like a bad problem waiting to
> happen. The fact that 'long' is 64bit on an Alpha may be the ingredient
> that triggers this bug, but the real problem is in the source, I guess.
> 
> More to come, but not today.
> 
> Hans-Bernhard Broeker (br...@ph...)
> Even if all the snow were burnt, ashes would remain.
> 
> _______________________________________________
> Cscope-devel mailing list
> Csc...@li...
> http://lists.sourceforge.net/mailman/listinfo/cscope-devel

-- 
--------------------------------------------------------
Petr Sorfa                  Software Engineer
Santa Cruz Operation (SCO)
430 Mountain Ave.           http://www.sco.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

Re: [Cscope-devel] Src seems stable

[Hans-Bernhard B. <br...@ph...>]

On Mon, 8 May 2000, Petr Sorfa wrote:

> It seems that the src is stable with Mike's changes. It seems that the
> -q problem went away with the changes made to the autoconf files.
> 
> Can everybody please confirm this?

Although I'm not exactly what the difference between normal operation and
'-q' mode of cscope is supposed to feel like, there definitely is a
remaining problem, here. 

The same code version (current top-of-tree) working nicely in -q mode on a
Linux-glibc1/x86 machine behaves noticeably different on an Alpha box
running Digital Unix. On the Alpha, no symbol search in -q mode ever seems
to succeed. I don't think this ever worked, on that machine, actually. Let
me show some example output:

acaxp6-broeker cscope/alpha/src> ./cscope -ql ../../src/*.[chly]
>> 0main
Unaligned access pid=14141 <cscope> va=0x140041664 pc=0x1200179b8
ra=0x120017998 inst=0xa4090008
cscope: 0 lines
>> 1main
Unaligned access pid=14141 <cscope> va=0x140041664 pc=0x1200179b8
ra=0x120017998 inst=0xa4090008
cscope: 0 lines
>> q

The 'pc' of that unligned access warning is the 'return' statement of
invterm(), so this may well be related to the '-q' misbehaviour.
I managed to trace this back to the return type of invterm(). The
structure element it's accessing is of type 'long':

typedef struct  {
        short   offset;         /* offset in this logical block */
        unsigned char size;     /* size of term */
        unsigned char space;    /* number of longs of growth space */
        long    post;           /* number of postings for this entry */
} ENTRY;

The address calculation for the the pointer 'entry' in invterm looks more
than suspicious, to me. Esp. that 'magic number' 12 being added to some
'char *' field of another structure looks like a bad problem waiting to
happen. The fact that 'long' is 64bit on an Alpha may be the ingredient
that triggers this bug, but the real problem is in the source, I guess.

More to come, but not today.

Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[Cscope-devel] flex/yacc finding: why not use automake?

[Hans-Bernhard B. <br...@ph...>]

Hello, all.

Seeing all the problems about locating the right lex or yacc
automatically, I wonder if there is any particular reason we aren't using
the experience of the FSF, as found in automake? They provide a script
'ylwrap' that sort of automatically finds and uses the right tools for the
job. Our current method smells like we're reinventing a wheel, to me.

Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[Cscope-devel] Src seems stable

[Petr S. <pe...@us...>]

Hi All,

It seems that the src is stable with Mike's changes. It seems that the
-q problem went away with the changes made to the autoconf files.

Can everybody please confirm this?

Thanks,

Petr

Re: [Cscope-devel] BL2 tag on May 5th 4pm EST

[Mike Hopkirk(hops) <ho...@sc...>]

On Fri May 05,2000 (01:14:57PM -0400), pe...@sc...(Petr Sorfa) wrote:
> Hi Joshua,
> 
> > > We need a BSD release as well (src and bin). Anybody got access to a BSD
> > > machine?
> 
> > Autoconf seems also to be missing at least one macro, where can I get
> > it?
> > autoconf: Undefined macros:
> > configure.in:104:      AC_LINK_IFELSE([`cat $LEX_OUTPUT_ROOT.c`], ac_cv_prog_lex_yytext_pointer=yes)
> 
> Any ideas here as well?

update autoconf to autoconf-2.13 ( dist from prep.ai.mit.edu)
autoconf --version reports itself as 2.14a.

(configure.in now changed so works with autoconf v2.13).

-- 
- hops

Everything disclaimed (including disclaimer)
------<ho...@sc...>--------------------------------------
Mike Hopkirk (hops)  |       Whenever possible steal code.
SCO Inc              |          Tom Duff. (ex) Bell Labs

Re: [Cscope-devel] ANOTHER URGENT ERROR: -q fails to work

[Mike Hopkirk(hops) <ho...@sc...>]

On Fri May 05,2000 (12:21:10PM -0700), pe...@us...(Petr Sorfa) wrote:
> Hi Folks,
> 
> Bad news, -q fails to work. It is either the recent code changes made by
> Mike or Hans.

I don't have Hans changes updated into my codebase and -q works fine.

-- 
- hops

Everything disclaimed (including disclaimer)
------<ho...@sc...>--------------------------------------
Mike Hopkirk (hops)  |       Whenever possible steal code.
SCO Inc              |          Tom Duff. (ex) Bell Labs

Re: [Cscope-devel] MAJOR ERROR: bl2 tag may be delayed

[Mike Hopkirk(hops) <ho...@sc...>]

On Fri May 05,2000 (12:15:23PM -0700), pe...@us...(Petr Sorfa) wrote:
> Hi Folks,
> 
> 
> Can we have this fixed ASAP. As it will delay the tagging.

I've put an updated configure.in (and configure) into the src tree 
that works with the redhat supplied version of autoconf-2.13 (autoconf v2.13). 
It also works with the gnu autoconf-2.13 (autoconf v2.14a)

Please retest on your systems that it was failing with...

-- 
- hops

Everything disclaimed (including disclaimer)
------<ho...@sc...>--------------------------------------
Mike Hopkirk (hops)  |       Whenever possible steal code.
SCO Inc              |          Tom Duff. (ex) Bell Labs

Re: [Cscope-devel] MAJOR ERROR: bl2 tag may be delayed

[Mike Hopkirk(hops) <ho...@sc...>]

On Fri May 05,2000 (12:15:23PM -0700), pe...@us...(Petr Sorfa) wrote:
> Hi Folks,
> 
> Looks like that Mike's changes cause problems on several OS, including Redhat 6.2:
> 
> AC_LINK_IFELSE([`cat $LEX_OUTPUT_ROOT.c`], ac_cv_prog_lex_yytext_pointer=yes)
> 
> line in configure.in is causing undefined macro errors.
> 
> Can we have this fixed ASAP. As it will delay the tagging.

What version of autoconf and automake do rhat 6.2 use ?
I had to rebuild my versions of autoconf 
(2.13 - however autoconf --version gives 2.14a (:-o))
and automake (1.4) just to get the old configure to work...

The interior of those macros was copied from the same macros in the
autoconf-2.13 distribution - 

Looks like prev versions were made with an autoconf that labelled itself
2.13...

prep has autoconf-2.13 dist which contains autoconf advertising itself as 2.14a
and  autoconf-2.12 which contains autoconf advertising itself as 2.12

so where did folks get an autoconf calling itself 2.13 ?

using 2.12 works if change offending line to
AC_TRY_LINK(`cat $LEX_OUTPUT_ROOT.c`, , ac_cv_prog_lex_yytext_pointer=yes)

( and you also need to remove calls to macros AH_CHECK_LIB in 
    ACNU_PROG_LEX)
but then it doesn't substite @SHELL@.





> 
> Petr
> 
> _______________________________________________
> Cscope-devel mailing list
> Csc...@li...
> http://lists.sourceforge.net/mailman/listinfo/cscope-devel

-- 
- hops

Everything disclaimed (including disclaimer)
------<ho...@sc...>--------------------------------------
Mike Hopkirk (hops)  |       Whenever possible steal code.
SCO Inc              |          Tom Duff. (ex) Bell Labs

[Cscope-devel] bl2 tagging delayed till Monday 4pm EST

[Petr S. <pe...@us...>]

Hi All,

Ok, since 4pm EST has just come and gone, I've decided to delay the bl2 tagging
till monday 4pm EST.

Any errors detected an hour before the tagging will be backed out.

For bl3 I'll implement a testing procedure that will hopefully prevent this
from happening again.

Anyway good work to everybody and hold your thumbs for Monday. If we were in
the same area (state, country, continent) we'd have a good party.

Petr

[Cscope-devel] ANOTHER URGENT ERROR: -q fails to work

[Petr S. <pe...@us...>]

Hi Folks,

Bad news, -q fails to work. It is either the recent code changes made by
Mike or Hans.

Please get on this now. I will wait till Monday 4pm EST to tag. If these problems are not solved by then, I will back out changes until I'm happy that we
have a stable cscope.

Petr

[Cscope-devel] MAJOR ERROR: bl2 tag may be delayed

[Petr S. <pe...@us...>]

Hi Folks,

Looks like that Mike's changes cause problems on several OS, including Redhat 6.2:

AC_LINK_IFELSE([`cat $LEX_OUTPUT_ROOT.c`], ac_cv_prog_lex_yytext_pointer=yes)

line in configure.in is causing undefined macro errors.

Can we have this fixed ASAP. As it will delay the tagging.

Petr