Hello,
I'm looking to build a project out-of-source-tree. This project uses cefglue as a submodule, and cefglue is accordingly in a subdirectory. With MSBuild, the best practice for building a project out-of-source-tree appears to be to use a Directory.Build.props file when taking nuances into consideration, overriding $OutputPath and other logic. The problem is that cefglue doesn't respect this user-supplied Directory.Build.props file as cefglue already has one checked into source control, and won't be built out-of-source-tree.
MSBuild (via Microsoft.Common.props logic) searches up the filesystem for Directory.Build.props and includes the first one it finds, if one exists.
Looking at the documentation, Directory.Build.props appears to me to be a user-supplied file, much like the .user file, which should not be checked into source control as it is intended for user-specific customization, even though it will technically work if checked into source control anyway.
I propose refactoring the contents of cefglue's Directory.Build.props and Directory.Build.targets into a differently named .props and .targets file, and including those in each .csproj and .shfbproj. My question is: would this be acceptable for this project for me to submit a patch to do so? Unfamiliar with this project I do not know the technical reasoning Directory.Build.props was used in the first place, and there may be good reason, and I do not know of all other implications like a maintainer would.
If that is not acceptable, then would a patch be accepted to cefglue's Directory.Build.props to replicate the logic in Microsoft.Common.props, to again search up the filesystem for another Directory.Build.props and include it if one exists?
If neither are acceptable upstream, I will seek to put the patch in the fork.