Cross compiling doesn't always use the correct settings for subrepos.

[cemeceme]

When cross compiling, the wrong settings are getting used for subrepos sometimes. I haven't been able to create a minimal environment that reproduces this behavior unfortunately.

What I can say so far is:

• The wrong settings seem to be used in some subrepos but not the root project.
  • However it may also be dependent on how the subrepo gets included. I.e. local_repository vs github_repo.
• In build.log, the labels using the wrong settings still correctly contain an @<architecture> tag.
• The settings in question is from a plugin.
• The issue is deterministic: it is always the same subrepo with the same plugin settings that are incorrect.
• Any .plzconfig_arch or .plzconfig files in the subrepo get ignored, using the plugin default instead.
  • Overriding in the root .plzconfig does have an effect, but the root .plzconfig_arch does not.
  • However, a different plugin in the project uses the root configuration or its own config for the target arch with no problems.

Also, I would like to mention that there doesnt seem to be any documentation specifying how settings should be overridden. Should subrepo settings be ignored entirely, be overrideable or be the definitive settings for that subrepo? Some detail on this would be useful since there are some other inconsistencies regarding this topic too.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity in the past 90 days. It will be closed if no further activity occurs. If you require additional support, please reply to this message. Thank you for your contributions.

[cemeceme]

test.zip

I believe I have figured out a way of reproducing the issue. It seems to be a race condition as well, since the example I'm providing seems to randomly output the bug.

To reproduce the bug, run ./pleasew build --arch=test_arch //:testFile ; ./printFiles.sh in the given please project. The output will randomly show that "Content for subrepo1File" and "Content for subrepo1File for Arch" is either (correctly)RootArchString or (incorrectly)--std=c++11 -O3 -pipe -DNDEBUG -Wall -Werror.

For reference, this is the setup:

• A subrepository
  • Contains a rule using a build command that uses a plugins configuration value.
    • I'm not sure if it HAS to be a plugin, or if it can be one of the built-in configuration values.
    • I believe that the given config value has to have a default value defined by the plugin.
  • Contains a .plzconfig file that only defines the plugin, but does not set any config values.
  • Contains a .plzconfig_someOS_someArch file that overrides the plugin config value.
• A root repository
  • Imports the subrepository, so it is available to its own rules.
  • Contains a rule, which depends on the previously mentioned rule in its deps AND tools.
    • This way the subrepository rule needs to be set up twice, once with the target architecture and once with the current architecture.
  • Contains a .plzconfig file that defines the plugin, but does not set any config values.
  • Contains a .plzconfig_someOS_someArch file, that overrides the plugin config value. Then finally, the root repos rule is built with the --arch=someOS_someArch argument, and the output will randomly use the root override or the plugin configs default setting.

It should also be noted, that depending on the build order, one or the other state may be achieved consistently. For instance, one of my large projects using please will consistently exhibit the bug.