Chromium build and symlinks outside src

[Igor Bukanov]

Hi,

I would like to understand if using symlinks pointing to directories outside Chromium src in a customised Linux-specific Chromium build asks for troubles. So what is more closer to the reality:

A. While using a symlink may work in some cases with particular Chromium release, no efforts will be put toward keeping it so. Chromium may even accept changes to the build that explicitly break such usage.

B. While using symlinks pointing outside src can be useful, Chromium does not test for such configuration so things may stop working as the code evolves. However fixes to make such links to work again will be accepted and in general such usage will not be explicitly broken.  

So is it A or B?

Regards, Igor

[Dirk Pranke]

Hi Igor,

You're asking a good question, one that I don't think we have an official policy on.

In general, we only support stuff that the project itself directly uses. E.g., we don't accept patches to code to fix a FreeBSD port because we don't support FreeBSD or ship a Chrome binary on it. Patches to infrastructure (build files, etc.) are a bit more supported though we would probably still officially only support them if we used them. 

But, I know that there can be real advantages to having your build artifacts be "out of tree" and could see a world where we did want to use and support such a configuration directly. 

And, on the third hand, I can also imagine that there might be cases where we would accept a patch that explicitly broke symlinks because we really needed whatever was being changed and viewed it as an acceptable tradeoff, but I don't know if those would actually be a real world scenarios.

I would be reluctant to say much more without looking at real changes and understanding their impact. I hope this helps a little, even though I realize it doesn't resolve your question one way or another.

If you had a concrete proposal for how to enable such a configuration (and why that configuration is useful), I would certainly be happy to look at it.

-- Dirk 

--
--
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/cae3abad-e25e-46f9-a262-28f6cf053643n%40chromium.org.

[Bruce Dawson]

We do have at least some support for symlinks in Chrome's build - the clobber functionality recently had some fixes made to better support this. crrev.com/c/4173494

[Jakob Kummerow]

Empirically: Every now and then I compile Chrome with src/v8 being a symlink to a separate standalone V8 checkout. In the past couple of years that's been working without issues. (Previously there was a time when it didn't work, many years ago.)

[Igor Bukanov]

Hi,

As regarding usefulness of symlinks consider that projects that use a patched Chromium typically have an extra repository for own files. This allows for most of the changes to go to a small (well, at least much smaller than Chromium) and quick repository. Some even goes as far as not committing anything to Chromium repository, but store the changes to Chromium source files in own repository (typically as patches) leaving Chromium repository pristine and applying the changes during the build.

Then a natural layout for the project with own main repository is to have Chromium checkout either as a subdirectory or as a directory in the parent directory of the main project. But then the question arises of how to refer to files outside Chromium. Symlink like //project-name placed under src is a natural solution for that. This is even true for projects that target Windows. Windows 11 does not require administrative privileges to create a symlink and Windows 10 can be configured to allow for unprivileged processes to create a symlink.

But presently symlinks do not work at least for Grit files. Given the unclear status of symlink support some projects opted to require to fetch Chromium first and then place own main repo as a subfolder of Chromium/src. A variation of that is to have an umbrella repository with a script to fetch depot_tools, Chromium src and then fetch the main repo under src. But this is a rather awkward arrangement when the main project repo contains files not related to Chromium.

So it will be nice if Chromium build would support at least symlinks to a directory from the top level. I.e. having a full support for //foo as a symlink pointing to a directory outside src will be nice. There is no practical need to support symlinks to individual files or from directories not at the top level.

Regards, Igor    

[Dirk Pranke]

Your first use case (where Chromium is part of a larger checkout) is a good example of something that we'd be disinclined to support since we wouldn't use it ourselves. This is definitely not the first time this particular usage has been raised and we've always been very reluctant to go out of our way to enable it.

For the second issue (grit), I think the main reasons we wouldn't have supported it historically would've been that the underlying platforms support for symlinks (as you've mentioned) and IMO also because the interactions of symlinks and a version-controlled directory tree can be confusing. But, I'd probably still not be eager to support this since I don't know of a situation where we'd use them and they'd be a good idea for us.

I guess based on my replies above that I would in fact take a stance closer to A than B, and say that you're asking for trouble.

That said, I still stand by my last two paragraphs of my reply. If your use cases could be done with very minimal impact on the code base (and particularly if it solved some problems in a cleaner way than what the code does today) I'd consider it further. I'd probably also want to discuss the changes with other build (and perhaps project) owners, since I'm definitely not the only voice that matters here.

-- Dirk

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/58e9c337-3967-423a-a866-d15ac4d92f3fn%40chromium.org.