building snapshot on hp-ux with hp tools

building snapshot on hp-ux with hp tools

[Michael Elizabeth Chastain]

I'm building gdb+dejagnu-20040113.tar.bz2 on hpux 11.11 using
the hp-ux tools, and I'm running into two problems.

(1) expect doesn't build with hp-ux make.
    When I use gnu make, it builds fine.

(2) dejagnu doesn't build because it doesn't find a C++ compiler

I can think of several ways around this:

(A) Make snapshots with no expect+dejagnu, such as gdb-20040113.tar.bz2.
    Since our releases are like that, I think it's okay for our
    snapshots to be like that.

(B) Tell people who use snapshots to remove the expect and dejagnu
    subdirectories before building from source.

(C) Upgrade dejagnu in sourceware (and upstream if necessary) to make
    the C++ compiler optional.

Comments?

Michael C

Re: building snapshot on hp-ux with hp tools

[Andrew Cagney]

> I'm building gdb+dejagnu-20040113.tar.bz2 on hpux 11.11 using
> the hp-ux tools, and I'm running into two problems.
> 
> (1) expect doesn't build with hp-ux make.
>     When I use gnu make, it builds fine.

Does a more up-to-date expect build?
Per 
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1349
>  Will need to merge in changes that get expect/ to link against 
>  ../tcl/unix/libtcl*.a instead of the installed tcl.
I've found nothing else (but those configury changes looked nasty :-().

> (2) dejagnu doesn't build because it doesn't find a C++ compiler

It doesn't actually need the C++ compiler - its an unnecessary test in 
one of the subdirectories (examples?).  A quick hack may pasify it :-)

> I can think of several ways around this:
> 
> (A) Make snapshots with no expect+dejagnu, such as gdb-20040113.tar.bz2.
>     Since our releases are like that, I think it's okay for our
>     snapshots to be like that.

Historically expect and dejagnu have been bundled in with GDB to ensure 
that all parties are using a consistent test framework.  It might be 
time to cut our losses?

> (B) Tell people who use snapshots to remove the expect and dejagnu
>     subdirectories before building from source.

It's a workaround.

> (C) Upgrade dejagnu in sourceware (and upstream if necessary) to make
>     the C++ compiler optional.

Yes, someone was looking at that?  (BTW, upstream where?).

Andrew

Re: building snapshot on hp-ux with hp tools

[Daniel Jacobowitz]

On Tue, Jan 13, 2004 at 10:43:16AM -0500, Andrew Cagney wrote:
> >(C) Upgrade dejagnu in sourceware (and upstream if necessary) to make
> >    the C++ compiler optional.
> 
> Yes, someone was looking at that?  (BTW, upstream where?).

dejagnu@gnu.org ?  It's not all that responsive at the moment.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: building snapshot on hp-ux with hp tools

[Michael Elizabeth Chastain]

> Historically expect and dejagnu have been bundled in with GDB to ensure 
> that all parties are using a consistent test framework.  It might be 
> time to cut our losses?

Gcc has an "unbundled" strategy, so every gcc tester has to install
tcl+expect+dejagnu outside of gcc.  It works for them; they have a lot
of testing activity.  Look at http://gcc.gnu.org/ml/gcc-testresults .
I wish that gdb-testers looked like that.

> Does a more up-to-date expect build?

Errr, no.  expect 5.39 does not build on hppa2.0w-hp-hpux11.11 with
the hp ansi c compiler.  Configure craps out with:

  checking whether the compiler (gcc -pipe) actually works... configure:
  error: the native compiler is broken and won't compile.

I don't know what the gcc-testresults@ people are doing to work
around that.  Perhaps they always use gcc to build tcl+expect+dejagnu.

If we unbundle tcl+expect+dejagnu, then we can separate those problems
out.  As it is, I can't tell people to try gdb snapshots on hp-ux
(see pr gdb/1458, I can't reply to it with "try a snapshot").

The advantage of bundling is that, in principle, we can make things
easier for people, if add value to our bundled versions.  The
disadvantage of bundling is that we're not spending the effort to add
value so that the "+dejagnu" part of "gdb+dejagnu" just stops it from
building on some systems.

I'm favor of separating gdb from dejagnu.  Have a separate
"tcl+expect+dejagnu" tarball if you want, but no "gdb+dejagnu".

Michael C