On 12/18/15 07:34, Magnus Ihse Bursie wrote:
On 2015-12-17 20:40, Gary Adams wrote:
On 12/17/15 11:09, Magnus Ihse Bursie wrote:
On 2015-12-17 14:19, Gary Adams wrote:
I've revised the original webrev based on some feedback received.
- reverted white space only changes
- proper copyrights on the new files
- some hotspot files contained previously removed code
Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/
Planning to push this first batch tomorrow.
Hi Gary,
There seems to be multiple merge/diff errors in this patch. I'm
seeing several location where this patch contains changes that is
part of other, recently pushed change sets. This makes it hard to
fully understand what changes you are contributing in this patch, to
speak nothing of the merge problems that are likely to arise if this
patch were pushed as it is.
My bad. In getting the workspace to build I had diff'ed the files
against the latest jdk9-dev sources
and pulled in changes that were ahead of the recently cloned
mobile/dev repos.
The next merge will bring in those updates. mobile/dev is cloned from
jdk9-b94 and latest jdk9/dev
is at jdk9-9+b96.
While reverting the code that had newer functionality than it should,
I found the issue that dragged me down the rabbit hole. The change
to use JAVA_JAVAC in the SetupCompilers logic was a thread that
unraveled into more code than I should have touched. I'll double
check on the next resync to make sure everything is OK.
I found several other issues as well. I'm sorry I have not been able
to review this code before. It's a quite massive patch. If you want
to commit the patch as-is in the mobile/dev forest and then fix my
comments later before pushing further to mobile/jdk9, it's ok for
me. I understand that it's tricky to manage a patch of this size.
(But I think it's better to fix issues now, if you ask me...)
I'd like to do any simple cleanups before the initial push. We know
there will be more pushes coming, so I'm not opposed to partial solutions
being put back at this time.
I'll start with something that you and Erik already has discussed:
how to express tests for logic that is common to ios and macosx.
There are places in the patch right now that I'm still not happy with.
First of all, I don't think you need to be shy of testing for macosx
or ios. It's a bit more to write, but it's very clear to the reader,
and code is read more often than written.
I am uncomfortable with all the places platform specific changes need
to be made.
There isn't an easy way to express platform A is like platform B with
the following
differences.
I agree. Platforms are alike and different in very amorphous ways.
We've tried to capture some of this using the concept of "os type"
(that is, to group unix-like operating systems) and "os env" (to
differentiate the unix-emulation layers on windows). It works sort-of,
but it's not perfect. For instance, in some respects macosx is indeed
"unix", but in many other (GUI etc), it's different. We could of
course try to create some kind of category "unix-except-macosx" for
that, but in the end I don't think having
src/java.base/unix-but-not-macosx/ would fly. :-)
So this is a tricky problem, and I believe it can only be "solved" in
terms of getting a "best effort" solution for the platforms and
combinations we currently support. When that support matrix changes
too much (as with mobile), we might have to revise our model. Let's
keep an open discussion on the best way to solve this for mobile. For
now, though, I think the best way is to try and use the current
framework as far as possible. Then we will learn what the actual
limitations are and where they need to be fixed.
OK
Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios.
It's a bit strange, since it changes the meaning of the OS_ENV
(previously it was only used to differentiate between cygwin and
msys in Windows), but I think it could be a reasonable modification.
This means that you can test if OPENJDK_TARGET_OS_ENV == macosx to
cover both the case of macosx and ios. Let's just assume that you
need to know what you're doing when looking at OS_ENV. So this could
be an alternative to a lot of "if target == macosx or target ==
ios", if you don't want to type that everywhere. For android it
seems less of a point of setting OS_ENV. Or do you think you could
unify android/linux code by this?
I thought previously we were told not to use OPENJDK_TARGET_OS_ENV
and I asked at that time for "documentation".
You probably were. :) And it is perhaps best that you don't. :-) In
any way, I don't see any references to the OS_ENV in this code anyway,
so given that, you should remove this.
Removed OS_ENV settings for both andrioid and ios from platform.m4.
What I think you need is, as I understand it, rather to express some
"os kind", that is, saying that android is "a kind of" linux and ios
is "a kind of" macosx, so that at times android behaves as linux, but
at times it behaves differently, etc. I thought maybe OS_ENV could use
that role, but perhaps it's best not to mess around with it.
Third, I'm not really fond of the TOOLCHAIN_NAME variable. The
concept is fine, but the variable name is not (I know you didn't
invent this). We have a TOOLCHAIN_DESCRIPTION and a TOOLCHAIN_NAME
sounds like just a variant of that. Perhaps resusing the fluffy and
unspecified ENV and call it TOOLCHAIN_ENV instead? I thought of
TOOLCHAIN_VENDOR, but then again I'd assume that it'd be "apple",
and I think we gain clarity by calling Xcode "xcode" and not "apple".
I'd be glad to use a different name or value for the flag, just let
me know.
This is a change we could defer til the mobile/dev to mobile/jdk9
integration.
At this time I'm mostly interested to know that we've used it in the
right places.
e.g. prior to discovery of boot-jdk and xcode we used BUILD_OS
macosx, after
that we use toolchain xcode check, for native flags and libraries we
still check TARGET_OS
for macosx or ios when not xcode specific.
Fair enough. Use TOOLCHAIN_NAME for now, and we'll make a
search/replace for it later on if we agree on a better name. I think
your usage of the xcode check was good, except where I noted otherwise
in my review.
So, to the specifics:
basics.m4: It's not really true that this is build os rather than
target os. In fact, the whole block is a mix of target and build
dependent stuff. For instance, xattr depends on build platform but
dsymutil depends on target os. I suggest you change to target ==
macosx || ios.
Will do.
boot-jdk.m4: At the end looks like merge error.
Will fix.
We had the big java fix in ejdk8u and it recently cam back in jdk9
recent builds.
flags.m4: Why delete CPPFLAGS for SYSROOTS?
SYSROOT does not belong on CPPFLAGS.
We needed the fix for the ios builds.
Hm...
First of all, I'm not even sure where we're using CPPFLAGS. It's
probably in a few special cases. Do you remember where you got
problems with the CPPFLAGS and sysroot? But even the preprocessor
needs to know the path to the system header files to be able to
function correctly, yes? So I still can't really see why this should
be deleted.
Are you using it to create build tools, i.e. tools that should run
during the build process on the build platform when cross compiling?
If so, you probably need a BUILD_CPP, which we might be lacking at the
moment.
The original configure processing validates the flag settings.
If CPP flags include the target platform sysroot there are errors
in the compile and execute tests. It's not set up well for cross
compilation checks. In the early stages it just wants to ensure
it has a command that accepts flags. e.g. build cc and ld
I think that if you set only LEGACY_EXTRA_CFLAGS and not
EXTRA_CFLAGS, you will only pass this to Hotspot and not the jdk
libraries. But honestly, the flag handling is mysterious even to me
so I can't say for sure. But you might want to double-check this.
Not sure about this comment. We have working ios and android builds
from the flags
that are currently being set. Several fingers over several years have
touched these
files, so the original intent may not be clear.
If it works for you I'm happy. :-) I'm just a bit surprised that it
does. But it also goes to show that we desperately need to rework the
flag handling, it's grown almost impossible to comprehend.
:-)
BUILD_CC check looks like merge error.
Will fix.
lib-bundled.m4:
Out choice to use system zlib has nothing to do with xcode. It's a
target os decision.
Will fix.
lib-freetype.m4: OTOH, I'd say that this is indeed a build-os
decision :-)
Will fix.
lib-std.m4: This test is only valid for gcc. We are currently not
using gcc, only clang, for macosx builds. Are you really using gcc
for ios builds? Otherwise, just leave it as it is.
Only changed it because it was flagged as
should be changed if we switched from xcode clang to
gcc based toolchain in the future.
Will revert/fix.
spec.gmk.in:
Looks like mostly (only?) merge problems here. Or have you added
something?
Will roll back the sjava related changes, but keep
the ":=" fix on mac osx version.
Aha, there were your change. I missed it.
toolchain.m4: See discussion above on TOOLCHAIN_NAME. It looks like
there are lot of merge errors here.
Will recheck.
CompileJavaModules.gmk: Merge errrors galore. I can't really tell
what are your changes in here.
Will fix
Images.gmk: Care to elaborate? I don't understand anything.
ios builds do not build any command line executables.
It is the wrong target to build a dependency when the jlmage is
the result of the recipe.
# Use this file inside the image as target for make rule
-JIMAGE_TARGET_FILE := bin/java$(EXE_SUFFIX)
+JIMAGE_TARGET_FILE := lib/modules/bootmodules.jimage
Right! *duh* I didn't read the comment above, I just noted that you
did a non-platform specific change and reacted to that. In fact,
checking for the jimage almost seems more natural even if it weren't
for your requirements. :)
Main.gmk, JavaCompilation.gmk, Modules.gmk: Merge errors. What is
your changes in these files? I can't review this.
MakeBase.gmk: just wanted to let you know that I approve of the
change to build os. :-) I'd appreciate if you could fix the
whitespace mistake as well (space after the comma is missing).
Fixed.
(Sure would be nice if there was tool to do the makefile whitespace
checking.)
Indeed it would be. If you know of one, let me know. :-)
On a slightly more serious note: I've done some research on code
formatting tools for makefiles, but that's more or less non-existent.
I think it's a combination of having a small target audience and an
archaic and difficult syntax. So we've realized that we need to be
vigilant and learn to fix the whitespace ourself manually, to keep the
files from creeping back into an unreadable mess.
The best tool I've found so far is the flymake-mode in emacs.
One of the difficulties debugging with the current recipe generation
approach
in the makefiles, is you never have a "final form makefile" that you can
examine
for debugging purposes. I had a number of "makefile syntax errors -
missing separator"
that I tried to track down looking for a recipe missing tabs (typical
error case), but
was actually a missing double-dollar in the two level Setup recipe
processing.
If we had a "show me the makefile you think you are processing", it
might have been
a quicker identification of the premature comma expansion error.
SetupJavaCompilers.gmk: merge errors? For the
GENERATE_JAVA5_BYTECODE, please use space after comma. (I know we
didn't do that everywhere originally, but new code should adhere to
the styleguide.)
Fixed.
I assume it's OK to fix the other missing space-after-comma.
Yes.
jdk/make/CompileDemos.gmk: Merge erros. The new android ifdef should
have proper whitespace (space after comma, the if block indented two
spaces).
Fixed.
jdk/make/Import.gmk: Looks like the block after the two ifneq
($(OPENJDK_TARGET_OS), ios) has not been indented. (Or is it a
problem with the webrev?) Also, the android ifdef is weirdly
indented, looks like you tried to cram it in with just a single
space indent.
Fixed.
jdk/make/gensrc/GensrcCharsetMapping.gmk,
jdk/make/gensrc/Gensrc-jdk.jdi.gmk,
jdk/make/gendata/Gendata-java.base.gmk: indentation in if blocks is
missing.
Fixed.
jdk/make/launcher/Launcher-java.base.gmk and other launcher make
files: I thought you and Erik agreed to remove this?
The addition of new configure options will be handled in subsequent
pushes.
This is one of the places where new features need to be developed
to be ready for a mobile/jdk9 push, but should not block getting
basic ios
functionality into the open repos.
Ok.
jdk/make/lib/CoreLibraries.gmk: Why remove ARFLAGS? On macosx, we
put the -framework options in LIBS rather than LDFLAGS (the latter
is only used to change the behavior of the linker, not determine
what to link with.)
We ran into conflicts with the use of ARFLAGS and AR_OUTPUT_OPTION
in NativeCompilation.gmk.
It does not appear that both could be set and build properly.
# Generating a static library, ie object file archive.
$$($1_TARGET): $$($1_EXPECTED_OBJS) $$($1_RES) $$($1_VARDEPS_FILE)
$(ECHO) $(LOG_INFO) "Archiving $$($1_STATIC_LIBRARY)"
$(call LogFailures, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_link.log,
$$($1_SAFE_NAME)_link, \
$$($1_AR) $$($1_ARFLAGS) $(AR_OUT_OPTION)$$($1_TARGET)
$$($1_EXPECTED_OBJS) \
$$($1_RES))
There are also ARFLAGS references in hotspot/bsd/makefiles that may
need unification
when the hotspot new build is set up.
I see. We have not exercised the static library builds that much. Our
code certainly looks suspect. I see that on macosx we have ARFLAGS:=-r
and AR_OUT_OPTION "rcs ". That doesn't seem right. In fact, even for
all unix platforms, the "rcs" is more reasonably thought of as flags
than an output option. The ar command does not need an option to
specify the output file (unlike on windows).
But I still don't understand your change. You are deleting it for the
case of NOT building on macosx. This means that e.g. linux and windows
builds will not get ARFLAGS, and this is a regression for those
platforms. I can only assume you did this to handle the ios case. If
so, I suggest the quick fix is to set ARFLAGS to "" for ios in
flags.m4, and then we'll have to clean up this logic properly instead.
Here's the fullset of ARFLAGS and AR_OUT_OPTION references
make/common/NativeCompilation.gmk:279:# ARFLAGS the archiver flags to
be used
make/common/NativeCompilation.gmk:758: $1_VARDEPS := $$($1_AR)
$$($1_ARFLAGS) $$($1_LIBS) \
make/common/NativeCompilation.gmk:767: $$($1_AR) $$($1_ARFLAGS)
$(AR_OUT_OPTION)$$($1_TARGET) $$($1_EXPECTED_OBJS) \
The creations of the static library is using the passed in ARFLAGS and
the global AR_OUT_OPTION.
common/autoconf/flags.m4:133: ARFLAGS="-r"
common/autoconf/flags.m4:135: ARFLAGS="-X64"
common/autoconf/flags.m4:138: ARFLAGS="-nologo -NODEFAULTLIB:MSVCRT"
common/autoconf/flags.m4:140: ARFLAGS=""
common/autoconf/flags.m4:142: AC_SUBST(ARFLAGS)
common/autoconf/flags.m4:164: AR_OUT_OPTION=-out:
common/autoconf/flags.m4:174: AR_OUT_OPTION='rcs$(SPACE)'
common/autoconf/flags.m4:179: AC_SUBST(AR_OUT_OPTION)
Platform specific flags are designated for ARFLAGS macosx, aix, windows
AR_OUTPUT is set for microsoft and non-microsoft.
I can change the ARFLAGS for macosx and ios to "" in flags.m4
or could define AR_OUT_OPTION to "" for macosx and ios ....
common/autoconf/spec.gmk.in:308:AR_OUT_OPTION:=@AR_OUT_OPTION@
common/autoconf/spec.gmk.in:394:ARFLAGS:=@ARFLAGS@
jdk/make/lib/CoreLibraries.gmk:52: ARFLAGS := $(ARFLAGS), \
jdk/make/lib/CoreLibraries.gmk:408: ARFLAGS := $(ARFLAGS), \
jdk/make/lib/CoreLibraries.gmk:450: ARFLAGS := $(ARFLAGS), \
These are the requests for static library builds of libfdlibm and a
static libjli (aix)
Restore the places that were passing ARFLAGS into NativeCompilation ...
hotspot/make/bsd/makefiles/jsig.make:67: $(QUIETLY) $(AR) $(ARFLAGS)
$@ $(JSIG).o
hotspot/make/bsd/makefiles/rules.make:43:LINK_LIB.CC = $(AR) $(ARFLAGS)
And change the hotspot uses of ARFLAGS to add AR_OUT_OPTION.
Currently we only support full static builds on macosx and ios.
jdk/make/lib/Awt2dLibraries.gmk: LIBAWT_EXFILES += initIDs.c
awt/image/cvutils/img_colors.c should not depend on build os. That's
a target os decision. The same goes for the LIBSPLASHSCREEN_DIRS
changes. Also, the whole file seems to be excluded on ios so why
these changes at all? (And, if that ifdef really is correct, you
need to indent the whole file as well.) And the same goes for
-framework into LIBS not LDFLAGS (but only if it's really used on ios).
Unfortunately our android developer retired, so I'm not totally up to
date on the selective files being excluded.
I'm assuming they did not compile on the target platform and were
simply excluded. The mobile platforms
are intend as headless compact2 only. I'm pretty sure the whole file
ios exclusion was done after some
number of attempts to get the library to compile.
The android changes looks fine to me.
However, if the long term goal is to actually skip this for ios, then
the only change that is needed is the global if target-os != ios, and
all other ios/macosx changes could be reverted.
I'll save this change for the cleanup when new switches are available.
Is java.desktop not included in the compact2 profile? And the problem
here is that even when building a subset of the modules, we still
start by compiling all modules, so you need it not to break during
compilation. Arrghh... I think we need to speed up getting a solution
were we only compile what's actually needed, so you don't have to mess
around with code that's not being used.
Yes, please.
I would like to build for java.compact2 and have only the required
modules and dependent libraries built.
This is a another place we expect to fix later with a proper working
of headless builds.
I'll fix the LIBS reference to framework before the initial push.
jdk/make/lib/Lib-java.base.gmk: I'm not sure what's happening here.
Can you elaborate?
On ios there is no libjli. The app container is not allowed to
fork/exec new processes.
That is why a separate JavaLauncher interface is provided to ease the
startup of a VM in the current process.
The other logic in the selection of symbol file to use is based on
the VM actually
being built. e.g. minimal, client, server vm. The static macosx build
only supported
server vm. We deplot mobile with minimal vm, but still maintain
client vm for testing purposes.
And the chained "else ifeq" is since you assume that you only have a
single variant, but you still want to put the symbols file in the
corresponding directory name? If it's a requirement to build only with
a single variant when doing static builds, maybe we should enforce
that in configure? Otherwise this code will break if someone builds
with --with-jvm-variants=server,client.
Multiple variants are OK.
If there are differences in the exported vm symbol lists,
it will select the smaller vm symbol set for the jdk compiled launchers.
Specifying an exported symbols list for scode clang has two effects.
First it ensures object files are pulled in from the static library and
second
promotes the visibility of those symbols so they are visible to dlsym
lookups from the current executable. This allows for very minimal changes
in the runtime code between static and shared libraries being used.
For ios the deliverable is the static library and associated symbol list.
The end user decides what is include or excluded from their executable.
e.g only one vm could be included in a staticly linked application.
jdk/make/lib/Lib-java.prefs.gmk,
jdk/make/lib/Lib-java.instrument.gmk: indentation seems wrong, it
should be two spaces.
Fixed.
jdk/make/lib/Lib-jdk.jdwp.agent.gmk: Why the LIBDIR stuff?
There is still a remnant of arch specific directories in the build
system.
Here's the relevant setting from platform.m4
# This is the name of the cpu (but using i386 and amd64 instead of
# x86 and x86_64, respectively), preceeded by a /, to be used when
# locating libraries. On macosx, it's empty, though.
OPENJDK_TARGET_CPU_LIBDIR="/$OPENJDK_TARGET_CPU_LEGACY_LIB"
if test "x$OPENJDK_TARGET_OS" = xmacosx; then
OPENJDK_TARGET_CPU_LIBDIR=""
fi
AC_SUBST(OPENJDK_TARGET_CPU_LIBDIR)
I see. So the static build worked by chance on macosx but not on
android. Argh. There is a bug JDK-8066474 on removing this arch dir,
we really should get that fixed.
We found the problem initially in the ios build.
It will be obvious when we need to update the mobile repos when the
OPENJDK_TARGET_CPU_LEGACY_LIB variable is removed.
Ideally, the build system would allow us to cross compile
multiple targets in a single pass.
macosx build system
ios-x86
ios-x86_64
ios-arm
ios-aarch64
then roll up universal static libraries with lipo.
Since we do not have that capability we build 4 separate bundles
and our users are combining 4 platform bundles and rolling their own
universal libraries.
I think we are going to need a continuing discussion on how to solve
these needs in the best way.
OK
jdk/make/lib/Lib-jdk.management.gmk, jdk/make/lib/Lib-jdk.sctp.gmk:
Indentation, indentation...
Fixed.
(Wish there was a tool that could fix the whitespace.)
jdk/make/lib/LibCommon.gmk: Why the strange order in the android case?
I read the android diff to mean use the "linux" native code when
TARGET_OS is android.
You are right. I think my eyes got a bit tired after reading through
all that code.
Hm. Let's do it this way for now, but we should really rethink how to
express that android is like linux only different.
OK
+ifeq ($(OPENJDK_TARGET_OS), android)
+FindSrcDirsForLib = \
+ $(call uniq, $(wildcard \
+ $(JDK_TOPDIR)/src/$(strip $1)/*linux*/native/lib$(strip $2) \
+ $(JDK_TOPDIR)/src/$(strip
$1)/$(OPENJDK_TARGET_OS_TYPE)/native/lib$(strip $2) \
+ $(JDK_TOPDIR)/src/$(strip $1)/share/native/lib$(strip $2)))
...
+else
+FindSrcDirsForLib = \
+ $(call uniq, $(wildcard \
+ $(JDK_TOPDIR)/src/$(strip $1)/$*(OPENJDK_TARGET_OS)*/native/lib$(strip
$2) \
+ $(JDK_TOPDIR)/src/$(strip
$1)/$(OPENJDK_TARGET_OS_TYPE)/native/lib$(strip $2) \
+ $(JDK_TOPDIR)/src/$(strip $1)/share/native/lib$(strip $2)))
+endif
Will fix the indents there.
jdk/make/lib/SoundLibraries.gmk: indentation (last if block, the
rest looks fine)
Fixed.
jdk/src/java.base/share/tools/jproject/ios/frameworks/*...: I'm not
sure this is the correct location. We've never had a "share/tools"
directory before in a module. They are needed to building the
JavaLauncher static library on ios, right? I think they should
reside with the source code, then, in
jdk/src/java.base/ios/native/JavaLauncher. (but see below about the
name).
Will fix. We just recently stopped using xcodebuild to create a
proper framework.
jdk/src/java.base/ios/native/JavaLauncher: Directories should only
use lower case. Normally, we prefix libraries with "lib" in the
native directory, directories without "lib" are supposed to be
programs. Now this is a static library and we haven't had many of
these before, but libjli is static (or can be) and still have the
lib prefix, so I'd argue that thisshould be
jdk/src/java.base/ios/native/libjavalauncher instead.
Not just a library.
Our deliverable artifact is a framework on ios.
The include file and static library are packaged so they can drop
into an Xcode project and all the proper connections are made.
This is the native component that will launch the VM in the current
process.
But the native code compiles to a library. In SetupNativeCompilation,
you have:
OUTPUT_DIR := $(SUPPORT_OUTPUTDIR)/native/java.base/libjavalauncher, \
The idea is that the name here should match the source code directory.
We're working on getting the setup macros to get this connection
automatically, so you only would have to specifify something along the
lines of:
SetupNativeLibrary(libjavalauncher,
CFLAGS := ...)
and it will automatically infer where to find the source code and
where to store the output. All other libraries adhere to this
standard, so please don't break this for us.
I'm looking a bit more closely now at the newly added files here.
I think you are making this more complicated than what's needed. Drop
the libocldvk and share/javalauncher_api. Instead, call all of it
libjavalauncher. Then when we finish the automatic setup the android
launcher will pick up the shared api and the ios launcher will pick up
the shared api, and the platform specific files, all by themselves.
The native compilation setup in JavaLauncher.gmk is also overly
complicated. SRC points to the base source dir. You don't have to
explicitly name the files. You don't have to include both $(OCLDVK)
and $(OCLDVK)/net, the top dir is enough.
I'm going to save the JavaLauncher cleanup to a subsequent push.
There are some additional code coming before we have the full android
platform supported
in the mobile/dev repos.
make/lib/JavaLauncher.gmk: For consistency (and to clarify that this
is libraries, not launchers), it should be named
JavaLauncherLibraries.gmk. The android part creates a jar. This
should not be done in the native phase, but in the Java phase.
OCLDVK_OUTPUTDIR is defined but not used. It's a bit sad to commit
new code with WARNINGS_AS_ERRORS_clang := false. :-( Can't you fix
the warnings instead?
Even though we compile a Java 5 byte code jar file, it will be
processed via dex before it is actually linked into an android
executable.
This is something that's still missing, right?
While it is possible to run the java command from an adb shell on an
android device,
the real target of the mobile project on android is the encapsulated
application.
That build procedure is outside the scope of a jdk build.
We will be providing a sample HelloWorld project on each of the target
platforms that can drop in a "jre" and perform the final application build
step with the native toolchain.
Note: that a static build only requires symbol files and static
libraries at
application build time and will not be copied to a deployed application
runtime image.
In a similar manner the dalvik jar file will be consumed/transformed in the
application build process.
This is the native side that will launch a Java VM within the current
process.
We called in JavaLauncher because it was a replacement for libjli.
I'll investigate the unused OCLDVK_OUTPUTDIR and the WARNINGS_AS_ERRORS.
There is probably some shared linux code that does not compile
cleanly with the android toolchain.
The WARNINGS_AS_ERRORS is on the ios side. It only compiles three
newly added files.
I will follow up on the warnings at a later time.
---
This was what I could find right now. I have not looked at hotspot
build changes, nor any source code changes.
Thanks I appreciate all these comments.
Thanks. I apologize once more for coming with so much feedback after
so long time.
My hope is that we will have much smaller reviewable changesets
going forward.
Let's hope. :-)
/Magnus
/Magnus
