Update includes of mojo/edk to be fully-qualified instead of relative to third_party/mojo/src.

Update includes of mojo/edk to be fully-qualified instead of relative to third_party/mojo/src.

This is split off from https://codereview.chromium.org/1350023003/ so that it can have another EDK in src/mojo/edk without conflicts. Also update header include guards as well so they don't clash with the ones in src/mojo/edk.

BUG=478251
Committed: https://crrev.com/172cd932bdf5bb1cc21a7b5bcaa164d33365075c
Cr-Commit-Position: refs/heads/master@{#351014}

[jam, 2015-09-25 23:26:36]

jam@chromium.org changed reviewers:
+ rockot@chromium.org

[jam, 2015-09-25 23:27:51]

Patchset #1 (id:1) has been deleted

[Ken Rockot(use gerrit already), 2015-09-26 01:56:58]

I admittedtly haven't reviewed every file in detail. Assuming this is
essentially

#include "mojo/edk => #include "third_party/mojo/src/mojo/edk/
#ifndef MOJO => #ifndef THIRD_PARTY_MOJO_SRC_MOJO
#endif  // MOJO => #endif  // THIRD_PARTY_MOJO_SRC_MOJO

over all of third_party/mojo, which appears to be the case from a large random
sample, lgtm!

[Ken Rockot(use gerrit already), 2015-09-26 01:58:26]

On 2015/09/26 01:56:58, Ken Rockot wrote:
> I admittedtly haven't reviewed every file in detail. Assuming this is
> essentially
> 
> #include "mojo/edk => #include "third_party/mojo/src/mojo/edk/
> #ifndef MOJO => #ifndef THIRD_PARTY_MOJO_SRC_MOJO
> #endif  // MOJO => #endif  // THIRD_PARTY_MOJO_SRC_MOJO
> 
> over all of third_party/mojo, which appears to be the case from a large random
> sample, lgtm!

Actually I wonder - why are some header guards changed and others not? Could we
just change them all to be safe?

[jam, 2015-09-26 04:18:13]

On 2015/09/26 01:58:26, Ken Rockot wrote:
> On 2015/09/26 01:56:58, Ken Rockot wrote:
> > I admittedtly haven't reviewed every file in detail. Assuming this is
> > essentially
> > 
> > #include "mojo/edk => #include "third_party/mojo/src/mojo/edk/
> > #ifndef MOJO => #ifndef THIRD_PARTY_MOJO_SRC_MOJO
> > #endif  // MOJO => #endif  // THIRD_PARTY_MOJO_SRC_MOJO
> > 
> > over all of third_party/mojo, which appears to be the case from a large
random
> > sample, lgtm!
> 
> Actually I wonder - why are some header guards changed and others not? Could
we
> just change them all to be safe?

I tried to explain this in my cl comment but I did a poor job :) This is a bit
complicated, and only arises once the other change is compiled in.

What happens is that to support a runtime switch,
third_party/mojo/src/mojo/edk/embedder/embedder.cc includes
"../../../../../../mojo/edk/system/core.h" (i.e. the header from src/mojo/edk).
Then based on the presence of the command line switch, it calls mojo::embedder::
methods in third_party or mojo::edk methods in the src/mojo/edk. As a result,
embedder.cc in third_party includes the same header from src/mojo/edk and
third_party; hence they must have different include guards. Only these files
need to have their guards updated. There's no correctness issue, since this
would be a compile time error because they're in different namespaces.

[Ken Rockot(use gerrit already), 2015-09-26 19:01:45]

On 2015/09/26 04:18:13, jam wrote:
> On 2015/09/26 01:58:26, Ken Rockot wrote:
> > On 2015/09/26 01:56:58, Ken Rockot wrote:
> > > I admittedtly haven't reviewed every file in detail. Assuming this is
> > > essentially
> > > 
> > > #include "mojo/edk => #include "third_party/mojo/src/mojo/edk/
> > > #ifndef MOJO => #ifndef THIRD_PARTY_MOJO_SRC_MOJO
> > > #endif  // MOJO => #endif  // THIRD_PARTY_MOJO_SRC_MOJO
> > > 
> > > over all of third_party/mojo, which appears to be the case from a large
> random
> > > sample, lgtm!
> > 
> > Actually I wonder - why are some header guards changed and others not? Could
> we
> > just change them all to be safe?
> 
> I tried to explain this in my cl comment but I did a poor job :) This is a bit
> complicated, and only arises once the other change is compiled in.
> 
> What happens is that to support a runtime switch,
> third_party/mojo/src/mojo/edk/embedder/embedder.cc includes
> "../../../../../../mojo/edk/system/core.h" (i.e. the header from
src/mojo/edk).
> Then based on the presence of the command line switch, it calls
mojo::embedder::
> methods in third_party or mojo::edk methods in the src/mojo/edk. As a result,
> embedder.cc in third_party includes the same header from src/mojo/edk and
> third_party; hence they must have different include guards. Only these files
> need to have their guards updated. There's no correctness issue, since this
> would be a compile time error because they're in different namespaces.

Got it - mostly I was just wondering if it would hurt to update all the guards
anyway, just for consistency. Not a big deal though

[jam, 2015-09-27 03:02:51]

Patchset #2 (id:40001) has been deleted

[jam, 2015-09-27 03:22:00]

On 2015/09/26 19:01:45, Ken Rockot wrote:
> On 2015/09/26 04:18:13, jam wrote:
> > On 2015/09/26 01:58:26, Ken Rockot wrote:
> > > On 2015/09/26 01:56:58, Ken Rockot wrote:
> > > > I admittedtly haven't reviewed every file in detail. Assuming this is
> > > > essentially
> > > > 
> > > > #include "mojo/edk => #include "third_party/mojo/src/mojo/edk/
> > > > #ifndef MOJO => #ifndef THIRD_PARTY_MOJO_SRC_MOJO
> > > > #endif  // MOJO => #endif  // THIRD_PARTY_MOJO_SRC_MOJO
> > > > 
> > > > over all of third_party/mojo, which appears to be the case from a large
> > random
> > > > sample, lgtm!
> > > 
> > > Actually I wonder - why are some header guards changed and others not?
Could
> > we
> > > just change them all to be safe?
> > 
> > I tried to explain this in my cl comment but I did a poor job :) This is a
bit
> > complicated, and only arises once the other change is compiled in.
> > 
> > What happens is that to support a runtime switch,
> > third_party/mojo/src/mojo/edk/embedder/embedder.cc includes
> > "../../../../../../mojo/edk/system/core.h" (i.e. the header from
> src/mojo/edk).
> > Then based on the presence of the command line switch, it calls
> mojo::embedder::
> > methods in third_party or mojo::edk methods in the src/mojo/edk. As a
result,
> > embedder.cc in third_party includes the same header from src/mojo/edk and
> > third_party; hence they must have different include guards. Only these files
> > need to have their guards updated. There's no correctness issue, since this
> > would be a compile time error because they're in different namespaces.
> 
> Got it - mostly I was just wondering if it would hurt to update all the guards
> anyway, just for consistency. Not a big deal though

yeah, you're right. I was initially trying to avoid churn, but it's probably
better to be consistent. done.

[Ken Rockot(use gerrit already), 2015-09-28 01:06:44]

On 2015/09/27 03:22:00, jam wrote:
> On 2015/09/26 19:01:45, Ken Rockot wrote:
> > On 2015/09/26 04:18:13, jam wrote:
> > > On 2015/09/26 01:58:26, Ken Rockot wrote:
> > > > On 2015/09/26 01:56:58, Ken Rockot wrote:
> > > > > I admittedtly haven't reviewed every file in detail. Assuming this is
> > > > > essentially
> > > > > 
> > > > > #include "mojo/edk => #include "third_party/mojo/src/mojo/edk/
> > > > > #ifndef MOJO => #ifndef THIRD_PARTY_MOJO_SRC_MOJO
> > > > > #endif  // MOJO => #endif  // THIRD_PARTY_MOJO_SRC_MOJO
> > > > > 
> > > > > over all of third_party/mojo, which appears to be the case from a
large
> > > random
> > > > > sample, lgtm!
> > > > 
> > > > Actually I wonder - why are some header guards changed and others not?
> Could
> > > we
> > > > just change them all to be safe?
> > > 
> > > I tried to explain this in my cl comment but I did a poor job :) This is a
> bit
> > > complicated, and only arises once the other change is compiled in.
> > > 
> > > What happens is that to support a runtime switch,
> > > third_party/mojo/src/mojo/edk/embedder/embedder.cc includes
> > > "../../../../../../mojo/edk/system/core.h" (i.e. the header from
> > src/mojo/edk).
> > > Then based on the presence of the command line switch, it calls
> > mojo::embedder::
> > > methods in third_party or mojo::edk methods in the src/mojo/edk. As a
> result,
> > > embedder.cc in third_party includes the same header from src/mojo/edk and
> > > third_party; hence they must have different include guards. Only these
files
> > > need to have their guards updated. There's no correctness issue, since
this
> > > would be a compile time error because they're in different namespaces.
> > 
> > Got it - mostly I was just wondering if it would hurt to update all the
guards
> > anyway, just for consistency. Not a big deal though
> 
> yeah, you're right. I was initially trying to avoid churn, but it's probably
> better to be consistent. done.

cool, still lgtm

[jam, 2015-09-28 02:22:02]

The CQ bit was checked by jam@chromium.org

[commit-bot: I haz the power, 2015-09-28 02:22:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1367303002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1367303002/60001

[commit-bot: I haz the power, 2015-09-28 02:31:40]

Committed patchset #2 (id:60001)

[commit-bot: I haz the power, 2015-09-28 02:32:27]

Patchset 2 (id:??) landed as
https://crrev.com/172cd932bdf5bb1cc21a7b5bcaa164d33365075c
Cr-Commit-Position: refs/heads/master@{#351014}