Why does htis need its own repo? Can't bootstrap.py just live in the chromium repo where it used to be?

gn's `gen.py` is supposed to be a bootstrap script from what I can tell.

So the bootstrap.py script in chromium's repo could clone the gn code and call gen.py with the right flags.

And eventually, the packagers could call gen.py directly maybe.

Yeah, that would probably be better if we could get it working.  How would the publish_tarball bot clone the gn repo to tools/gn if it's nonempty?

Does it have to? bootstrap.py could clone it on demand. (Off a fixed rev I suppose.)

Once packagers have the tarball, they should be able to complete the build with no network.  So the tarball needs to include all resources that are pulled from the network.

I suppose the bot could just clone gn to /tmp and then merge the dirs.  does this sg?

I'm not familiar with how the tarballs work. Do they also not require `gclient sync`? Does the bot run that and tar up all the deps too?

How do tarball users acquire ninja? gn is now in a similar spot that ninja used to be in, so medium term doing the same for gn and ninja would make sense to me.

Short term, comment 5 sounds fine to me.

The bot does not run gclient sync, but whatever libraries in third_party that are part of the main repo (not DEPSed in) will be included in the tarballs.

The system ninja is used.  I don't think gn is mainstream enough to have a default package for any distros.

Ok, for now I'm going with the solution from c#5, so I'm closing this issue out.