make gyp_skia runnable from any directory

Fix for http://b.corp.google.com/issue?id=5019517 ('Linux make build (from out dir) no longer runs skia_gyp correctly'):

Works around gyp's finickyness about the directory from which it is run:
- changes CWD to the directory containing gyp_skia
- makes sure to pass a relative path (to skia.gyp) to the gyp innards, regardless of whether gyp_skia was launched using an absolute path

Confirmed that toplevel make builds still work on Mac and Linux.  Both of the following work on Linux too:

cd .../trunk
make clean
make -j SampleApp
cd out
make -j SampleApp
touch ../gyp/SampleApp.gyp
make -j SampleApp

cd .../trunk
make clean
$PWD/gyp_skia
cd out
make -j SampleApp
touch ../gyp/SampleApp.gyp
make -j SampleApp

[Stephen White, 2011-07-14 17:25:42]

LGTM.  Thanks!

[epoger, 2011-07-14 17:32:06]

committed as r1863

[thakis, 2011-07-14 17:45:04]

http://codereview.appspot.com/4720042/diff/1/gyp_skia
File gyp_skia (right):

http://codereview.appspot.com/4720042/diff/1/gyp_skia#newcode64
gyp_skia:64: # See http://b.corp.google.com/issue?id=5019517 ('Linux make build
Can you file a bug on some public tracker (say, the skia tracker) and reference
this? Nobody outside google will be able to look at this bug. I hate it when I
find references to, say, apple's internal bug tracker in open source code since
that conveys 0 information for most people.

[epoger, 2011-07-14 18:34:42]

http://codereview.appspot.com/4720042/diff/1/gyp_skia
File gyp_skia (right):

http://codereview.appspot.com/4720042/diff/1/gyp_skia#newcode64
gyp_skia:64: # See http://b.corp.google.com/issue?id=5019517 ('Linux make build
On 2011/07/14 17:45:04, thakis wrote:
> Can you file a bug on some public tracker (say, the skia tracker) and
reference
> this? Nobody outside google will be able to look at this bug. I hate it when I
> find references to, say, apple's internal bug tracker in open source code
since
> that conveys 0 information for most people.

Yeah, that is definitely a frustrating situation.

Unfortunately, on the other side of the balance, there are two problems with
using the public issue tracker:

1. Utility: the code.google.com issue tracker lacks some important features of
buganizer (mainly hotlists) that help me organize my work.

2. Confidentiality: sometimes in the process of discussing a bug, it's important
to add information like "we need this by March so we can launch Secret Project
XXX on time".  Sometimes it is immediately obvious that a bug falls into this
category; other times it happens in surprising ways.

Right now, my approach is to figure that non-Googlers are only occasionally
interested in my bugs, to the point where they can contact one of us directly to
ask for information.  This frees me to use the internal tools for the reasons
stated above.

Another approach would be to have two bugs filed for each issue (one on the
public tracker and another on the internal tracker, linked to each other), but
that seems like a lot of extra work.

Do you have other suggestions for dealing with the issues described above?

Thanks
Elliot

[thakis, 2011-07-14 18:46:13]

http://codereview.appspot.com/4720042/diff/1/gyp_skia
File gyp_skia (right):

http://codereview.appspot.com/4720042/diff/1/gyp_skia#newcode64
gyp_skia:64: # See http://b.corp.google.com/issue?id=5019517 ('Linux make build
On 2011/07/14 18:34:43, epoger wrote:
> On 2011/07/14 17:45:04, thakis wrote:
> > Can you file a bug on some public tracker (say, the skia tracker) and
> reference
> > this? Nobody outside google will be able to look at this bug. I hate it when
I
> > find references to, say, apple's internal bug tracker in open source code
> since
> > that conveys 0 information for most people.
> 
> Yeah, that is definitely a frustrating situation.
> 
> Unfortunately, on the other side of the balance, there are two problems with
> using the public issue tracker:
> 
> 1. Utility: the http://code.google.com issue tracker lacks some important
features of
> buganizer (mainly hotlists) that help me organize my work.

Not true: You can add arbitrary labels to bugs and then search for
"label:mylabel"

> 
> 2. Confidentiality: sometimes in the process of discussing a bug, it's
important
> to add information like "we need this by March so we can launch Secret Project
> XXX on time".  Sometimes it is immediately obvious that a bug falls into this
> category; other times it happens in surprising ways.

You can set bugs to hidden. We manage to do this in chromium somehow.

> Right now, my approach is to figure that non-Googlers are only occasionally
> interested in my bugs, to the point where they can contact one of us directly
to
> ask for information.  This frees me to use the internal tools for the reasons
> stated above.
> 
> Another approach would be to have two bugs filed for each issue (one on the
> public tracker and another on the internal tracker, linked to each other), but
> that seems like a lot of extra work.
> 
> Do you have other suggestions for dealing with the issues described above?

For this specific case, I'd dupe the internal bug into the external tracker and
have references from each bug to the other, and then link to the public one.

As I said before, I'd recommend to just use the public tracker for everything.
If you don't want to do this, please create shadow bugs for the ones you're
referencing from comments.

> 
> Thanks
> Elliot

[epoger, 2011-07-14 19:02:33]

>
>
>  1. Utility: the http://code.google.com issue tracker lacks some
>>
> important features of
>
>> buganizer (mainly hotlists) that help me organize my work.
>>
>
> Not true: You can add arbitrary labels to bugs and then search for
> "label:mylabel"


Suffice it to say that there are lots of things you can do with buganizer
hotlists that you can't do with those labels.  Regardless, your advice seems
good; I will try to follow it and see how it goes.


>
>
>  2. Confidentiality: sometimes in the process of discussing a bug, it's
>>
> important
>
>> to add information like "we need this by March so we can launch Secret
>>
> Project
>
>> XXX on time".  Sometimes it is immediately obvious that a bug falls
>>
> into this
>
>> category; other times it happens in surprising ways.
>>
>
> You can set bugs to hidden. We manage to do this in chromium somehow.
>
>
>  Right now, my approach is to figure that non-Googlers are only
>>
> occasionally
>
>> interested in my bugs, to the point where they can contact one of us
>>
> directly to
>
>> ask for information.  This frees me to use the internal tools for the
>>
> reasons
>
>> stated above.
>>
>
>  Another approach would be to have two bugs filed for each issue (one
>>
> on the
>
>> public tracker and another on the internal tracker, linked to each
>>
> other), but
>
>> that seems like a lot of extra work.
>>
>
>  Do you have other suggestions for dealing with the issues described
>>
> above?
>
> For this specific case, I'd dupe the internal bug into the external
> tracker and have references from each bug to the other, and then link to
> the public one.
>
> As I said before, I'd recommend to just use the public tracker for
> everything. If you don't want to do this, please create shadow bugs for
> the ones you're referencing from comments.
>
>
>
>  Thanks
>> Elliot
>>
>
>
http://codereview.appspot.com/**4720042/<http://codereview.appspot.com/4720042/>
>