Generate ChromeVersionConstants.java at build time.

Generate ChromeVersionConstants.java at build time.

This allows us to query version information (e.g. the build version,
whether it's an offical build) whether or not the native library is
loaded.

Future work: put channel information in this file too, and delete the
ChromeVersionInfo.init() method.

TBR=mmenke@chromium.org

Committed: https://crrev.com/e0da09649369c4b65d0bedf5bc3609299a0ef5e3
Cr-Commit-Position: refs/heads/master@{#299195}

[newt (away), 2014-10-04 00:11:59]

newt@chromium.org changed reviewers:
+ cjhopman@chromium.org, yfriedman@chromium.org

[newt (away), 2014-10-04 00:12:00]

PTAL

https://codereview.chromium.org/623403002/diff/1/chrome/android/java/src/org/...
File chrome/android/java/src/org/chromium/chrome/browser/BrowserVersion.java
(right):

https://codereview.chromium.org/623403002/diff/1/chrome/android/java/src/org/...
chrome/android/java/src/org/chromium/chrome/browser/BrowserVersion.java:11:
public class BrowserVersion {
This class will be deleted once its users have been updated to use
ChromeVersionInfo.java

[Yaron, 2014-10-06 15:45:39]

lgtm

https://codereview.chromium.org/623403002/diff/1/chrome/android/java/ChromeVe...
File chrome/android/java/ChromeVersionConstants.java.version (right):

https://codereview.chromium.org/623403002/diff/1/chrome/android/java/ChromeVe...
chrome/android/java/ChromeVersionConstants.java.version:8: public static final
String PRODUCT_NAME = "@PRODUCT_FULLNAME@";
Hmm. I think these two would allow us to clean up some other cludge in the
settings UI.

[newt (away), 2014-10-06 16:39:13]

https://codereview.chromium.org/623403002/diff/1/chrome/android/java/ChromeVe...
File chrome/android/java/ChromeVersionConstants.java.version (right):

https://codereview.chromium.org/623403002/diff/1/chrome/android/java/ChromeVe...
chrome/android/java/ChromeVersionConstants.java.version:8: public static final
String PRODUCT_NAME = "@PRODUCT_FULLNAME@";
On 2014/10/06 15:45:38, Yaron wrote:
> Hmm. I think these two would allow us to clean up some other cludge in the
> settings UI.

Yes, possibly so :)

[cjhopman, 2014-10-08 18:21:29]

lgtm

[newt (away), 2014-10-08 18:29:09]

newt@chromium.org changed reviewers:
+ thestig@chromium.org

[newt (away), 2014-10-08 18:29:10]

+thestig: chrome.gyp (one line change)

[Lei Zhang, 2014-10-08 18:46:52]

lgtm (and there's no GN changes to be done for Android, right?)

[newt (away), 2014-10-08 18:52:38]

On 2014/10/08 18:46:52, Lei Zhang wrote:
> lgtm (and there's no GN changes to be done for Android, right?)

No. These targets don't exist in GN yet.

[newt (away), 2014-10-08 18:52:42]

The CQ bit was checked by newt@chromium.org

[commit-bot: I haz the power, 2014-10-08 18:54:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/623403002/1

[commit-bot: I haz the power, 2014-10-08 21:04:45]

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

[commit-bot: I haz the power, 2014-10-08 21:04:46]

Try jobs failed on following builders:
  ios_rel_device on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device/bu...)

[newt (away), 2014-10-09 21:53:05]

https://codereview.chromium.org/623403002/diff/1/chrome/chrome_android.gypi
File chrome/chrome_android.gypi (right):

https://codereview.chromium.org/623403002/diff/1/chrome/chrome_android.gypi#n...
chrome/chrome_android.gypi:76: '<(SHARED_INTERMEDIATE_DIR)/templates',
Chris, do you think putting the generated Java file in this shared templates
directory is causing the compile failures on various try bots? e.g.

    FAILED: cd ../../chrome; python ../build/android/gyp/dex.py ...

    UNEXPECTED TOP-LEVEL EXCEPTION:
    com.android.dex.DexException: Multiple dex files define
Lorg/chromium/base/library_loader/NativeLibraries;

http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...

[cjhopman, 2014-10-09 22:07:29]

https://codereview.chromium.org/623403002/diff/1/chrome/chrome_android.gypi
File chrome/chrome_android.gypi (right):

https://codereview.chromium.org/623403002/diff/1/chrome/chrome_android.gypi#n...
chrome/chrome_android.gypi:76: '<(SHARED_INTERMEDIATE_DIR)/templates',
On 2014/10/09 21:53:04, newt wrote:
> Chris, do you think putting the generated Java file in this shared templates
> directory is causing the compile failures on various try bots? e.g.
> 
>     FAILED: cd ../../chrome; python ../build/android/gyp/dex.py ...
> 
>     UNEXPECTED TOP-LEVEL EXCEPTION:
>     com.android.dex.DexException: Multiple dex files define
> Lorg/chromium/base/library_loader/NativeLibraries;
> 
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...

Yeah, that would do it. I see that we do this other places... we really
shouldn't. All targets that generate sources should have their own unique root.

I would suggest changing the output path to
<(SHARED_INTERMEDIATE_DIR)/templates/<(_target_name)/...

It looks like nobody passes <(SHARED_INTERMEDIATE_DIR)/templates as a
generated_src_dir so it should work.

[newt (away), 2014-10-09 22:45:04]

On 2014/10/09 22:07:29, cjhopman wrote:
> https://codereview.chromium.org/623403002/diff/1/chrome/chrome_android.gypi
> File chrome/chrome_android.gypi (right):
> 
>
https://codereview.chromium.org/623403002/diff/1/chrome/chrome_android.gypi#n...
> chrome/chrome_android.gypi:76: '<(SHARED_INTERMEDIATE_DIR)/templates',
> On 2014/10/09 21:53:04, newt wrote:
> > Chris, do you think putting the generated Java file in this shared templates
> > directory is causing the compile failures on various try bots? e.g.
> > 
> >     FAILED: cd ../../chrome; python ../build/android/gyp/dex.py ...
> > 
> >     UNEXPECTED TOP-LEVEL EXCEPTION:
> >     com.android.dex.DexException: Multiple dex files define
> > Lorg/chromium/base/library_loader/NativeLibraries;
> > 
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...
> 
> Yeah, that would do it. I see that we do this other places... we really
> shouldn't. All targets that generate sources should have their own unique
root.

That's what I suspected, though I decided to followed the existing pattern
instead of trusting my instinct. Tsk tsk.

> I would suggest changing the output path to
> <(SHARED_INTERMEDIATE_DIR)/templates/<(_target_name)/...
> 
> It looks like nobody passes <(SHARED_INTERMEDIATE_DIR)/templates as a
> generated_src_dir so it should work.

Good suggestion. I also updated the two other gyp files that were placing files
in <(SHARED_INTERMEDIATE_DIR)/templates.

[newt (away), 2014-10-09 22:46:08]

newt@chromium.org changed reviewers:
+ mmenke@chromium.org

[newt (away), 2014-10-09 22:46:09]

TBR mmenke: cronet.gypi

[newt (away), 2014-10-09 22:51:09]

PTAL

Looks like the shared template directory problem doesn't exist in GN, so no need
to fix it there.

build/config/android/rules.gni:

    template("java_cpp_template") {
      ...
      gen_dir =
"${target_gen_dir}/${target_name}/java_cpp_template/${package_name}"

[cjhopman, 2014-10-09 22:54:04]

On 2014/10/09 22:51:09, newt wrote:
> PTAL
> 
> Looks like the shared template directory problem doesn't exist in GN, so no
need
> to fix it there.
> 
> build/config/android/rules.gni:
> 
>     template("java_cpp_template") {
>       ...
>       gen_dir =
> "${target_gen_dir}/${target_name}/java_cpp_template/${package_name}"

Ha. GN actually goes a step further and doesn't allow you to pass generated src
dirs at all, you must zip your generated java files together and pass that zip
file to dependents. Makes it much harder to accidentally have your dependent
include something you didn't intend it to.

still lgtm

This might affect ide configuration, though, idk...

[newt (away), 2014-10-09 22:56:32]

The CQ bit was checked by newt@chromium.org

[newt (away), 2014-10-09 22:57:19]

On 2014/10/09 22:54:04, cjhopman wrote:
> On 2014/10/09 22:51:09, newt wrote:
> > PTAL
> > 
> > Looks like the shared template directory problem doesn't exist in GN, so no
> need
> > to fix it there.
> > 
> > build/config/android/rules.gni:
> > 
> >     template("java_cpp_template") {
> >       ...
> >       gen_dir =
> > "${target_gen_dir}/${target_name}/java_cpp_template/${package_name}"
> 
> Ha. GN actually goes a step further and doesn't allow you to pass generated
src
> dirs at all, you must zip your generated java files together and pass that zip
> file to dependents. Makes it much harder to accidentally have your dependent
> include something you didn't intend it to.
> 
> still lgtm
> 
> This might affect ide configuration, though, idk...

Ugh. It does complicate the Eclipse classpath. Oh well :/

[commit-bot: I haz the power, 2014-10-09 22:58:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/623403002/50001

[commit-bot: I haz the power, 2014-10-09 23:28:36]

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

[commit-bot: I haz the power, 2014-10-09 23:28:37]

Try jobs failed on following builders:
  android_aosp on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_aosp/bu...)

[newt (away), 2014-10-10 18:53:17]

newt@chromium.org changed reviewers:
+ boliu@chromium.org

[newt (away), 2014-10-10 18:53:17]

+boliu: for android_webview/java_library_common.mk

[boliu, 2014-10-10 19:01:40]

On 2014/10/10 18:53:17, newt wrote:
> +boliu: for android_webview/java_library_common.mk

lgtm

[newt (away), 2014-10-10 19:21:35]

The CQ bit was checked by newt@chromium.org

[commit-bot: I haz the power, 2014-10-10 19:23:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/623403002/370001

[commit-bot: I haz the power, 2014-10-10 21:49:07]

Committed patchset #3 (id:370001)

[commit-bot: I haz the power, 2014-10-10 21:49:44]

Patchset 3 (id:??) landed as
https://crrev.com/e0da09649369c4b65d0bedf5bc3609299a0ef5e3
Cr-Commit-Position: refs/heads/master@{#299195}