public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Geoff Keating <geoffk@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: rewrite lib/g77.exp
Date: Fri, 16 Nov 2001 12:45:00 -0000	[thread overview]
Message-ID: <or7kscaf1y.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: Geoff Keating's message of "26 Nov 2001 13:09:43 -0800"

On Nov 26, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
>> 
>> > Libstdc++ is not built on the host.  Test programs are.
>> 
>> Test programs are built for the target on the build machine, just like
>> libgcc, libstdc++, libobjc, libjava and libf2c.

> That would be pointless; we want to test the compiler that we just
> built, which may only run on the host.

I don't see how our current test-in-build-tree machinery could handle
this any differently.  Of course, we want to test the compiler we just
built, but if it won't run on the build machine, either we have to
install it and use some alternate testing machinery that uses an
installed compiler on the host, or we end up using for testing the
previously-installed build-x-target compiler used as part of the
host-x-target-on-build Canadian cross, which would be useless in terms
of testing the new compiler.

> Hmmm.  Do we really want to have a test procedure for testing in the
> build tree that's so different from how the user will likely use gcc?
> I mean, a libtool wrapper script is a lot of machinery.

If we want to test in the build tree, this is a must on at least one
platform, unless we get the test machinery to set up PATH correctly
such that Windows DLLs are found in the build tree.  Libtool would
only create such a wrapper script as a last resource, remember.
Besides, the current wrapper script is *very* simple.  Something like
setting LD_LIBRARY_PATH and running the program.  For Windows, this
gets to be a bit more complicated, since a shell script may not work
(think of Cygwin boxes without user-tools, i.e, no /bin/sh, or with
only the Cygwin DLL, or perhaps even without the DLL).

Of course, we're not going to run into this when testing in the build
tree, but libtool may eventually have to deal with this for
installable programs.  It's not of our (GCC) concern anyway.  Only the
simple wrapper scripts are.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

WARNING: multiple messages have this Message-ID
From: Alexandre Oliva <aoliva@redhat.com>
To: Geoff Keating <geoffk@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: rewrite lib/g77.exp
Date: Mon, 26 Nov 2001 22:44:00 -0000	[thread overview]
Message-ID: <or7kscaf1y.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
Message-ID: <20011126224400.uoOSUBZOmvh-0EPdHtb_p9FrzGCTxHW78iBahRS6RGk@z> (raw)
In-Reply-To: <jm8zctjl2g.fsf@geoffk.org>

On Nov 26, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
>> 
>> > Libstdc++ is not built on the host.  Test programs are.
>> 
>> Test programs are built for the target on the build machine, just like
>> libgcc, libstdc++, libobjc, libjava and libf2c.

> That would be pointless; we want to test the compiler that we just
> built, which may only run on the host.

I don't see how our current test-in-build-tree machinery could handle
this any differently.  Of course, we want to test the compiler we just
built, but if it won't run on the build machine, either we have to
install it and use some alternate testing machinery that uses an
installed compiler on the host, or we end up using for testing the
previously-installed build-x-target compiler used as part of the
host-x-target-on-build Canadian cross, which would be useless in terms
of testing the new compiler.

> Hmmm.  Do we really want to have a test procedure for testing in the
> build tree that's so different from how the user will likely use gcc?
> I mean, a libtool wrapper script is a lot of machinery.

If we want to test in the build tree, this is a must on at least one
platform, unless we get the test machinery to set up PATH correctly
such that Windows DLLs are found in the build tree.  Libtool would
only create such a wrapper script as a last resource, remember.
Besides, the current wrapper script is *very* simple.  Something like
setting LD_LIBRARY_PATH and running the program.  For Windows, this
gets to be a bit more complicated, since a shell script may not work
(think of Cygwin boxes without user-tools, i.e, no /bin/sh, or with
only the Cygwin DLL, or perhaps even without the DLL).

Of course, we're not going to run into this when testing in the build
tree, but libtool may eventually have to deal with this for
installable programs.  It's not of our (GCC) concern anyway.  Only the
simple wrapper scripts are.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

  reply	other threads:[~2001-11-27  6:44 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-13 15:03 Kaveh R. Ghazi
2001-11-14 15:45 ` Alexandre Oliva
2001-11-14 16:42   ` Geoff Keating
2001-11-14 17:05     ` Alexandre Oliva
2001-11-14 17:18       ` Geoff Keating
2001-11-14 17:24         ` Alexandre Oliva
2001-11-15 18:36           ` Geoff Keating
2001-11-16 12:45             ` Alexandre Oliva [this message]
2001-11-26 22:44               ` Alexandre Oliva
2001-11-26 13:09             ` Geoff Keating
2001-11-24 23:46           ` Alexandre Oliva
2001-11-24 23:27         ` Geoff Keating
2001-11-24 22:38       ` Alexandre Oliva
2001-11-24 22:15     ` Geoff Keating
2001-11-14 16:55   ` Zack Weinberg
2001-11-14 17:05     ` Alexandre Oliva
2001-11-14 17:14       ` Zack Weinberg
2001-11-14 17:20         ` Alexandre Oliva
2001-11-24 23:44           ` Alexandre Oliva
2001-11-24 22:49         ` Zack Weinberg
2001-11-24 22:28       ` Alexandre Oliva
2001-11-24 22:23     ` Zack Weinberg
2001-11-24 19:55   ` Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
2001-10-28 16:51 Kaveh R. Ghazi
     [not found] ` <jm3d42qic9.fsf@geoffk.org>
2001-11-13 15:03   ` Alexandre Oliva
2001-10-28  5:44 Kaveh R. Ghazi
2001-10-28  9:37 ` Geoff Keating
2001-10-28  9:56   ` Franz Sirl
     [not found]   ` <REFOR1kDTM9wGmAf0Mj00001d53@eforward1.enom.com>
2001-10-28 10:10     ` Geoff Keating
2001-10-28 10:19       ` Franz Sirl
2001-10-23 13:42 Geoffrey Keating
2001-10-23 13:57 ` Joseph S. Myers
2001-10-23 14:40   ` Geoff Keating

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=or7kscaf1y.fsf@free.redhat.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=geoffk@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).