734050 - Build stlport as part of our build process

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

Rationale being that it would then be compiled with the same flags as our code, and most importantly, as the stlport templates we end up compiling as part of our code.

Comment 1

[Mike Hommey [:glandium]]

Attachment: Build stlport as part of our build process

Comment 2

[Mike Hommey [:glandium]]

Attachment: Build stlport as part of our build process

Comment 3

[Mike Hommey [:glandium]]

Attachment: Build stlport as part of our build process

Comment 4

[Mike Hommey [:glandium]]

Attachment: Build stlport as part of our build process

Comment 5

[(not currently active) Ted Mielczarek]

Comment on attachment 604883 [details] [diff] [review]
Build stlport as part of our build process

Review of attachment 604883 [details] [diff] [review]:
-----------------------------------------------------------------

::: allmakefiles.sh
@@ +76,5 @@
>  if [ ! "$LIBXUL_SDK" ]; then
> +  if [ "$STLPORT_SOURCES" ]; then
> +    add_makefiles "
> +      build/stlport/Makefile
> +      build/stlport/stl/config/_android.h

Using autoconf to generate non-Makefiles always feels like overkill to me, but I don't have an alternate suggestion that doesn't result in you writing a bunch more lines of code.

::: build/stlport/stl/config/_android.h.in
@@ +4,5 @@
> +
> +#ifndef mozilla_stl_config__android_h
> +#define mozilla_stl_config__android_h
> +
> +#include "@STLPORT_SOURCES@/stlport/stl/config/_android.h"

Absolute-path #include seems weird. Can you use #include_next instead, or am I just being too picky?

::: configure.in
@@ +1810,5 @@
>         fi
>         STLPORT_CPPFLAGS="-I$android_ndk/sources/cxx-stl/gnu-libstdc++/include -I$android_ndk/sources/cxx-stl/gnu-libstdc++/libs/$ANDROID_CPU_ARCH/include -D_GLIBCXX_PERMIT_BACKWARD_HASH"
>         STLPORT_LDFLAGS="-L$android_ndk/sources/cxx-stl/gnu-libstdc++/libs/$ANDROID_CPU_ARCH"
>         STLPORT_LIBS="-lstdc++"
>      elif test -e "$android_ndk/sources/cxx-stl/stlport/libs/$ANDROID_CPU_ARCH/libstlport_static.a" ; then

We should probably make this check for the source, since we're not intending to use the static library here.

@@ +1818,2 @@
>         STLPORT_LIBS="-lstlport_static"
>      elif  test -e "$android_ndk/tmp/ndk-digit/build/install/sources/cxx-stl/stlport/libs/$ANDROID_CPU_ARCH/libstlport_static.a" ; then

Do we want to combine this block with the previous? (This is presumably a check for an older NDK version.)

Comment 6

[Mike Hommey [:glandium]]

(In reply to Ted Mielczarek [:ted] from comment #5)
> > +#include "@STLPORT_SOURCES@/stlport/stl/config/_android.h"
> 
> Absolute-path #include seems weird. Can you use #include_next instead, or am
> I just being too picky?

#include_next leads to very noisy warnings on Android, and there's no easy way to get rid of them. In all likeliness, this would also break with --enable-warnings-as-errors.

> >      elif test -e "$android_ndk/sources/cxx-stl/stlport/libs/$ANDROID_CPU_ARCH/libstlport_static.a" ; then
> 
> We should probably make this check for the source, since we're not intending
> to use the static library here.

Fair enough.

> >      elif  test -e "$android_ndk/tmp/ndk-digit/build/install/sources/cxx-stl/stlport/libs/$ANDROID_CPU_ARCH/libstlport_static.a" ; then
> 
> Do we want to combine this block with the previous? (This is presumably a
> check for an older NDK version.)

Note that the oldest NDK i have, which is r5c, has the other layout already. I don't know if building stlport from there would work with these older NDKs, which is basically why I left that as is (that is, to not risk breaking something untested)

Comment 7

[(not currently active) Ted Mielczarek]

Okay. Maybe we should just drop that block and require a non-ancient NDK?

Comment 8

[Mike Hommey [:glandium]]

(In reply to Ted Mielczarek [:ted] from comment #7)
> Okay. Maybe we should just drop that block and require a non-ancient NDK?

How about doing that in a separate bug?

Comment 9

[(not currently active) Ted Mielczarek]

Fine, be that way! :)

Comment 10

[Mike Hommey [:glandium]]

Attachment: Build stlport as part of our build process

With the discussed change for js/src.

Comment 11

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4934f8f21328

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/4934f8f21328

Comment 13

[Joel Maher ( :jmaher ) (UTC -8)]

I am unable to build mozilla-central locally on my ubuntu 11.10 x86_64 machine.  This worked early friday and I narrowed down the configure.in changes to be this as the root cause.  

Are there steps to take to build with this change?

Comment 14

[Mike Hommey [:glandium]]

(In reply to Joel Maher (:jmaher) from comment #13)
> I am unable to build mozilla-central locally on my ubuntu 11.10 x86_64
> machine.  This worked early friday and I narrowed down the configure.in
> changes to be this as the root cause.  
> 
> Are there steps to take to build with this change?

Is it failing to configure like bug 738753 ?

Comment 15

[Joel Maher ( :jmaher ) (UTC -8)]

actually it fails exactly like:
https://bugzilla.mozilla.org/show_bug.cgi?id=720621

Comment 16

[Mike Hommey [:glandium]]

Please file a bug, with your build log, and ndk version.