This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] Support arm-android-eabi
- From: Daniel Jacobowitz <drow at false dot org>
- To: gcc-patches at gcc dot gnu dot org
- Date: Mon, 7 Jul 2008 18:26:04 -0400
- Subject: Re: [PATCH][ARM] Support arm-android-eabi
- References: <498552560806271116o2f5618f6m230c1453dfa873c4@mail.gmail.com> <48656BAA.9080107@codesourcery.com> <498552560806281105y4b57ba94p53d375cb5cafed3a@mail.gmail.com> <4867D662.2040203@codesourcery.com> <498552560806291228q25344823k4c3a9644c45f1cf2@mail.gmail.com> <4867E4D9.8040503@codesourcery.com> <498552560806301522l721a55d6qc31cf0e929f7e825@mail.gmail.com> <4869B235.1000909@codesourcery.com> <498552560806302249g3e88df22yc1f382e13a708ace@mail.gmail.com>
On Mon, Jun 30, 2008 at 10:49:10PM -0700, Doug Kwan (éæå) wrote:
> > I don't know. Do we do that in any other backend? In my ideal world,
> > there'd be a "--with-options=" option to configure that would cause the
> > driver to assume those options appeared on every command-line. Then, you
> > could just configure with that.
>
> I don't think we do that in any backend. My proposal is quite a hack.
> I like your idea better. It is sufficient for my purpose but I don't
> think a single option is sufficient in general. We may need a family
> of options for different front-end to pass front-end depended options.
> Passing specs will be even better IMHO.
Most backends accomplish your goal with tm_defines. You could use it
to set DRIVER_SELF_SPECS, for instance.
--
Daniel Jacobowitz
CodeSourcery