Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: fedor@gnu.org, fnasser@redhat.com, msalter@redhat.com
Cc: ezannoni@redhat.com, gdb-gnats@sources.redhat.com,
	gdb-patches@sources.redhat.com
Subject: Re: [RFA] ObjC Testsuite
Date: Mon, 03 Mar 2003 16:15:00 -0000	[thread overview]
Message-ID: <200303031615.h23GFBc26561@duracef.shout.net> (raw)

In gdb.objc/Makefile.in, the distclean goal needs these commands:

  distclean maintainer-clean realclean: clean
  	-rm -f Makefile config.status config.log

Specifically, distclean must remove config.status.  The release
packaging process depends on this.  First it configures the whole tree
and then it makes 'distclean' in the whole tree.  If a config.status
file is left alive after 'make distclean', then it will get into the
gdb.tar tarball, and 'configure' will fail because the config.status
file already exists.

As Elena Z mentioned, the name of the pthreads library varies
from system to system.  We've encountered -lpthreads, -lpthread,
and -lthread.  We have to figure out a way to handle this.

I think the cleanest way is to add 'proc gdb_compile_objc'
in lib/gdb.exp, similar to 'proc gdb_compile_pthreads'.  Then we
can mess with the internals of 'proc gdb_compile_objc' as needed.
For instance, on my system, native i686-pc-linux-gnu with gcc 3.2.2,
gcc needs only '-lobjc' without any explicit thread library in
order to link Objective C programs.  Fernando N and Mark S,
what do you think?

I'm okay with the names 'myclass.exp' and 'myclass.c'.  I wouldn't mind
if they became a bit less generic than 'my....'.  I don't like the names
'objc-class.exp' and 'objc-class.m' because these are already in the
objc directory, and 'objc-' just eats 5 characters of uniqueness that we
need for 8.3 uniqueness.

On the next submission, please use 'cvs diff -N' to include the new
files in the diff, rather than attaching a diff + a tarball.
That's easier for me.

We need one or more maintainers for the new gdb.objc.  I volunteer to
be one of the maintainers.  Adam, are you willing to be a maintainer?

Also, this whole review process is getting messy, we are going to have
several people pushing Adam in different directions.  I would like to
figure out *first* who are going to be the maintainer(s) of
gdb.objc, and then those people should be the reviewers of this patch.

Michael C


             reply	other threads:[~2003-03-03 16:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-03 16:15 Michael Elizabeth Chastain [this message]
2003-03-04  4:45 ` Adam Fedor
2003-03-04  6:42 ` richard
2003-03-04 14:54   ` Andrew Cagney
2003-03-05  6:15     ` richard
  -- strict thread matches above, loose matches on Subject: below --
2003-02-20  2:19 [RFA]: " Adam Fedor
2003-03-03  2:47 ` Elena Zannoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200303031615.h23GFBc26561@duracef.shout.net \
    --to=mec@shout.net \
    --cc=ezannoni@redhat.com \
    --cc=fedor@gnu.org \
    --cc=fnasser@redhat.com \
    --cc=gdb-gnats@sources.redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msalter@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox