http://sourceware.org/bugzilla/show_bug.cgi?id=14768
--- Comment #20 from Hans-Peter Nilsson <hp at sourceware dot org> --- (In reply to Tom Tromey from comment #19) > (In reply to Hans-Peter Nilsson from comment #18) > > > Sorry, there was an ambiguity here. By "work-flow" I meant > > "git-migration-unrelated usual work-flow, of checking out and building and > > committing changes to files affected by the migration changes", not > > specifically "work-flow of git migration" - though that makes sense too on > > its own. > > I don't follow this. > Could you give an example? The work-flow changes unrelated to the act of moving to git but affected by the combined (and separated) repository. The simplest example would be the extra options needed to configure for configuring *only* binutils (*without* gdb and *without* sim) in the "<path>/configure && make && make check" work-flow (alternatively the release-tarball method, but that's more involved than I expected). For separated projects, e.g. cgen, you would also need a separate tree when testing your cgen changes or changes to files in src/cpu/* instead of just checking out cgen along with your sim or binutils tree. So, the bullet-point being to test these changes in development work-flow works (that the binutils configure option above works and that the cgen separation works - patch needed there), post them to the respective lists. For newlib, I guess there wouldn't be much change in work-flow (needs gcc too, so also has overcome any tree-separation anxiety with gdb and binutils). And now that you've read this far, how about that src-release patch for sim? I'll add a pointer in my next comment. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
