GN argument change

[Brett Wilson]

Previously if you typed "gn" on the command-line it would generate
ninja files in the default location (out/Default) with the default
build arguments. This seems to be confusing to people and is of
limited utility (you're not setting up new builds all the time, and
this overwrites any existing one). It's also a bit mysterious where
your files went (I had some questions about this from initial
testers).

I'm planning on changing this to:
gn gen <output_dir>
so you have to specify the "gen" command as well as the output
directory. The command "gn" by itself would instead print some help
message.

I'm also going to change the meaning of "gn gen" from "replace the
given build with one with no build arguments" to "regenerate the ninja
files with the build arguments associated with that output directory.
This means that you can refresh your ninja files (if you suspect some
dependency is wrong) and preserve your build arguments easily.

This should also feel more natural with a method of editing build
arguments I hope to add in the future. Seeing how many people have so
many different GYP_DEFINES it seems that making configuring these
build parameters should be a lot easier.

None of this will affect the GN-GYP build so should not affect
Chrome-team except those people playing with the pure GN build.

Please let me know if you have any objections or suggestions!

Brett

[Nico Weber]

On Thu, Feb 13, 2014 at 1:11 PM, Brett Wilson <bre...@chromium.org> wrote:

Previously if you typed "gn" on the command-line it would generate
ninja files in the default location (out/Default) with the default
build arguments. This seems to be confusing to people and is of
limited utility (you're not setting up new builds all the time, and
this overwrites any existing one). It's also a bit mysterious where
your files went (I had some questions about this from initial
testers).

I'm planning on changing this to:
  gn gen <output_dir>
so you have to specify the "gen" command as well as the output
directory. The command "gn" by itself would instead print some help
message.

Cool.

 

I'm also going to change the meaning of "gn gen" from "replace the
given build with one with no build arguments" to "regenerate the ninja
files with the build arguments associated with that output directory.
This means that you can refresh your ninja files (if you suspect some
dependency is wrong) and preserve your build arguments easily.

cmake does this, and I find it hurts more than it helps. I often end up with a build directory where I'm not sure which settings I set at some point in the past, and there's no easy way (that I'm aware of) to say "just get me the default build, no matter what I did in the past". So I'm not sure if this part is a good idea.

[Brett Wilson]

Hopefully we can make it easy enough so you don't have this problem.

My plan is to have "gn args out/Default" open the arguments for that
build dir in your EDITOR and then re-run the generation step when
you're done. So if you want to clear if. you could just delete all the
lines at that point.

My binary build needs like 5 args at this point and I find I really
need something like this. Antoine has like 20 or something from
ChromeOS and graphics stuff.

Brett

[Nico Weber]

I have 4-7. But it's easy to set up an alias for passing those in, and it's well known how to do that. For gn, I'd have to learn how to work around its automatic behavior. (You're still free to implement this of course, just saying that I consider this a misfeature in other software that has implemented it.)

 

Brett

[Brett Wilson]

Okay, I'll implement this and you should please complain and fix after
you've tried it a bit.

Brett

[Nico Weber]

Another approach to supporting the use case of passing in many flags better would be to offer some way to read a list of flags from a file. Then you could say `gn gen --flagfile=android.gnflags` – that'd be less magic, and maybe some of the flag files could even be checked in.

gyp has various (too many) ways to set GYP_DEFINES, see e.g. build/android/developer_recommended_flags.gypi (the supplement files have the problem that it's tricky to use one checkout with different supplement files.)

ps: Ideally, one would have to pass 0-1 flags to gn and everything else would have good default values – I still tell about one dev per month about the component build for example.

[Ben Boeckel]

On Thu, Feb 13, 2014 at 16:39:43 -0800, Nico Weber wrote:
> cmake does this, and I find it hurts more than it helps.

Hmm. I tend to reconfigure/regenerate a *lot*, so saving the pile of
options that I've modified (custom dependency locations, wrapping
support, install location, etc.) saves me *lots* of time.

> I often end up with a build directory where I'm not sure which
> settings I set at some point in the past, and there's no easy way
> (that I'm aware of) to say "just get me the default build, no matter
> what I did in the past". So I'm not sure if this part is a good idea.

If you want the sledgehammer approach, "rm CMakeCache.txt". If you want
the defaults, use ccmake or cmake-gui and delete all of the entries
there. It will regenerate using the default values and you might not
have to start the build from scratch.

--Ben

[Marc-Antoine Ruel]

As a data point,

isolate.py does save the configuration variables used during the build step, so that rerunning the command does not have to specify these variables again. It also caches timestamp->sha-1 association to significantly speed up later runs.

I had to make it relatively fool proof, as for example someone could isolate.py but had moved files around, invalidating the previously saved state.

I have it save its state into foo.isolated.state, where foo.isolated is the output file. It's similar to foo.dll vs foo.ilk. It's tricky, for example Nico had fun with these when he moved the .state files around during msvs -> ninja conversion.

So in the end, it can be either very obvious to the user that the state is saved or very confusing. One thing that could help if you decide to reuse the previous specified variables is to print it out at stdout both when and when not reusing variables, so that it is clear to the user and feels less magical. (isolate.py doesn't do this at the moment).

I agree with the point, having the 'saved state' in a very clear single file that is obvious to zap to the user helps here.

M-A

[Ben Boeckel]

On Fri, Feb 14, 2014 at 13:59:31 -0500, Marc-Antoine Ruel wrote:
> So in the end, it can be either very obvious to the user that the state is
> saved or very confusing. One thing that could help if you decide to reuse
> the previous specified variables is to print it out at stdout both when and
> when not reusing variables, so that it is clear to the user and feels less
> magical. (isolate.py doesn't do this at the moment).

I guess an option could be added to CMake (maybe CMAKE_REPORT_DELTA?)
which would print out when a cache variable has a different value than
the default being set in the code.

set(var dflt CACHE STRING "description")

would output something like:

path/to/CMakeLists.txt:42: var 'dflt' -> 'cachedvalue'

Maybe with the description as well.

It could also possibly dump out a command line to use to duplicate the
build options elsewhere.

This actually sounds like a nice feature when debugging broken builds
others report...

--Ben