Build stlport as part of our build process

RESOLVED FIXED in mozilla14

Status

()

Core
Build Config
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: glandium, Assigned: glandium)

Tracking

Trunk
mozilla14
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 4 obsolete attachments)

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.
Assignee: nobody → mh+mozilla
Depends on: 716544
Created attachment 604181 [details] [diff] [review]
Build stlport as part of our build process
Attachment #604181 - Flags: review?(ted.mielczarek)
Created attachment 604881 [details] [diff] [review]
Build stlport as part of our build process
Attachment #604881 - Flags: review?(ted.mielczarek)
Attachment #604181 - Attachment is obsolete: true
Attachment #604181 - Flags: review?(ted.mielczarek)
Created attachment 604882 [details] [diff] [review]
Build stlport as part of our build process
Attachment #604882 - Flags: review?(ted.mielczarek)
Attachment #604881 - Attachment is obsolete: true
Attachment #604881 - Flags: review?(ted.mielczarek)
Created attachment 604883 [details] [diff] [review]
Build stlport as part of our build process
Attachment #604883 - Flags: review?(ted.mielczarek)
Attachment #604882 - Attachment is obsolete: true
Attachment #604882 - Flags: review?(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.)
Attachment #604883 - Flags: review?(ted.mielczarek) → review+
(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)
Okay. Maybe we should just drop that block and require a non-ancient NDK?
(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?
Target Milestone: --- → mozilla13
Version: Trunk → Other Branch
Target Milestone: mozilla13 → ---
Version: Other Branch → Trunk
Fine, be that way! :)
Created attachment 605414 [details] [diff] [review]
Build stlport as part of our build process

With the discussed change for js/src.
Attachment #605414 - Flags: review?(ted.mielczarek)
Attachment #604883 - Attachment is obsolete: true
Attachment #605414 - Flags: review?(ted.mielczarek) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/4934f8f21328
Depends on: 738753
https://hg.mozilla.org/mozilla-central/rev/4934f8f21328
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
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?
(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 ?
actually it fails exactly like:
https://bugzilla.mozilla.org/show_bug.cgi?id=720621
Please file a bug, with your build log, and ndk version.
You need to log in before you can comment on or make changes to this bug.