PSA: Code in //chrome/browser/chromeos moving to //chrome/browser/ash

[James Cook]

FYI for people working on Chrome OS code in chromium git....

The Lacros project is extracting a new "lacros" browser binary from the existing "ash" system UI + browser monolith on Chrome OS (overview docs). Both binaries are built out of the chromium source tree. To make it clearer which code runs where, we've moving code that only runs in the "ash" binary out of "chromeos" directories (design doc).

So if you're looking for code in //chrome/browser/chromeos and it isn't there, look in //chrome/browser/ash. :-)

James

on behalf of the Lacros team

[Colin Blundell]

Hi James,

I don't seem to be able to comment on the doc.

I saw that you considered moving this code out of //chrome entirely but got eng review feedback that led you to move it to //chrome/browser/ash. What was the feedback? Very naively, it seems that code that runs only in the Ash binary shouldn't need to live in //chrome. Likely there are lots of sad reasons that it would need to do so currently, but in the long-term, is what I just stated a goal? i.e., //chrome doesn't contain code that's only for the Ash binary.

Thanks,

Colin

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAKLzqjGRweoj3JWNg-v_%3DyhZ2fe4rzrbFEE%2BsjnfbMM%2Bh9KUTw%40mail.gmail.com.

[Dominic Mazzoni]

I had a similar question. I guess I'd like to better understand the difference between //ash and //chrome/browser/ash now - maybe both (1) what the split is today, and (2) ideally when refactoring is finished what it should be. Something along the lines of the content module documentation would be helpful - I recall jam@ had a good explanation of what the split should look like long before it was actually finished.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NHU-6D3fdJX-65BKfxU4m%2B0sPGwM3DvNyn0RG0zH9mfTQ%40mail.gmail.com.

[James Cook]

Here's the internal-only thread. Briefly, I proposed moving //chrome/browser/chromeos => //ash/browser. This would require //ash/browser to depend on //chrome/browser. Eng review pointed out that our top level product directories (chrome, android_webview, chromecast, headless, weblayer) are leaf nodes and said they shouldn't be depended on by any other directory. So we end up with //c/browser/ash.

Removing those dependencies on //chrome/browser is probably SWE-decades worth of work. The ideal end state would be that //ash contains everything for the ash binary and has no dependencies on //chrome. It would be even better if it didn't have //content deps. But both of those refactors are out of scope for Lacros.

Briefly, the distinction between //ash and //chrome/browser/ash is "stuff in //chrome/browser/ash has unavoidable dependencies on //chrome/browser or //content."

I'll open up the doc for comments from chromium.org.

[Colin Blundell]

That makes sense, thanks. I left a few minor comments on the doc.

So to make sure that I'm understanding: the ideal loooong-term end state would be that //ash becomes a "top-level product directory" for the ash binary, but as far as the scope of Lacros goes //ash is a support library (like e.g. //ui) and the ash binary is built out of //chrome.

Best,

Colin 

[James Cook]

On Fri, Jan 15, 2021 at 7:08 AM Colin Blundell <blun...@chromium.org> wrote:

That makes sense, thanks. I left a few minor comments on the doc.

So to make sure that I'm understanding: the ideal loooong-term end state would be that //ash becomes a "top-level product directory" for the ash binary, but as far as the scope of Lacros goes //ash is a support library (like e.g. //ui) and the ash binary is built out of //chrome.

Correct.

With lacros, we have two binaries:

* lacros-chrome, built out of //chrome, does not contain //ash, just a browser

* ash-chrome (the existing "chromeos chrome") - built out of //chrome, contains //ash, no change from today. It's either a browser with a built-in window manager, or a window manager with a built-in browser, depending on how you think about it.

In a post-lacros future, we would love to remove the //chrome bits from ash-chrome. Then //ash would be a "top-level product", and the binary would be much smaller than it is today.