[MPlayer-dev-eng] [PATCH] cross-compile: add --enable-cross-compile
Aurelien Jacobs
aurel at gnuage.org
Sat Oct 15 19:07:36 CEST 2005
On Thu, 13 Oct 2005 19:14:37 +0200
Oded Shimon <ods15 at ods15.dyndns.org> wrote:
> On Thu, Oct 13, 2005 at 07:02:43PM +0200, Diego Biurrun wrote:
> > On Thu, Oct 13, 2005 at 12:13:04AM +0200, Aurelien Jacobs wrote:
> > >
> > > --- ../main.test2/configure 2005-10-12 23:27:51.000000000 +0200
> > > +++ configure 2005-10-12 23:50:14.000000000 +0200
> > > @@ -54,6 +54,7 @@
> > > }
> > >
> > > tmp_run() {
> > > + test $_cross_compile = yes && return 0
> > > "$TMPO" >> "$TMPLOG" 2>&1
> > > }
> >
> > This may slow things down, since that test is run many many times. Why
> > not overload that function in the cross-compilation case?
>
> It really really really won't. "test" is an internal bash call, not a
> seperate program, so running it is near nothing, and the 'gcc' calls are
> like 99.9% of the time anyway. You're basically saving an "strcmp"...
I agree with this. I doubt you will be able to mesure any speed difference.
But still, here is a new version of the patch which overload tmp_run().
> I'm a bit more curious if this doesn't break any functionality, that is,
> will not running these tests actually give some wrong results?.. If it
> does, then it's a problem, and if it doesn't, then why do we run the tests
> at all?...
I must admit that I haven't tested with all the versions of all the
libraries supported by MPlayer. But with my common settings, there is no
difference between the ./configure result, wether I --enable-cross-compile
or not.
Maybe we could simply remove tmp_run() everywere, but I don't feel confident
enough to do this. At least for now it will allow everyone to test
--enable-cross-compile, and if no problem comes out, we may decide later
to drop tmp_run().
Aurel
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cross-compile.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20051015/885c319d/attachment.asc>
More information about the MPlayer-dev-eng
mailing list