Canonical way to build a different branch

[Michael Giuffrida]

I'm trying to build M38 per Working with release branches but keep failing.

What am I doing wrong? Is there a better way?

Last time I tried this and did "git cl upload; git cl try", the patch failed to apply on the bots even though the patch was correct for that branch. So I'm starting over trying to do everything right.

In a brand new repository:

$ fetch chromium

$ gclient sync --with_branch_heads

$ git fetch

$ BRANCH=2125

$ git checkout -b branch_$BRANCH branch-heads/$BRANCH

$ gclient sync --jobs 16

Error: you have unstaged changes in third_party/foo. # Why?

$ # attempt to fix but it wants me to manually merge changes... no thank you

$ rm -rf third_party

$ gclient sync --jobs 16

......

\________ running '/usr/bin/python src/third_party/binutils/download.py' in '/usr/local/google/home/michaelpg/cr/m38'

/usr/bin/python: can't open file 'src/third_party/binutils/download.py': [Errno 2] No such file or directory

Error: Command /usr/bin/python src/third_party/binutils/download.py returned non-zero exit status 2 in /usr/local/google/home/michaelpg/cr/m38

Then ninja fails (probably to be expected):

ninja: error: '../../third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_primitive_field.cc', needed by 'obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_primitive_field.o', missing and no known rule to make it

I'd appreciate any help or being pointed to docs.

Michael

[Lei Zhang]

"rm -rf third_party" looks... wrong. What was the third_party/foo that
you were getting complaints about?

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

[Michael]

It was one foo after another. I don't have the names in my scrollback anymore. But they were thousands of commits apart, as if they tried to first sync with one branch and then with another (thus my rather desperate attempt to clear out third_party).

I will start over, again, and see what happens.

[Jeremy Roman]

I don't think DEPS is maintained on branches, so the versions of
dependent repositories may not be correct.. If I understand correctly,
you have to build at a particular release (when a release is tagged,
chrome-tpm@ also dumps the DEPS file into the tree).

(Someone please correct me if I'm wrong, but I've been working under
the "build at a release tag, commit to a branch head" rule of thumb
for working with release branches.)

[Primiano Tucci]

This is a bi-weekly recurring topic on this forum :-)

Short answer: 

- Release branches !== release tags.

- Syncing and building a release tag is easy and works for everybody (see Syncing to a release in the get-the-code page.)

- Syncing and building a release branch is a more convoluted process which requires a workflow that is not publicly available.

- We should reword the "Working with release branches" from the public documentation, that is just misleading. That page explains how to checkout only the main project from a release branch, but not the corresponding third_party deps. It is NOT possible to work on a release branch without using an internal mysterious workflow.

Long answer:

See this previous discussion for more details

[Primiano Tucci]

- We should reword the "Working with release branches" from the public documentation, that is just misleading. That page explains how to checkout only the main project from a release branch, but not the corresponding third_party deps. It is NOT possible to work on a release branch without using an internal mysterious workflow.

 

Ok I did reword the Working_with_release_branches section and swapped their order (release tag first, branch 2nd). Hopefully should be clearer now.

[Michael]

Thanks. I've been able to successfully build M39. But then I brought my repo back to origin/master, and now I can't build M39 anymore.

I am following the instructions under "Syncing and building a release tag". 39.0.2171.29 is a legitimate version of Chrome OS.

michaelpg@erlkonig:~/cr/cr/src$ git fetch --tags

michaelpg@erlkonig:~/cr/cr/src$ git checkout -b 39.0.2171.29 tags/39.0.2171.29

Branch 39.0.2171.29 set up to track remote ref refs/tags/39.0.2171.29 by rebasing.

Switched to a new branch '39.0.2171.29'

michaelpg@erlkonig:~/cr/cr/src$ gclient sync --with_branch_heads --jobs 16

michaelpg@erlkonig:~/cr/cr/src$ ninja -C out/Debug -j 9999 -l 40 chrome

...

[2344/14205] RULE Generating binding f...m ../../../core/svg/SVGViewElement.idl

FAILED: cd ../../third_party/WebKit/Source/bindings/core/v8; python ../../scripts/idl_compiler.py --cache-dir ../../../../../../out/Debug/gen/blink/bindings/scripts --output-dir ../../../../../../out/Debug/gen/blink/bindings/core/v8 --interfaces-info ../../../../../../out/Debug/gen/blink/bindings/modules/InterfacesInfoModules.pickle --write-file-only-if-changed 1 "../../../core/svg/SVGViewElement.idl"

Traceback (most recent call last):

  File "../../scripts/idl_compiler.py", line 173, in <module>

    sys.exit(main())

  File "../../scripts/idl_compiler.py", line 169, in main

    generate_bindings(options, input_filename)

  File "../../scripts/idl_compiler.py", line 146, in generate_bindings

    idl_compiler.compile_file(input_filename)

  File "../../scripts/idl_compiler.py", line 127, in compile_file

    self.compile_and_write(idl_filename)

  File "../../scripts/idl_compiler.py", line 108, in compile_and_write

    definitions = self.reader.read_idl_definitions(idl_filename)

  File "/usr/local/google/home/michaelpg/cr/cr/src/third_party/WebKit/Source/bindings/scripts/idl_reader.py", line 70, in read_idl_definitions

    return self.interface_dependency_resolver.resolve_dependencies(definitions, component)

  File "/usr/local/google/home/michaelpg/cr/cr/src/third_party/WebKit/Source/bindings/scripts/interface_dependency_resolver.py", line 118, in resolve_dependencies

    self.reader)

  File "/usr/local/google/home/michaelpg/cr/cr/src/third_party/WebKit/Source/bindings/scripts/interface_dependency_resolver.py", line 143, in merge_interface_dependencies

    dependency_definitions = reader.read_idl_file(dependency_idl_filename)

  File "/usr/local/google/home/michaelpg/cr/cr/src/third_party/WebKit/Source/bindings/scripts/idl_reader.py", line 78, in read_idl_file

    ast = blink_idl_parser.parse_file(self.parser, idl_filename)

  File "/usr/local/google/home/michaelpg/cr/cr/src/third_party/WebKit/Source/bindings/scripts/../../../../../tools/idl_parser/idl_parser.py", line 1089, in ParseFile

    with open(filename) as fileobject:

(dozens more of these until my scrollback is full, and ninja eventually ends in an error state)

Am I missing a step somewhere? I'd hate for my workflow to include "nuke the repo and start over".

{ "GYP_DEFINES": "component=shared_library chromeos=1 clang=1 use_goma=1 gomadir=/usr/local/google/home/michaelpg/dev/goma", "GYP_GENERATOR_FLAGS": "output_dir=out" }

Thanks again.

Michael

[Primiano Tucci]

Have you tried nuking only out/ and starting again?

It might be that some stale autogenerated interface is left behind (IIRC there was some similar incident reported on this ML).

Eventually try to just remove out/Debug/gen first.

The way you sync and build looks correct.

(Note: if you don't plan to commit, you can just "git checkout 39.0.2171.29", without having to create a branch from the tag, and git checkout origin/master or origin/lkcr to get back to *trunk*. However this is unrelated with your problem here)

--

[Michael]

Thanks, "rm -rf out/" lets me gyp and build successfully.