Handle dynamic OutputPath #942
Conversation
Returns an `XmlNode seq` so that functions in the `Seq` module can be used more easily.
Code is incomplete, as it won't process place-holder values or conditions, but it should find and return the contents of an OutputPath node in the project file's main PropertyGroup.
allykzam
changed the title
Uses a regular expression to find and replace placeholder values. Note that the matches found by the regex need to be processed in reverse order, so that their indexes remain valid.
Rather than using hard-coded values for the OutputPath, use placeholders, so that their handling is tested as well. Project1.fsprojtest contains a single OutputPath node to be used for all build configurations, and should succeed so long as the placeholder replacement is working correctly. Project2.fsprojtest uses a hard-coded OutputPath node for all build configurations, and keeps hard-coded OutputPath nodes for each individual build configuration. This should succeed if the node condition checking is working correctly. Project3.fsprojtest keeps the traditional hard-coded OutputPath nodes for each individual build configuration, and should succeed if the node condition checking is working correctly.
|
Still trying to figure out a way to handle conditions. I've got some code written using Wanting to support a little more of the condition syntax for more complex conditions, all I've come up with so far is a rather complicated regular expression. Anyone else have any thoughts? cc/ @forki: I did get some work done on this :) |
|
nice. did you already look at the red builds? |
|
Yeah. I've gotten either the Release or Debug tests to pass by making changes to the Does a really big regular expression sound like a horrible idea to you? I'll use |
yes ;-) |
|
Sorry for the delay; I kept working at the regex idea, and found that as soon as I add three or more conditions separated by |
|
we had the idea to use FParsec for all parsers. but at the moment there is nobody who wants to build these. |
Currently does NOT handle the `Exists` or `HasTrailingSlash` features, nor grouping of conditions with parens. The MSDN article on MSBuild conditions also makes mention of hex literals, which have not been handled here either. See the following page for more information on these features: https://msdn.microsoft.com/en-us/library/7szfhaft.aspx Line 737 can be changed to `doComp left right` to support performing greater-than and lesser-than style comparisons on strings, but this is not supported by MSBuild.
The provided configuration needs to exist in the default placeholder data, so that if it's provided, the value isn't overridden. If the value is empty, project files typically contain something like this to provide a default value: <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> With this change, all tests appear to pass again, should be the last of the changes needed for #914.
|
Finished working on the code from the gist and built it in, tests are happy now. Is there anything else I should be doing with this before it'll be acceptable for merging? |
allykzam
changed the title
…tpath Handle dynamic OutputPath
|
this looks cool. let's see if it works in the wild wild real world ;-) |
|
|
|
Thanks! I'll change one of my work projects back and give it a go tomorrow morning :) |
|
Looks good from my FAKE script :) |
Partial implementation so far, updates
ProjectFile.GetOutputDirectoryto iterate through everyPropertyGroupnode in the project file loading values. Need to find a nice way to process basic placeholder values (the full supported syntax is a bit expansive for my liking) and theConditionattribute. Should also provide some default values in theMap<string, string>at start, such as thebuildConfigurationvalue.As a side-effect of rewriting this code, I've accidentally corrected how Paket handles project files with multiple
OutputPathnodes. MSBuild appears to process everything top-to-bottom, and so the lastOutputPathnode wins, whereas Paket will currently output a warning and use the firstOutputPathit found.