Proposal for a `gn init` command

[Paul Herman]

Hi everyone,

I recently found gn and it's very pleasant to work with in the face of cross platform codebases. However, as outlined in the documentation, starting a small project is non-trivial. I was wondering if there are any thoughts about a `gn init` command?

There are obviously pros and cons to the idea and here's some of my considerations.

It'll be easy enough to at least automate the quickstart guide (create .gn, BUILD.gn, BUILDCONFIG.gn and a directory structure). I'm not sure how much further this should go (for example, should it provide some of the most popular toolchains, such as gcc, clang, msvc) as it gets into territory where there's no "one size fits all" solution.

There seems to be some traction to make gn more standalone. I've seen repos on Github trying to provide a starting base (https://github.com/timniederhausen/gn-build).

Depending on how much is automated there's an obvious maintenance cost. I'm not sure how to estimate it nor how to compare it with the cost of maintaining the quickstart documentation (https://gn.googlesource.com/gn/+/main/docs/standalone.md).

[Roland McGrath]

I don't think there's value in adding a GN subcommand if its function will be simply to copy some stock files into a directory structure for your project. There's no one right stock setup to use, but even if you want to provide a "canonical" sample then you can just do that by distributing your tree of files to copy.  Perhaps folks packaging GN will include that tree along with the GN tool, but there's no need for the tool to know about it.

[Paul Herman]

That is a fair comment. I agree with your assessment that we should split thr problem in two parts:

1. providing a simple "canonical" tree to start a new project - I think there is value here.

2. bundling the above into the gn binary - your point is valid and we can abandon this.

Let's focus on #1 for the time being. I think the value exists: as an example, looking at the gcc_toolchain template it is quite complex but lots of bits are reusable for any project. Ideally, not every project would go through cleaning up the chromium specific bits. However, answering what "canonical" is and how far it should go is non-trivial. I would love for it to be something that goes as far as "I can write a simple executable and it will likely compile on well known platforms and compilers".

--

Regards,

Paul