Thanks for the detailed replies. I have to say neither of these workflows seem particularly nice for extended development. I prefer Jeremy's (that's the one I set up for Nick) because it doesn't involve moving directories around. (Also use of git-worktree seems to just be a disk saving exercise, not actually helping simplify the workflow.) Neither fetch time nor disk usage are the issue; the issue is developer time when doing an edit/build/test/upload loop.
The problem is both Jakob and Jeremy's workflow involves a "final upload" -- what about iterative development? I like to upload early and often, and the upload is the hard part of this workflow since you need to: 1. Make sure your main repo does *not* have the branch checked out (since that will block push). 2. From the chrome repo: git push. 3. From the main repo: git checkout <branch>. 4. From the main repo: git cl upload. Not to mention how hard it is to manage multiple stacked branches in this workflow (for example, for git push to work from the chrome repo, the branch upstream needs to be the remote branch, so you can't have a local branch hierarchy). I really can't understand why doing all your work from inside a sub-repo of the chrome repo isn't a supported workflow. Literally the only thing missing is gclient being able to check out DEPS of the v8 repo. That's the only difference between the v8 inside chrome and the "main" standalone v8 repo, and it would surely make development much easier? On Sat, 17 Dec 2016 at 06:56 Paweł Hajdan, Jr. <[email protected]> wrote: +infra-dev,machenbach On Fri, Dec 16, 2016 at 8:18 PM, Jeremy Roman <[email protected]> wrote: My workflow has been to have two repositories (a standalone one and a Chromium one), but with the standalone one added as a remote of the chromium one. Mine are /src/chromium/src and /src/v8/v8 $ cd /src/chromium/src/v8 $ git remote add standalone /src/v8/v8 Then I can fetch revisions from the standalone repo, check them out, push/pull, etc., and do the final upload from the standalone supported repo. Works well enough for me. On Fri, Dec 16, 2016 at 12:36 PM, Jakob Kummerow <[email protected]> wrote: Working on V8 from within a Chromium checkout's src/v8/ directory is not a supported workflow. There are various ways to hack it, but The Official Way is to get a separate V8 checkout with "fetch v8" (which should be fairly quick, so the only cost is a bit of disk space). For testing local changes, I have a secondary workdir of my standalone V8 checkout in my Chromium checkout (which I created with git-new-workdir, apparently "git worktree" is how you'd do it now), which I rename as needed (because symlinking used to confuse ninja, not sure if it still does): # setup $ cd /work/v8/ $ git worktree add /work/chromium/src/v8-custom # implement new feature $ git checkout -b my-feature $ ... $ git commit -am 'yay new feature' # test feature $ cd /work/chromium/src $ git pull && gclient sync # let "gclient sync" see the official "v8" directory $ mv v8 v8-official $ mv v8-custom v8 $ (cd v8; git checkout -f my-feature) $ ninja ... # cleanup when done $ mv v8 v8-custom $ mv v8-official v8 # land it $ cd /work/v8/ $ git cl upload You can iterate on the patch with: $ cd /work/v8/ $ edit... $ git commit -a --amend $ cd /work/chromium/src $ (cd v8; git checkout -f my-feature) $ ninja ... On Fri, Dec 16, 2016 at 1:10 AM, Daniel Cheng <[email protected]> wrote: I can't say I recommend this, but for limited development, I just upload with --bypass-hooks and let the v8_presubmit bot make sure I didn't do anything bad. It's probably still worth pulling down an actual v8 checkout; I found running the v8 tests to be a bit painful without an actual v8 checkout. Daniel On Thu, Dec 15, 2016 at 8:56 PM Trent Apted <[email protected]> wrote: I encountered something similar with WebRTC. It has a helpful message when you try to `git cl upload` (basically: you *must* create a separate checkout): Creating CLs from this location is not supported! Please make sure the current working directory is the parent directory of this directory. If you're working with a Chromium checkout, you'll have to create a full WebRTC checkout and upload a CL from that. See https://webrtc.org/native-code/development/ for instructions. V8 has instructions here - https://github.com/v8/v8/wiki/Using%20Git - that seem up-to-date. (tl;dr: `fetch v8` should work) You might be able to save some electrons with something like $ mkdir v8 # at the level above your chromium/.gclient $ gclient-new-workdir.py chromium/src/v8 v8/v8 $ cd v8/v8 $ git checkout master $ cd .. $ cat -> .gclient solutions = [ { "url": "https://chromium.googlesource.com/v8/v8.git";, "managed": False, "name": "v8", "deps_file": "DEPS", "custom_deps": {}, }, ] ^D That will symlink all the git objects for v8 so they're not re-downloaded, and share disk blocks. But you'll still get dupes of v8's DEPS. Getting much more creative probably risks wedging your chromium checkout into a weird state :/ On 16 December 2016 at 15:18, Matt Giuca <[email protected]> wrote: Hi, TL;DR: How do you work on V8 (build, test and upload CLs) from within the v8 subrepo of a Chromium checkout (without having to make a separate v8 checkout)? I was helping Nick get started on V8 development within Chromium and we couldn't find any way to run the presubmit from within the v8 directory that's checked out inside the chromium repo. That is, we would like to be able to do: ~/chrome/src$ cd v8/src ~/chrome/src/v8/src$ git cl presubmit However, if you do that, you get: Traceback (most recent call last): File "/usr/local/google/home/mgiuca/chrome/depot_tools/git_cl.py", line 5654, in <module> sys.exit(main(sys.argv[1:])) File "/usr/local/google/home/mgiuca/chrome/depot_tools/git_cl.py", line 5636, in main return dispatcher.execute(OptionParser(), argv) File "/usr/local/google/home/mgiuca/chrome/depot_tools/subcommand.py", line 252, in execute return command(parser, args[1:]) File "/usr/local/google/home/mgiuca/chrome/depot_tools/git_cl.py", line 4222, in CMDpresubmit change=cl.GetChange(base_branch, None)) File "/usr/local/google/home/mgiuca/chrome/depot_tools/git_cl.py", line 1685, in RunHook gerrit_obj=self._codereview_impl.GetGerritObjForPresubmit()) File "/usr/local/google/home/mgiuca/chrome/depot_tools/presubmit_support.py", line 1247, in DoPresubmitChecks results += executer.ExecPresubmitScript(presubmit_script, filename) File "/usr/local/google/home/mgiuca/chrome/depot_tools/presubmit_support.py", line 1157, in ExecPresubmitScript result = eval(function_name + '(*__args)', context) File "<string>", line 1, in <module> File "<string>", line 287, in CheckChangeOnCommit File "<string>", line 260, in _CommonChecks File "<string>", line 101, in _CheckUnwantedDependencies ImportError: No module named checkdeps Turns out this is because the v8 directory is missing the buildtools subdirectory which is checked out by its DEPS. Basically, when gclient checks out all the subrepos of chrome (including v8) it doesn't recursively check out the DEPS' DEPS. So we can't submit v8 from there and maybe some other things are broken too. If you make a separate checkout of v8 (outside of chrome), and run gclient sync, it's fine. But then you can't test your changes in Chrome, resulting in tedious copying of git patch data back and forth between the two checkouts of v8. It would be much better if you could just do the full v8 edit/build/test/upload workflow from within the v8 checkout inside chrome. I don't want gclient to be recursive by default. I just want to be able to set it up so it fetches v8. We found this old (looks obsolete) documentation describing exactly how to do this: http://www.chromium.org/developers/how-tos/chromium-modularization#Advanced_Usage - It gives the example of v8 but then says "The V8 example is somewhat simple since V8 does not itself have other dependencies." That's no longer true since V8 *does* have other dependencies. This example doesn't get what we want. - Then it goes on to say how to do webkit (no longer applicable) and get webkit's dependencies. But we tried setting up .gclient with v8 similar to how webkit is set up there, and it didn't work. I won't go into the details of how it didn't work (can discuss on request). How do you do this? I'd imagine most v8 engineers have a workflow that solves this problem. There must be a way to have gclient check out the DEPS of v8 without needing to make a separate v8 checkout. Thanks Matt & Nick -- -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/a/chromium.org/group/chromium-dev -- -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/a/chromium.org/group/chromium-dev -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/a/chromium.org/group/chromium-dev -- -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/a/chromium.org/group/chromium-dev -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
