build failure due to observer.sh

build failure due to observer.sh

[Joel Brobecker]

Hello,

The build failed on most of our machines, due to a problem happening
during the sed command in observer.sh. Here is the output we got:

        Creating observer.h-tmp
        sed:     # Save original line for later processing into the actual parameter is not a recognized function.

As a consequence, all observers are missing, and we fail during the link.

I tried on AiX to remove the comments, to see if it works any better,
and managed to get past this error. Are comments a GNU sed extension?

In my opinion, I would handle observer.sh the same as gdbarch.sh:
The contributors run it manually when needed. And we keep and up-to-date
version of observer.[hc] checked in the repository. That way, we avoid
requiring a certain implementation of sed when just building GDB.

I can regenerate observer.[hc] and check them in, if you agree.

-- 
Joel

Re: build failure due to observer.sh

[Andrew Cagney]

> Hello,
> 
> The build failed on most of our machines, due to a problem happening
> during the sed command in observer.sh. Here is the output we got:
> 
>         Creating observer.h-tmp
>         sed:     # Save original line for later processing into the actual parameter is not a recognized function.
> 
> As a consequence, all observers are missing, and we fail during the link.
> 
> I tried on AiX to remove the comments, to see if it works any better,
> and managed to get past this error. Are comments a GNU sed extension?

I don't think so, just sounds like it isn't a common extension, do the 
comments need to be in column one?  With the comments removed did it build?

> In my opinion, I would handle observer.sh the same as gdbarch.sh:
> The contributors run it manually when needed. And we keep and up-to-date
> version of observer.[hc] checked in the repository. That way, we avoid
> requiring a certain implementation of sed when just building GDB.

Having this built on-demand is one of the departures from gdbarch.sh 
(and why I committed this now, so early in a release cycle).  I'd like 
to see how unfixable the problem is before abandoning the idea.

> I can regenerate observer.[hc] and check them in, if you agree.

Lets first move the comments to outside of the sed line.  After that the 
SED can be simplified by using separate extracts for formal and actual. 
  If those fail, then yes, I guess we go back to generated observers.

Andrew

Re: build failure due to observer.sh

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

> I don't think so, just sounds like it isn't a common extension, do the 
> comments need to be in column one?

Moving the comments to column one seems to be fixing the problem.
I tested the attached patch on ppc-aix 5.1 (/usr/bin/sed),
alpha-tru64 5.1 (/usr/bin/sed), and solaris 2.5+2.8 (usr/xpg4/bin/sed).
It worked in all cases.

> Having this built on-demand is one of the departures from gdbarch.sh 
> (and why I committed this now, so early in a release cycle).  I'd like 
> to see how unfixable the problem is before abandoning the idea.

OK. I tend to prefer to have all files under revision control, generated
files included. That's because when somebody tells us about a problem,
we are certain about the sources he used. If some of the files are
generated on demand, then we have to consider the possibility of him
having experienced a problem during the generation.

Hardly an important issue, though.

2004-04-16  Joel Brobecker  <brobecker@gnat.com>

        * observer.sh: Move comments in sed command to first column.

Ok to apply?

Thanks,
-- 
Joel

[-- Attachment #2: observer.sh.diff --]
[-- Type: text/plain, Size: 1331 bytes --]

Index: observer.sh
===================================================================
RCS file: /cvs/src/src/gdb/observer.sh,v
retrieving revision 1.1
diff -u -p -r1.1 observer.sh
--- observer.sh	15 Apr 2004 14:29:20 -0000	1.1
+++ observer.sh	16 Apr 2004 20:39:48 -0000
@@ -62,22 +62,22 @@ esac
 IFS=:
 sed -n '
 /@deftypefun void/{
-    # Save original line for later processing into the actual parameter
+# Save original line for later processing into the actual parameter
     h
-    # Convert from: @deftypefun void EVENT (TYPE @var{PARAM},...)
-    # to event and formals: EVENT:TYPE PARAM, ...:
+# Convert from: @deftypefun void EVENT (TYPE @var{PARAM},...)
+# to event and formals: EVENT:TYPE PARAM, ...:
     s/^.* void \([a-z_][a-z_]*\) (\(.*\))$/\1:\2/
     s/@var{//g
     s/}//g
-    # Switch to held
+# Switch to held
     x
-    # Convert from: @deftypefun void FUNC (TYPE @var{PARAM},...)
-    # to actuals: PARAM, ...
+# Convert from: @deftypefun void FUNC (TYPE @var{PARAM},...)
+# to actuals: PARAM, ...
     s/^[^{]*[{]*//
     s/[}]*[^}]*$//
     s/}[^{]*{/, /g
-    # Combine held (EVENT:TYPE PARAM, ...:) and pattern (PARAM, ...) into
-    # FUNC:TYPE PARAM, ...:PARAM, ...
+# Combine held (EVENT:TYPE PARAM, ...:) and pattern (PARAM, ...) into
+# FUNC:TYPE PARAM, ...:PARAM, ...
     H
     x
     s/\n/:/g

Re: build failure due to observer.sh

[Andrew Cagney]

> 2004-04-16  Joel Brobecker  <brobecker@gnat.com>
> 
>         * observer.sh: Move comments in sed command to first column.
> 
> Ok to apply?

Yes, and thanks.

Andrew

Re: build failure due to observer.sh

[Joel Brobecker]

> >2004-04-16  Joel Brobecker  <brobecker@gnat.com>
> >
> >        * observer.sh: Move comments in sed command to first column.
> >
> >Ok to apply?
> 
> Yes, and thanks.

Thank you, checked in.

-- 
Joel

Re: build failure due to observer.sh

[Andrew Cagney]

>>I don't think so, just sounds like it isn't a common extension, do the 
>>> comments need to be in column one?
> 
> 
> Moving the comments to column one seems to be fixing the problem.
> I tested the attached patch on ppc-aix 5.1 (/usr/bin/sed),
> alpha-tru64 5.1 (/usr/bin/sed), and solaris 2.5+2.8 (usr/xpg4/bin/sed).
> It worked in all cases.
> 
> 
>>> Having this built on-demand is one of the departures from gdbarch.sh 
>>> (and why I committed this now, so early in a release cycle).  I'd like 
>>> to see how unfixable the problem is before abandoning the idea.
> 
> 
> OK. I tend to prefer to have all files under revision control, generated
> files included. That's because when somebody tells us about a problem,
> we are certain about the sources he used. If some of the files are
> generated on demand, then we have to consider the possibility of him
> having experienced a problem during the generation.

[picking other half of thread]

What about doing the same as for .y and .l files?  Generate them when 
not there, but also bundle generated versions as part of the distro? 
Aat one stage the repository did contain generated lex/yacc files but 
they were removed as they were often out-of-sync and/or badly date-stamped.

Andrew

(for configure, yes, I agree that it should be generated, it's just to 
big, complicated, and exposed to the local SH version's wim.)

Re: build failure due to observer.sh

[Joel Brobecker]

> What about doing the same as for .y and .l files?  Generate them when 
> not there, but also bundle generated versions as part of the distro? 

A reasonable compromise, indeed. We can ask the people building from CVS
to have all the necessary tools, but provide these files in our
releases.

-- 
Joel

Re: build failure due to observer.sh

[Jim Blandy]

Joel Brobecker <brobecker@gnat.com> writes:
> I tried on AiX to remove the comments, to see if it works any better,
> and managed to get past this error. Are comments a GNU sed extension?

sed comments, with leading blanks, are described in POSIX.