depot_tools ships a "vpython" binary that is added to the $PATH
for all Chromium engineers. This binary is versioned by depot_tools
which we roll in ourselves as part of `gclient sync`.
By using `vpython` instead of `python`, we are no longer depended
on the Python version installed locally and instead use the version
we pull in from DEPS.
R=liviurau@chromium.org
Change-Id: If49a54c24b6cf129ff843cd9ca1140a723a78afb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2571462
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Both front_end_devtools_module_entrypoint_sources and
generated_devtools_module_entrypoint_sources were unused, since
the `devtools_entrypoint` migration has finished.
Secondly, we can rename generated_typescript_entrypoint_sources to
generated_module_entrypoint_sources, since we no longer need to
distinguish between JavaScript and TypeScript entrypoints.
Lastly, we can clean up the definition of
devtools_module_entrypoint_sources to no longer include the
$resources_out_dir line, which saves some duplication.
R=aerotwist@chromium.org
Change-Id: I1a327cf40cec6630b3be7ac53e2c87f7e179c895
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2566802
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
There previously were two special files that were handled
by `build_release_applications`: root.js and RuntimeInstantiator.js.
Both files are explicitly part of the startup process of DevTools
and its various entrypoints.
To remove the copying from `build_release_applications`, we have
to move these to the relevant `devtools_entrypoint`. Since a
`devtools_entrypoints` bundles all subdirectories, we can't keep
these files in `front_end/` directly. Instead, we move these files
to `startup/` to denote their special-casing in the startup process.
Next to that, we have to fix all usages of these files in the entrypoints.
For all JavaScript entrypoint files, all side-effect legacy files
that are loaded by `startup.js` (previously known as `root.js` and renamed
to prevent confusion with the `root/` module) are removed. All
"additional" legacy files that a particular entrypoint requires are
still loaded as-is.
The RuntimeInstantiator is moved to become an implementation detail
of `startup/`. Therefore, all of the usages that were previously
importing from `RuntimeInstantiator` now import via `startup.js`.
In the end, the special-casing of these files are removed and renamed
for clarity. In the future, we want to remove the complicated
entrypoints startup process, but we are not ready for that yet.
That will require additional cleanups with `resources` in `module.json`
before that change can happen.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: I198d5a62d2aab70f842c68d9b4c0871fde1587a4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2485072
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
To continue to move away from `build_release_applications.py`, move
building `common-legacy.js` into `devtools_entrypoint`. In the end,
it will allow us to remove `_rollup_module` from
`build_release_applications.py`.
The logic in `build_release_applications.py` is updated to assume
a pregenerated `-legacy.js` file based on the `pre_generates_legacy`
option in the `module.json` file. Once all `-legacy.js are migrated,
we can remove this option once again.
To make sure that we Rollup properly, we should assume that an
entrypoint in the same folder is regarded as external. Otherwise,
we would rollup the contents of `common.js` into `common-legacy.js`,
which is not what we want.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: Idcda3e1c2436a0bebb36501523c8d586d6e86fac
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2450297
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
For all `_module.js` files, we currently copy all `modules` into
the `module.json` metadata. However, since then the Runtime got
updated to always load the entrypoint. This is possible, because
in release modes only the entrypoint exists and all other files
are removed.
Therefore, we can use an empty array to denote that solely the
entrypoint should be loaded by the Runtime. If however the module
has a legacy file, the Runtime needs to load that instead. (See
`Runtime._loadModules` for more information) Therefore, include
solely the legacy file to the metadata information in the
`_module.js` to load it.
Eventually, this will allow us to remove the files from the modules
array in the `module.json`, as only Closure would require that
information.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: Ie14bd55b29b356a39aad7e8ca2041c979bd1b2cb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2461783
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
This CL addresses a few issues that will help make it possible
to build Chromium using Python 3.
Nothing in this CL should cause any functional changes, and
Python 3 is not required (indeed, won't even work yet), but
this CL will be needed to unblock other work.
See https://crrev.com/c/2333868 for the roll-up Chromium patch,
which also has multiple other dependencies.
Bug: 1112471
Change-Id: Ica8a5b2b24674e1abd267bcd558b7101a6da6fc5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2330718
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@google.com>
Since formatter_worker.ts is the actual entrypoint for the worker,
we should perform the message handling and postMessage invocations
there. This allows us to remove accesses to the `self.postMessage`
global in the implementation of the parsers and formatters, allowing
proper unit testing. Note all `self.postMessage`s have been removed,
as that requires additional refactoring in a follow-up CL.
This also paves the way for removing `formatter_worker_entrypoint`,
which is currently a no-op file. That requires additional infrastructure
changes to `Common.Worker` to allow specify a subfolder of `front_end/`
to be passed as the entrypoint.
Note that this CL also removes the `parseSCSS` method, which appears to
be unused in both the Chromium codebase as well as externally. Testing
on stable shows that we are currently not formatting `.scss` files
anyways.
R=aerotwist@chromium.org
Bug: 1011811
Change-Id: I808c5ea83efa5ec9fed6bd1aec2418487f553848
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2410232
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This reverts commit 862107080d.
Reason for revert: Chromium build issue fixed.
Original change's description:
> Revert "Reland "Remove support for remote modules""
>
> This reverts commit b3859e8d65.
>
> Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
>
> Original change's description:
> > Reland "Remove support for remote modules"
> >
> > This reverts commit d5044ddf05.
> >
> > Reason for revert: Fixed Chromium debug issue.
> >
> > Original change's description:
> > > Revert "Remove support for remote modules"
> > >
> > > This reverts commit 419c91eff6.
> > >
> > > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> > >
> > > Original change's description:
> > > > Remove support for remote modules
> > > >
> > > > LightHouse is currently broken in Canary, because of problems with
> > > > the appspot server. This isn't the first occurrence of this problem
> > > > and it becomes increasingly more difficult to figure out why the
> > > > server keeps on breaking. This is combined with a large infrastructure
> > > > cost of supporting remote modules and a confusing debugging experience
> > > > when working with it locally.
> > > >
> > > > The reason we had remote modules was the fact that these modules are
> > > > too large to be included in the Chromium bundle. In the last months,
> > > > we have made numerous remote modules bundled, by applying minifications
> > > > and optimizations to each module.
> > > >
> > > > The remaining remote module that we are currently shipping is LightHouse.
> > > > Since the remote appspot server is broken and unlikely to be fixed
> > > > anytime soon, now is the best time to finally resolve the remote
> > > > modules question.
> > > >
> > > > Therefore, we remove support for remote modules from the `module.json`
> > > > files and `Runtime.js`. Additionally, we update the build system
> > > > to properly generate the required files and load them via ES modules.
> > > >
> > > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > > more infrastructure related to scripts/remote modules, but given that
> > > > this CL is already quite large we are doing that in a follow-up CL.
> > > >
> > > > Follow-up action items for the LightHouse folks are to further decrease
> > > > the bundle size for LightHouse. Since we are now loading it via ES
> > > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > > well. This allows us to remove the copy of the SDK files, as well as
> > > > make use of proper ES exports, rather than the browserified requires.
> > > >
> > > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > > >
> > > > Fixed: 1128890
> > > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> > >
> > > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> > >
> > > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > > No-Presubmit: true
> > > No-Tree-Checks: true
> > > No-Try: true
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
> >
> > Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> > Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
>
> TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
>
> Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Change-Id: I8718e9d94c384a13fd18261f8f497d32418658fb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2421690
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit b3859e8d65.
Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
Original change's description:
> Reland "Remove support for remote modules"
>
> This reverts commit d5044ddf05.
>
> Reason for revert: Fixed Chromium debug issue.
>
> Original change's description:
> > Revert "Remove support for remote modules"
> >
> > This reverts commit 419c91eff6.
> >
> > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> >
> > Original change's description:
> > > Remove support for remote modules
> > >
> > > LightHouse is currently broken in Canary, because of problems with
> > > the appspot server. This isn't the first occurrence of this problem
> > > and it becomes increasingly more difficult to figure out why the
> > > server keeps on breaking. This is combined with a large infrastructure
> > > cost of supporting remote modules and a confusing debugging experience
> > > when working with it locally.
> > >
> > > The reason we had remote modules was the fact that these modules are
> > > too large to be included in the Chromium bundle. In the last months,
> > > we have made numerous remote modules bundled, by applying minifications
> > > and optimizations to each module.
> > >
> > > The remaining remote module that we are currently shipping is LightHouse.
> > > Since the remote appspot server is broken and unlikely to be fixed
> > > anytime soon, now is the best time to finally resolve the remote
> > > modules question.
> > >
> > > Therefore, we remove support for remote modules from the `module.json`
> > > files and `Runtime.js`. Additionally, we update the build system
> > > to properly generate the required files and load them via ES modules.
> > >
> > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > more infrastructure related to scripts/remote modules, but given that
> > > this CL is already quite large we are doing that in a follow-up CL.
> > >
> > > Follow-up action items for the LightHouse folks are to further decrease
> > > the bundle size for LightHouse. Since we are now loading it via ES
> > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > well. This allows us to remove the copy of the SDK files, as well as
> > > make use of proper ES exports, rather than the browserified requires.
> > >
> > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > >
> > > Fixed: 1128890
> > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> >
> > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> >
> > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
>
> Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
This reverts commit d5044ddf05.
Reason for revert: Fixed Chromium debug issue.
Original change's description:
> Revert "Remove support for remote modules"
>
> This reverts commit 419c91eff6.
>
> Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
>
> Original change's description:
> > Remove support for remote modules
> >
> > LightHouse is currently broken in Canary, because of problems with
> > the appspot server. This isn't the first occurrence of this problem
> > and it becomes increasingly more difficult to figure out why the
> > server keeps on breaking. This is combined with a large infrastructure
> > cost of supporting remote modules and a confusing debugging experience
> > when working with it locally.
> >
> > The reason we had remote modules was the fact that these modules are
> > too large to be included in the Chromium bundle. In the last months,
> > we have made numerous remote modules bundled, by applying minifications
> > and optimizations to each module.
> >
> > The remaining remote module that we are currently shipping is LightHouse.
> > Since the remote appspot server is broken and unlikely to be fixed
> > anytime soon, now is the best time to finally resolve the remote
> > modules question.
> >
> > Therefore, we remove support for remote modules from the `module.json`
> > files and `Runtime.js`. Additionally, we update the build system
> > to properly generate the required files and load them via ES modules.
> >
> > We will be able to perform subsequent cleanups in the Runtime to remove
> > more infrastructure related to scripts/remote modules, but given that
> > this CL is already quite large we are doing that in a follow-up CL.
> >
> > Follow-up action items for the LightHouse folks are to further decrease
> > the bundle size for LightHouse. Since we are now loading it via ES
> > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > well. This allows us to remove the copy of the SDK files, as well as
> > make use of proper ES exports, rather than the browserified requires.
> >
> > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> >
> > Fixed: 1128890
> > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
>
> TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
>
> Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit 419c91eff6.
Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
Original change's description:
> Remove support for remote modules
>
> LightHouse is currently broken in Canary, because of problems with
> the appspot server. This isn't the first occurrence of this problem
> and it becomes increasingly more difficult to figure out why the
> server keeps on breaking. This is combined with a large infrastructure
> cost of supporting remote modules and a confusing debugging experience
> when working with it locally.
>
> The reason we had remote modules was the fact that these modules are
> too large to be included in the Chromium bundle. In the last months,
> we have made numerous remote modules bundled, by applying minifications
> and optimizations to each module.
>
> The remaining remote module that we are currently shipping is LightHouse.
> Since the remote appspot server is broken and unlikely to be fixed
> anytime soon, now is the best time to finally resolve the remote
> modules question.
>
> Therefore, we remove support for remote modules from the `module.json`
> files and `Runtime.js`. Additionally, we update the build system
> to properly generate the required files and load them via ES modules.
>
> We will be able to perform subsequent cleanups in the Runtime to remove
> more infrastructure related to scripts/remote modules, but given that
> this CL is already quite large we are doing that in a follow-up CL.
>
> Follow-up action items for the LightHouse folks are to further decrease
> the bundle size for LightHouse. Since we are now loading it via ES
> modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> well. This allows us to remove the copy of the SDK files, as well as
> make use of proper ES exports, rather than the browserified requires.
>
> R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
>
> Fixed: 1128890
> Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
LightHouse is currently broken in Canary, because of problems with
the appspot server. This isn't the first occurrence of this problem
and it becomes increasingly more difficult to figure out why the
server keeps on breaking. This is combined with a large infrastructure
cost of supporting remote modules and a confusing debugging experience
when working with it locally.
The reason we had remote modules was the fact that these modules are
too large to be included in the Chromium bundle. In the last months,
we have made numerous remote modules bundled, by applying minifications
and optimizations to each module.
The remaining remote module that we are currently shipping is LightHouse.
Since the remote appspot server is broken and unlikely to be fixed
anytime soon, now is the best time to finally resolve the remote
modules question.
Therefore, we remove support for remote modules from the `module.json`
files and `Runtime.js`. Additionally, we update the build system
to properly generate the required files and load them via ES modules.
We will be able to perform subsequent cleanups in the Runtime to remove
more infrastructure related to scripts/remote modules, but given that
this CL is already quite large we are doing that in a follow-up CL.
Follow-up action items for the LightHouse folks are to further decrease
the bundle size for LightHouse. Since we are now loading it via ES
modules, we can now use ES imports in the `devtools-dt-bundle.js` as
well. This allows us to remove the copy of the SDK files, as well as
make use of proper ES exports, rather than the browserified requires.
R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
Fixed: 1128890
Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This refactors away the cachedResources from an object map
to a normal Map as defined in `Runtime.js`. The Map is used during
boot time by setting the relevant stylesheet contents, which is
included by `build_release_applications`. Moreover, it moves the
`*_module.js` files into the `modules` array rather than scripts.
This ensures that `*_module.js` files can use ES imports.
In a follow-up CL, we can do additional cleanup in the Runtime
to stop retrieving `resources` in `_loadResources`, as that should
no longer be possible. (In both debug and non-debug we build the
appropriate `_module.js` files)
R=aerotwist@chromium.org,aerotwist@chromium.org
Bug: 1058320
Change-Id: I89602b332360338f5914038f6cd505f75b531f8e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2398829
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
While we implemented this check for `devtools_module` and
`devtools_entrypoint`, we did not do so for `devtools_pre_built`.
This caused build failures yesterday when we forgot to add the
live directive of lit-html in the GRD files.
Therefore, implement the same check for `devtools_pre_built`. This
not only catches the live directive file missing, but also found out
that the imports for Acorn were using the wrong version. We use the
`.mjs` bundles from Acorn, not the `.js` versions.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Bug: 1126630
Change-Id: I54004efda6fb0ac50f894262f09fe2104d1b2f86
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2403322
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
When TypeScript writes to pre-existing files, it will overwrite the
contents, but it won't create a new file per se. If files in gen/ were
previously created by devtools_pre_built they will be hardlinked to the
original source file, thus any changes tsc makes to the file in gen will
be reflected back to the source. This causes an issue with ninja, since
it believes on the next run that the source file has changed.
This CL updates the behavior of devtools_pre_built such that it no
longer calls gn's copy, but rather a node utility that ensures that
there is a freshly minted copy of the file rather than a hardlink.
Change-Id: I11a23fce764101eb237e434a64159223ef8d700e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2335277
Auto-Submit: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Inside of devtools_entrypoint we use gn's copy command. This generates
hardlinks, which can sometimes mean that incremental builds get into a
broken state. This CL changes those copy commands over to being node
actions that ensure the files are copied rather than hardlinked, and it
also unlinks files before writing them (if they exist) to prevent the
case where hardlinked files are overwritten.
R=jacktfranklin@chromium.org
Change-Id: I86a1f351780afc3ac725c690866b4ac9dd649fd1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2335056
Auto-Submit: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
I had a bad gn file and running the cross-reference script didn't show
that but instead treated it as if gn knew of no dependencies and
therefore gave me a huge output of JS files that were not declared as gn
deps.
If the script gets an error, it should bail and log that error rather
than treat it as if there were no gn deps found.
Change-Id: I5672e97581659836adbf2fc1aa4fc5f837b78835
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2317308
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
It is possible for TypeScript to import a file that is not included in
the corresponding devtools_entrypoint as a dependency. In many cases
this would likely cause the build to fail, but it's also possible that a
dependency might have been provided as a dep of another entrypoint.
Given that ninja parallelizes builds this results in a race condition
where on some builds the dependency that wasn't declared is there, and
on some builds it is not. This is further complicated if build artifacts
from previous builds are kept around.
This CL introduces a script that can be run manually that cross
references the files that GN knows about, and the files that TypeScript
expects to be able to import. Any files expected by the TypeScript
compiler that are not declared in the BUILD.gn (even indirectly as a
dep of a dep etc) will be flagged.
Change-Id: Ieb95600f11bfc20e0e71d8792a7f344b13a0fb8e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2316063
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
The internal ninja copy action is, for Linux and Mac, the creation of a
hardlink. In the case of an is_debug = false build, we copy the
devtools_entrypoint file with ninja to the gen folder. However, should
the file then change in the gen folder, those changes will be reflected
back in the original source file since the two are hardlinked. This does
happen when the JavaScript file moves to being managed by the TypeScript
compiler, for example, because tsc often changes blank lines and adds
sourcemap information to the file. If the gen folder is empty and no
hardlink exists prior to build, there are no issues. If, on the other
hand, the hardlink exists, and the TypeScript compiler runs, the file
written in the gen folder will update, and then so will its original
source.
The ways to resolve this reflection back to the source folder is either
by deleting the gen folder before rebuilding (where one anticipates
changes being reflected in source), or, instead of using the ninja copy,
using an action to call out to a script that will ensure that a new file
is created and not hardlinked.
This CL chooses the latter path.
Change-Id: Id2cc8acdc240eb73ac736ddaf6f1eabdd08f8359
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2308534
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Tim van der Lippe