[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving `migcom' out of `[exec_prefix]/libexec/'

From: Thomas Schwinge
Subject: Re: Moving `migcom' out of `[exec_prefix]/libexec/'
Date: Sat, 9 Dec 2006 17:04:27 +0100
User-agent: Mutt/1.5.9i


On Thu, Dec 07, 2006 at 12:14:53AM +0100, I wrote:
> On Wed, Nov 29, 2006 at 04:28:00PM -0800, Roland McGrath wrote:
> > Using gcc driver with a custom specs file is probably not really hard.
> I had a look.  After having read about that specs file language I first
> was under the same impression and was full of enthousiasm to do that.
> But it now seems to me that the specs file language is not powerful
> enough to properly handle that task and also that

To elaborate on that a bit further: from
<http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html>: ``It is built into
GCC which switches take arguments and which do not.  [...]''.  This means
we can't convince it to a syntax like ``gcc -user FILE'' or (avoiding to
pollute general name spaces) ``gcc -Xmig-user FILE'', but would have to
use a syntax like ``gcc -Xmig-user=FILE'', which seems to be a bit
awkward to use.  So far I had no succes to get a syntax like ``gcc
-Wmig,-user,FILE'' to work.  Given all that, we'd still want to use a
(shell script) frontend that keeps up the current `mig' command line
interface.  But then I don't know if it's still worthwhile to do the
specs file dance at all.

> it might not be portable enough between different versions of GCC.

To complicate matters further this was confirmed by GCC's Andrew Pinski:
``specs are an internal format really.  It is very subject to change each
release.  Also some time in the future we might decide to get rid of the
specs.'', see <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30091#c2>.

> So, did you alread have specific ideas about how to do that?

Did you mean to do this task differently from what I've outlined above?

My unfinished specs file is attached to this email.


Attachment: specs_for_mig
Description: Text document

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]