In regards to the virtue of cheating the F# project system
Cheating is bad - right? But what if this is the only option available? As you may or may not know the project system shipped with F# compiler imposes limits on theВ compilation orderВ for the files in non-flat directory structure. Look here for the explanation.
I was looking for a way to squeeze by this limitation and here is what I found out: all this strictness is only enforced when
- The project is being loaded.
- project elements are added or renamed.
In particular these rules are not validated or enforced when the project is compiled. So the solution I came up with is to give the F# project manager something it can live with and when it is happy with what's provided and looks the other way rearrange the elements in the project file in the order I want them to be. If I do that I can use my custom compile order dialog to arrange the compilation order any way I want - for as long as the F# project manager looks the other way.
When the project is saved it has to be brought back to the state compatible with the F# project manager, otherwise it will refuse to load it next time around. So I intercept the onAfterProject close event and reorder project elements to comply with the F# project manager demands. While doing so I decorate the elements I move with custom XML elements to preserve the information how should I move them back to restore the (non-compliant) order of the files.
I also have to be on the lookout for F# project manager turning its attention to the build file element order. When it is about to happen I will have to adjust the element order in the build file to F# project manager liking, and it turns its back on me again I will have to move the items back.
That's the plan at the moment, let's see how far it's gonna take us.