[MPlayer-dev-eng] [PATCH] cross-compile: add --enable-cross-compile

[Aurelien Jacobs]

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>