build/grit_target.gypi - Issue 6705030: Standardize grit invokes

Side by Side Diff: build/grit_target.gypi

Issue 6705030: Standardize grit invokes (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src/

Patch Set: '' Created 9 years, 9 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

Property Changes:

Added: svn:eol-style
+ LF

OLD	NEW
(Empty)
	1 # Copyright (c) 2011 The Chromium Authors. All rights reserved.

	2 # Use of this source code is governed by a BSD-style license that can be

	3 # found in the LICENSE file.

	4

	5 # This file is meant to be included into an target that will be one or
	Mark Mentovai 2011/03/25 18:22:07 an target -> a target an target -> a target Mark Mentovai 2011/03/25 18:22:07 will be is wrong, what did you mean? will be is wrong, what did you mean? TVL 2011/03/25 18:33:30 Done. Show quoted text On 2011/03/25 18:22:07, Mark Mentovai wrote: > an target -> a target Done. TVL 2011/03/25 18:33:30 Done. Show quoted text On 2011/03/25 18:22:07, Mark Mentovai wrote: > will be is wrong, what did you mean? Done.
	6 # more uses of grit_action.gypi. To use this the following variables need to

	7 # be defined:

	8 # grit_out_dir: string: the output directory path

	9 #
	Mark Mentovai 2011/03/25 18:22:07 Remove this line. Remove this line. TVL 2011/03/25 18:33:30 Done. Show quoted text On 2011/03/25 18:22:07, Mark Mentovai wrote: > Remove this line. Done.
	10

	11 # NOTE: This file is optional, not all targets that use grit include it, some

	12 # do their own custom directives instead.

	13 {

	14 'direct_dependent_settings': {
	Mark Mentovai 2011/03/25 17:48:55 Really? I guess this means that you’re expecting a Really? I guess this means that you’re expecting all users of this to be none-type targets and to have all of the real compiling done in dependents? This is wrong if the action winds up living in a non-none-type target, like a static_library. TVL 2011/03/25 18:15:53 Yea, I'm torn on this one. It was in every place Show quoted text On 2011/03/25 17:48:55, Mark Mentovai wrote: > Really? I guess this means that you’re expecting all users of this to be > none-type targets and to have all of the real compiling done in dependents? > > This is wrong if the action winds up living in a non-none-type target, like a > static_library. Yea, I'm torn on this one. It was in every place we've used this because we always made a target for these and didn't directly hang them on other targets. So in the effort to cut down common code I did this. Mark Mentovai 2011/03/25 18:22:07 TVL wrote: TVL wrote: Show quoted text > On 2011/03/25 17:48:55, Mark Mentovai wrote: > > Really? I guess this means that you’re expecting all users of this to be > > none-type targets and to have all of the real compiling done in dependents? > > > > This is wrong if the action winds up living in a non-none-type target, like a > > static_library. > > Yea, I'm torn on this one. It was in every place we've used this because we > always made a target for these and didn't directly hang them on other targets. > So in the effort to cut down common code I did this. Have you considered putting this inside a target_conditions? If _type is none, do what you’ve got here. Otherwise, bring include_dirs directly into the target, no direct_dependent_settings. Then we can start transitioning these to happen directly in targets where that makes sense. TVL 2011/03/25 18:33:30 makes sense, i'll take a shot at that next. Show quoted text On 2011/03/25 18:22:07, Mark Mentovai wrote: > TVL wrote: > > On 2011/03/25 17:48:55, Mark Mentovai wrote: > > > Really? I guess this means that you’re expecting all users of this to be > > > none-type targets and to have all of the real compiling done in dependents? > > > > > > This is wrong if the action winds up living in a non-none-type target, like > a > > > static_library. > > > > Yea, I'm torn on this one. It was in every place we've used this because we > > always made a target for these and didn't directly hang them on other targets. > > > So in the effort to cut down common code I did this. > > Have you considered putting this inside a target_conditions? If _type is none, > do what you’ve got here. Otherwise, bring include_dirs directly into the target, > no direct_dependent_settings. Then we can start transitioning these to happen > directly in targets where that makes sense. makes sense, i'll take a shot at that next.
	15 'include_dirs': [

	16 '<(grit_out_dir)',

	17 ],

	18 },

	19 'conditions': [

	20 ['OS=="win"', {

	21 'dependencies': ['<(DEPTH)/build/win/system.gyp:cygwin'],

	22 }],

	23 ],

	24 }

	25

	26 # Local Variables:

	27 # tab-width:2

	28 # indent-tabs-mode:nil

	29 # End:

	30 # vim: set expandtab tabstop=2 shiftwidth=2:

OLD	NEW

« build/grit_action.gypi ('K') | « build/grit_action.gypi ('k') | chrome/app/policy/policy_templates.gypi » ('j') | chrome/app/policy/policy_templates.gypi » ('J')