-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subrepositories and plugin settings inherited from root #3005
Comments
The plugin settings are either inherited from the host repo, or overridden by the subrepo. This is defined by the plugin e.g. This means that we will use the flags as defined in the host repo. I think this is probably what you want most of the time, because these flags can be dependant on the toolchain you're using. Maybe we need another config option called |
As a workaround for this issue, I've been doing something similar to this :
This create a BUILD file for the subrepo that will override every config keys first and then do the actual work, you can even completely remove PluginDefinition from .plzconfig I still get this bug #2943 though |
Sorry for the late response. The issue I'm facing is that I have transient plugins that need different settings for other plugins. In my case, I have a c++20 project, which depends on 2 other c++ projects using please. Namely, a library I wrote & mysql-connector-cpp (I wrote a diff file to add please support for it). Further issues arise as mysql-connector-cpp also provides a modified version of the protobuf compiler, so even though any projects that depend on it should not care, they still have to define the please proto rules and their arguments in the root While something like If it helps, I can also look into creating a public repo for the patch file I made for mysql-connector-cpp, though right now it only adds the minimum required please support to it (I have not tried to dynamically generate version strings etc. that their current cmake setup does). |
This is not a specific issue and more of a general overview of the issues I have been having about subrepositories.
I think this is best described by an example:
Suppose I have a repository
A
which depends on pluginC
andD
as well as another please repositoryB
.Repository
B
also depends on pluginC
, but has different settings set in it's.plzconfig
file.B
also depends onD
, however, it compiles the tool thatD
uses internally and uses that instead of the default thatA
would use.Finally,
B
also depends on another pluginE
.From my understanding, currently please will ignore any
.plzconfig
settings that are not in the root project, with the exception of definitions inPluginDefinition
tags. This means that in this example, repositoryB
will inherit the same settings for pluginC
as the root repositoryA
. The same would also go forD
, but now repositoryA
has to know about the rule that builds the internal tool executable. As far as I can tell, there is no way to override settings for other plugins, to e.g. specify a different set ofDefaultOptCppflags
forcc_rules
.I have come across "test/plugins/nested_subrepo" in this repo, that seems to address this partially, but again, it provided no hint as to how to specify settings for other plugins that should not get overridden or handled differently.
Finally, it also appears that the tool
E
in our example also doesn't end up working as all plugins appear to need to be defined in the root repositoryA
. The only mention of having to list transient dependencies like this seems to be in the documentation page "Third-party dependencies/Comparison to other systems" where it reads: "If you're coming from Gradle or Maven, it's a little more alien due to being less language-specific and requiring full transitive dependencies to be specified.". However, I am not sure if this is actually in reference to this behavior.To put this all as a single paragraph issue:
One cannot use subrepos as you would a library unless your root build environment matches closely enough to that of the subrepo, including things like warning flags. That is, unless I am mistaken and the documentation does not give adequate information on how to achieve configurable libraries using
.plzconfig
files.The text was updated successfully, but these errors were encountered: