GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

Most of the porting involves files inside /base. 

This also fixes build/build_config.h not identifying PPC architectures correctly. Finally, it adds aix support to files inside tools/gn/, including the bootstrap script.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
Review-Url: https://codereview.chromium.org/2807463004
Cr-Commit-Position: refs/heads/master@{#467484}
Committed: https://chromium.googlesource.com/chromium/src/+/0088ee5017f4bef6c27243a54d8998f993db11b8

[rayb, 2017-04-11 23:24:04]

Description was changed from

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

work in progress

BUG=706728
==========

to

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

BUG=706728
==========

[rayb, 2017-04-12 17:09:32]

Description was changed from

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

BUG=706728
==========

to

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

R=machenbach@chromium.org, dpranke@chromium.org, agrieve@chromium.org
BUG=706728
==========

[rayb, 2017-04-12 17:15:09]

Description was changed from

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

R=machenbach@chromium.org, dpranke@chromium.org, agrieve@chromium.org
BUG=706728
==========

to

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

[rayb, 2017-04-12 17:21:02]

rayb@ca.ibm.com changed reviewers:
+ adamk@chromium.org, dpranke@chromium.org, machenbach@chromium.org

[rayb, 2017-04-12 17:21:03]

ptal

[Primiano Tucci (use gerrit), 2017-04-13 09:59:14]

primiano@chromium.org changed reviewers:
+ primiano@chromium.org

[Primiano Tucci (use gerrit), 2017-04-13 09:59:15]

https://codereview.chromium.org/2807463004/diff/80001/base/allocator/allocato...
File base/allocator/allocator_shim_default_dispatch_to_glibc.cc (right):

https://codereview.chromium.org/2807463004/diff/80001/base/allocator/allocato...
base/allocator/allocator_shim_default_dispatch_to_glibc.cc:32: return
malloc(size);
this is just going to cause loops in the malloc code.
I think you just want to set
use_experimental_allocator_shim = false
in your builds

this will avoid this entire logic to kick in, without having to change these
files.

[Dirk Pranke, 2017-04-14 01:19:33]

Please add more text to the CL description to describe *what* is being ported
(i.e., //base and //tools/gn ...).

the //tools/gn changes lgtm w/ the comments addressed. I defer to the others for
the //base changes.

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc#newcod...
tools/gn/args.cc:337: // We handle the endianess inside
build/config/BUILDCONFIG.gn.
s/endianess/endianness

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc#newcod...
tools/gn/args.cc:339: // and specifc flags are included using the host_byteorder
logic.
s/specifc/specific

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/bootstrap/boot...
File tools/gn/bootstrap/bootstrap.py (right):

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/bootstrap/boot...
tools/gn/bootstrap/bootstrap.py:329: # optimization level is set to 2 (0 works
fine).
This comment confuses me. If this is true, doesn't this mean that there should
be a check for ppc64 BE here somewhere?

[Michael Achenbach, 2017-04-18 14:07:16]

I'm no owner of any of these files. Moving myself to CC.

[Michael Achenbach, 2017-04-18 14:07:45]

machenbach@chromium.org changed reviewers:
- machenbach@chromium.org

[rayb, 2017-04-19 19:49:27]

On 2017/04/13 09:59:15, Primiano Tucci wrote:
>
https://codereview.chromium.org/2807463004/diff/80001/base/allocator/allocato...
> File base/allocator/allocator_shim_default_dispatch_to_glibc.cc (right):
> 
>
https://codereview.chromium.org/2807463004/diff/80001/base/allocator/allocato...
> base/allocator/allocator_shim_default_dispatch_to_glibc.cc:32: return
> malloc(size);
> this is just going to cause loops in the malloc code.
> I think you just want to set
> use_experimental_allocator_shim = false
> in your builds
> 
> this will avoid this entire logic to kick in, without having to change these
> files.

I made changes to the bootstrap script so that the allocator_shim never gets
used on aix. And while we are on that topic setting
use_experimental_allocator_shim = false, we still need to make changes to mostly
the BUILD.gn files to build GN using a GN binary on the aforementioned
platforms. I think it's best we do that in a seperate cl after these changes for
though. Let me know what you think.

[rayb, 2017-04-19 19:51:50]

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc#newcod...
tools/gn/args.cc:337: // We handle the endianess inside
build/config/BUILDCONFIG.gn.
On 2017/04/14 01:19:33, Dirk Pranke wrote:
> s/endianess/endianness

Acknowledged.

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc#newcod...
tools/gn/args.cc:339: // and specifc flags are included using the host_byteorder
logic.
On 2017/04/14 01:19:33, Dirk Pranke wrote:
> s/specifc/specific

Acknowledged.

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/bootstrap/boot...
File tools/gn/bootstrap/bootstrap.py (right):

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/bootstrap/boot...
tools/gn/bootstrap/bootstrap.py:329: # optimization level is set to 2 (0 works
fine).
On 2017/04/14 01:19:33, Dirk Pranke wrote:
> This comment confuses me. If this is true, doesn't this mean that there should
> be a check for ppc64 BE here somewhere?

The current bootstrap script has no way of detecting host architecture. We could
add that logic (not sure if it's worth). This wouldn't be an issue once we start
building GN with a GN binary on the aforementioned platforms(because then this
can be just handled inside build/config/toolchain/). Where we would just be
using the debug binary on ppc64 BE for the first iteration and after that
everything else should be straight forward (once we make the required changes to
build/).
And while we are on that topic, I think the changes required for building GN
using a GN binary should probably go on a separate cl(once these changes go
through).
Also I should probably elaborate a little what I meant by "does not work" for
ppc64 BE. With optimization level at anything greater than 0, we still get a GN
binary. But when running it to build something like v8, the generated .ninja
files would have entries where the right hand side of the assignment would be
missing (of course ninja fails when it comes to using those .ninja files to
build v8). 
So for example 'defines' would look something like "defines = " instead of
"defines = -DV8_DEPRECATION_WARNINGS ..". But things such as 'label_name' or the
required source file entries would come out just fine. Note that that once
optimization level is set to '0', it works completely fine. From my
understanding both the builds follow the exact same code path.

[rayb, 2017-04-19 20:17:09]

ptal

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc#newcod...
tools/gn/args.cc:337: // We handle the endianess inside
build/config/BUILDCONFIG.gn.
On 2017/04/14 01:19:33, Dirk Pranke wrote:
> s/endianess/endianness

Done.

https://codereview.chromium.org/2807463004/diff/80001/tools/gn/args.cc#newcod...
tools/gn/args.cc:339: // and specifc flags are included using the host_byteorder
logic.
On 2017/04/14 01:19:33, Dirk Pranke wrote:
> s/specifc/specific

Done.

[rayb, 2017-04-19 20:46:42]

Description was changed from

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

to

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

The changes mostly span across files inside build/. Also  	build/build_config.h
is changed in order to identify ppc architectures properly. Also adding support
for aix in tools/gn/bootstrap/.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

[rayb, 2017-04-19 20:47:00]

Description was changed from

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

The changes mostly span across files inside build/. Also  	build/build_config.h
is changed in order to identify ppc architectures properly. Also adding support
for aix in tools/gn/bootstrap/.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

to

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

The changes mostly span across files inside build/. Also build/build_config.h is
changed in order to identify ppc architectures properly. Also adding support for
aix in tools/gn/bootstrap/.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

[rayb, 2017-04-19 23:01:00]

Description was changed from

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

The changes mostly span across files inside build/. Also build/build_config.h is
changed in order to identify ppc architectures properly. Also adding support for
aix in tools/gn/bootstrap/.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

to

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

Most of the porting involves files inside /base. 

This also fixes build/build_config.h not identifying PPC architectures
correctly. Finally, it adds aix support to files inside tools/gn/, including the
bootstrap script.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

[Dirk Pranke, 2017-04-19 23:19:30]

https://codereview.chromium.org/2807463004/diff/100001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/100001/tools/gn/args.cc#newco...
tools/gn/args.cc:337: // We handle the endianness inside
build/config/BUILDCONFIG.gn.
per the discussion on the other CL, we probably need to update the path here.

[rayb, 2017-04-25 00:36:36]

ptal.

Also updated the other three related cls -

https://codereview.chromium.org/2809963004/ 
https://codereview.chromium.org/2807463004/
https://codereview.chromium.org/2812173002/

https://codereview.chromium.org/2807463004/diff/100001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/100001/tools/gn/args.cc#newco...
tools/gn/args.cc:337: // We handle the endianness inside
build/config/BUILDCONFIG.gn.
On 2017/04/19 23:19:30, Dirk Pranke wrote:
> per the discussion on the other CL, we probably need to update the path here.

Done.

[rayb, 2017-04-25 17:42:19]

The CQ bit was checked by rayb@ca.ibm.com

[rayb, 2017-04-25 17:42:20]

The patchset sent to the CQ was uploaded after l-g-t-m from dpranke@chromium.org
Link to the patchset: https://codereview.chromium.org/2807463004/#ps120001
(title: "rebased, cleaned up the code, addressed comments")

[commit-bot: I haz the power, 2017-04-25 17:42:47]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[rayb, 2017-04-25 17:44:08]

The CQ bit was unchecked by rayb@ca.ibm.com

[rayb, 2017-04-25 17:51:53]

rayb@ca.ibm.com changed reviewers:
+ danakj@chromium.org, thakis@chromium.org

[rayb, 2017-04-25 17:51:54]

ptal

[rayb, 2017-04-25 18:05:48]

The CQ bit was checked by rayb@ca.ibm.com to run a CQ dry run

[rayb, 2017-04-25 18:05:56]

The CQ bit was unchecked by rayb@ca.ibm.com

[rayb, 2017-04-25 18:34:34]

The CQ bit was checked by rayb@ca.ibm.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-25 18:35:20]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-25 18:40:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-25 18:40:35]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Nico, 2017-04-25 18:44:11]

On 2017/04/25 17:51:54, Ray Banerjee wrote:
> ptal

When adding reviewers, please teach each reviewer what specifically you want
them to look at.

[Nico, 2017-04-25 18:50:40]

https://codereview.chromium.org/2807463004/diff/120001/base/memory/shared_mem...
File base/memory/shared_memory_posix.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/memory/shared_mem...
base/memory/shared_memory_posix.cc:164: // AIX has no 64-bit support for open
falgs such as -
typo falgs

https://codereview.chromium.org/2807463004/diff/120001/base/process/internal_...
File base/process/internal_linux.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/process/internal_...
base/process/internal_linux.cc:22: // Not defined on AIX by default.
You build _linux files on aix?

https://codereview.chromium.org/2807463004/diff/120001/base/time/time_posix.cc
File base/time/time_posix.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/time/time_posix.c...
base/time/time_posix.cc:67: // we should perhaps use a more portable alternative
Use sentence case for comments. Remove second line.

https://codereview.chromium.org/2807463004/diff/120001/base/trace_event/proce...
File base/trace_event/process_memory_dump.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/trace_event/proce...
base/trace_event/process_memory_dump.cc:126:
reinterpret_cast<char*>(vec.get()));
vec is a unique_ptr<char[]>, why do you need to reinterpret_cast it to char*?

https://codereview.chromium.org/2807463004/diff/120001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/tools/gn/args.cc#newco...
tools/gn/args.cc:337: // We handle the endianness inside
//build/config/host_byteorder.gni.
I don't see a host_byteorder.gni. I don't think we want to support
non-little-endian systems.

[Dirk Pranke, 2017-04-25 18:53:37]

https://codereview.chromium.org/2807463004/diff/120001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/tools/gn/args.cc#newco...
tools/gn/args.cc:337: // We handle the endianness inside
//build/config/host_byteorder.gni.
On 2017/04/25 18:50:40, Nico wrote:
> I don't see a host_byteorder.gni. I don't think we want to support
> non-little-endian systems.

See https://codereview.chromium.org/2815453004/ where it is added. I have no
objection to adding support for big-endian systems to GN, there's little
overhead for it. I won't take a stand on whether you want to support it for
non-node-needed parts of chromium.

[rayb, 2017-04-25 22:40:17]

https://codereview.chromium.org/2807463004/diff/120001/base/memory/shared_mem...
File base/memory/shared_memory_posix.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/memory/shared_mem...
base/memory/shared_memory_posix.cc:164: // AIX has no 64-bit support for open
falgs such as -
On 2017/04/25 18:50:40, Nico wrote:
> typo falgs

Fixed it.

https://codereview.chromium.org/2807463004/diff/120001/base/process/internal_...
File base/process/internal_linux.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/process/internal_...
base/process/internal_linux.cc:22: // Not defined on AIX by default.
On 2017/04/25 18:50:40, Nico wrote:
> You build _linux files on aix?

Yeah. To be exact 8 of them. Mostly related to process handling and one in
threading. The extra bit of code required to make them work for AIX is pretty
small. Or at least small enough that they can just be guarded with the OS_AIX
macro (similar in size to the code guarded by the OS_CHROMEOS macros).

In the future, if the code paths for Linux and AIX diverge to an extent where
this just looks silly, then we can just add new files. Does that sound
reasonable?

https://codereview.chromium.org/2807463004/diff/120001/base/time/time_posix.cc
File base/time/time_posix.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/time/time_posix.c...
base/time/time_posix.cc:67: // we should perhaps use a more portable alternative
On 2017/04/25 18:50:40, Nico wrote:
> Use sentence case for comments. Remove second line.

That was just a leftover comment. Sorry about that. Fixed now.

https://codereview.chromium.org/2807463004/diff/120001/base/trace_event/proce...
File base/trace_event/process_memory_dump.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/base/trace_event/proce...
base/trace_event/process_memory_dump.cc:126:
reinterpret_cast<char*>(vec.get()));
On 2017/04/25 18:50:40, Nico wrote:
> vec is a unique_ptr<char[]>, why do you need to reinterpret_cast it to char*?

On AIX mincore is defined as the following inside sys/mman.h -

extern int mincore(char *, size_t, char *);

Whereas on Linux it's defined as -

extern int mincore (void *__start, size_t __len, unsigned char *__vec).

So without the reinterpret_cast, it generates a compiler error(invalid
conversion from 'std::unique_ptr<unsigned char []>::pointer {aka unsigned
char*}' to 'char*').

https://codereview.chromium.org/2807463004/diff/120001/tools/gn/args.cc
File tools/gn/args.cc (right):

https://codereview.chromium.org/2807463004/diff/120001/tools/gn/args.cc#newco...
tools/gn/args.cc:337: // We handle the endianness inside
//build/config/host_byteorder.gni.
On 2017/04/25 18:53:37, Dirk Pranke wrote:
> On 2017/04/25 18:50:40, Nico wrote:
> > I don't see a host_byteorder.gni. I don't think we want to support
> > non-little-endian systems.
> 
> See https://codereview.chromium.org/2815453004/ where it is added. I have no
> objection to adding support for big-endian systems to GN, there's little
> overhead for it. I won't take a stand on whether you want to support it for
> non-node-needed parts of chromium.

Acknowledged.

[rayb, 2017-04-25 22:42:48]

On 2017/04/25 18:44:11, Nico wrote:
> On 2017/04/25 17:51:54, Ray Banerjee wrote:
> > ptal
> 
> When adding reviewers, please teach each reviewer what specifically you want
> them to look at.

Specifically the changes in //base, as the ones in //tools/gn have been lgtm-ed
w/ comments by Dirk Pranke.

[Nico, 2017-04-25 22:43:11]

lgtm

[rayb, 2017-04-26 15:58:38]

The CQ bit was checked by rayb@ca.ibm.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-26 15:59:16]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-26 16:04:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-26 16:04:54]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[rayb, 2017-04-26 18:22:06]

The CQ bit was checked by rayb@ca.ibm.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-26 18:22:40]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-26 20:57:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-26 20:57:57]

Dry run: This issue passed the CQ dry run.

[rayb, 2017-04-26 22:22:26]

The CQ bit was checked by rayb@ca.ibm.com

[rayb, 2017-04-26 22:22:27]

The patchset sent to the CQ was uploaded after l-g-t-m from
dpranke@chromium.org, thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/2807463004/#ps160001
(title: "removed the changes from //base/BUILD.gn")

[commit-bot: I haz the power, 2017-04-26 22:23:19]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-26 22:35:11]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1493245346501430,
"parent_rev": "45270092658ba5f874078283b2fc43a2e07ad3b4", "commit_rev":
"0088ee5017f4bef6c27243a54d8998f993db11b8"}

[commit-bot: I haz the power, 2017-04-26 22:35:19]

Description was changed from

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

Most of the porting involves files inside /base. 

This also fixes build/build_config.h not identifying PPC architectures
correctly. Finally, it adds aix support to files inside tools/gn/, including the
bootstrap script.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728
==========

to

==========
GN: aix port along with linux_s390x, linux_ppc64 and linux_ppc64le support.

Most of the porting involves files inside /base. 

This also fixes build/build_config.h not identifying PPC architectures
correctly. Finally, it adds aix support to files inside tools/gn/, including the
bootstrap script.

R=machenbach@chromium.org, dpranke@chromium.org, adamk@chromium.org
BUG=706728

Review-Url: https://codereview.chromium.org/2807463004
Cr-Commit-Position: refs/heads/master@{#467484}
Committed:
https://chromium.googlesource.com/chromium/src/+/0088ee5017f4bef6c27243a54d89...
==========

[commit-bot: I haz the power, 2017-04-26 22:35:21]

Committed patchset #9 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/0088ee5017f4bef6c27243a54d89...

[jam, 2017-05-10 22:13:00]

Was there a discussion elsewhere about whether we want to add this code to the
chromium repo? 

I understand we don't have bots for this, but this code is sitting here
bitrotting. As developers change base, they can only guess at how to change this
ifdefs.

[Nico, 2017-05-10 22:15:29]

It's using the same model as bsd etc, it's not up to us to keep it
building. If you're changing base, just do anything.

On May 10, 2017 6:13 PM, <jam@chromium.org> wrote:

> Was there a discussion elsewhere about whether we want to add this code to
> the
> chromium repo?
>
> I understand we don't have bots for this, but this code is sitting here
> bitrotting. As developers change base, they can only guess at how to
> change this
> ifdefs.
>
> https://codereview.chromium.org/2807463004/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Dirk Pranke, 2017-05-10 23:11:54]

On 2017/05/10 22:15:29, Nico wrote:
> It's using the same model as bsd etc, it's not up to us to keep it
> building. If you're changing base, just do anything.

These changes are needed in order to be able to build GN on AIX
and Linux/s390. You need GN in order to build V8 (for Node), and
so we kinda need to support this to that end. 

As Nico says, I think we can support this to the level we support
the BSDs and we should be fine. I don't think they're planning
to port much of the rest of Chromium, so hopefully the impact will
be low.

[jam, 2017-05-11 00:54:29]

On Wed, May 10, 2017 at 4:11 PM, <dpranke@chromium.org> wrote:

> On 2017/05/10 22:15:29, Nico wrote:
> > It's using the same model as bsd etc, it's not up to us to keep it
> > building. If you're changing base, just do anything.
>

This still has a cost, and we have pushed back on other platforms before.


>
> These changes are needed in order to be able to build GN on AIX
> and Linux/s390. You need GN in order to build V8 (for Node), and
> so we kinda need to support this to that end.
>

This is what I'm wondering about: where is the discussion about whether we
need to support AIX in the codebase?


>
> As Nico says, I think we can support this to the level we support
> the BSDs and we should be fine. I don't think they're planning
> to port much of the rest of Chromium, so hopefully the impact will
> be low.
>
>
> https://codereview.chromium.org/2807463004/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.