From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [autodeps] gnu-nat, autogenerated files
Date: Wed, 10 Sep 2008 18:01:00 -0000 [thread overview]
Message-ID: <20080910180018.GP12222@adacore.com> (raw)
In-Reply-To: <200809091606.45512.pedro@codesourcery.com>
> 2008-09-09 Pedro Alves <pedro@codesourcery.com>
>
> * Makefile.in (generated_files): Add $(host_generated_files).
> * config/i386/i386gnu.mh (host_generated_files): New.
This one is a little beyond my knowledge of Makefile, particularly
since the build system has changed recently. The idea seems right to me
(adding a new variable in the mh file). But I'm still wondering whether
it would be possible to use the NAT_FILE to include the list of generated
files. Tom, what do you think? Probably be a little hacky...
If we introduce a new variable, I propose that its name be capitalized,
like most (if not all) variables we have been using so far. I like
HOST_GENERATED_FILES as you suggested.
We also need to document this new variable in gdbint. Perhaps around
there:
@table @file
@vindex NATDEPFILES
@item gdb/config/@var{arch}/@var{xyz}.mh
Specifies Makefile fragments needed by a @emph{native} configuration on
machine @var{xyz}. In particular, this lists the required
native-dependent object files, by defining @samp{NATDEPFILES=@dots{}}.
Also specifies the header file which describes native support on
@var{xyz}, by defining @samp{NAT_FILE= nm-@var{xyz}.h}. You can also
define @samp{NAT_CFLAGS}, @samp{NAT_ADD_FILES}, @samp{NAT_CLIBS},
@samp{NAT_CDEPS}, etc.; see @file{Makefile.in}.
@emph{Maintainer's note: The @file{.mh} suffix is because this file
originally contained @file{Makefile} fragments for hosting @value{GDBN}
on machine @var{xyz}. While the file is no longer used for this
purpose, the @file{.mh} suffix remains. Perhaps someone will
eventually rename these fragments so that they have a @file{.mn}
suffix.}
GMs, Tom, help!
--
Joel
next prev parent reply other threads:[~2008-09-10 18:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 15:07 Pedro Alves
2008-09-09 16:09 ` Tom Tromey
2008-09-09 16:18 ` Daniel Jacobowitz
2008-09-09 16:28 ` Tom Tromey
2008-09-10 18:01 ` Joel Brobecker [this message]
2008-09-10 18:13 ` Daniel Jacobowitz
2008-09-10 18:49 ` Pedro Alves
2008-09-12 5:06 ` Joel Brobecker
2008-09-12 9:10 ` Eli Zaretskii
2008-09-12 10:44 ` Pedro Alves
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=20080910180018.GP12222@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.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