This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: support non-libffi enabled platforms
- To: <green at cygnus dot com>
- Subject: Re: Patch: support non-libffi enabled platforms
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 15 Feb 2001 15:09:41 -0200
- Cc: <tromey at redhat dot com>, <java-patches at gcc dot gnu dot org>
- Organization: GCC Team, Red Hat
- References: <NEBBKJDPKLNNENPPIHCPCEHMKFAA.green@redhat.com>
On Feb 15, 2001, "Anthony Green" <green@redhat.com> wrote:
> Tom wrote:
>> However, couldn't we somehow ask libffi whether it should be used?
>> That way we only need to do the configure hacking in a single place.
>> Ideally libffi could tell us (1) if it works on the platform and (2)
>> if the closure code is supported on the platform.
> What do you think the best way of doing this is?
Have libffi never fail to configure. If it's to target an unsupported
platform, just create a libffi-config.h that says it's unsupported.
If it's on a supported target, have libffi-config.h tell whether
closure code is supported or not. Then, have configure tests that
#include libffi-config.h and decide whether to not use it at all, to
use it in a limited form or to use all of it.
If we went ahead and created an empty library for libffi even on
unsupported platforms, we wouldn't even need configure tests; it'd be
enough to arrange for all of libffi users to #include libffi-config.h
and disable the usage of features according to the macros defined
there. However, it might be better to have configure tests anyway; it
probably doesn't make sense to build a non-functional interpreter in
case libffi is totally unsupported.
--
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