You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can imagine some cases which could lead to an invalid file ordering for an fsproj file but I'm curious if I'm understanding the main motivation for attempting to a brute force method for finding a valid project ordering from an existing project.
Here are the cases I can dream up:
As a developer using and IDE that does not support file re-ordering I add a new file which adds the new file in an incorrect order.
As a developer who has made a change a .fs file to depend on a file that comes later in complication order according to the current fsproj file I need to move that dependency so that it precedes the file that now depends on that one being moved.
As a developer who has been working with an F# compiler tool chain that does not us fsproj but instead some other way of feeding the files in with a specific order I want to generate an fsproj file or correct the implied ordering created by some tool which may have generated the fsproj file.
As a developer who would like to take advantage of the new ability for .NET project files to not have to explicitly declare individual file references but need to satisfy the need for explicit file ordering for F# projects and would like some automatic tooling to make this less painful.
From my perspective it would seem to me that cases 1 and 2 would be the most common and would be facilitated through support for just simple explicit position translation commands either exposed through the library to the IDE or through the CLI.
The case for 4, if it even exists in the wild, seems far less regular as it should be inherently a onetime activity per project at most and may only happen in cases where existing projects are migrated to fsproj or from an older version to a new version.
As for case 5 it's not clear to me how or if this project would solve this issue as it sounds to me that the proposal is to still modify the existing fsproj file to include explicit file references to dictate compilation order. I personally have noticed the benefits of the single-pass style compilation in F# and I hear from many others who feel the same way so it's not clear to me how or if this would be a goal but I wanted to list it for completeness.
So as one may be able to see is that from the cases listed above it's hard for me to understand the significance of the value for determining a valid file compilation order from an arbitrary set of F# files or an fsproj in comparison with some of the other stated goals for providing a consistent CLI and library interface for modifying file order for fsproj files. Likewise the former seems at a glance much more complex and resource intensive without as much bang for the buck in comparison to the later. I'm hopeful that somebody can set me straight though and clarify some points I may have gotten wrong or gaps in my general understanding and perhaps this can help formulate some material that can help guide the improvement of the documentation for this project to state the goals and the problems that it addresses.
The text was updated successfully, but these errors were encountered:
jpierson
changed the title
What are the actual useer stories and personas involved with encountering existing fsproj files with invalid ordering?
What are the specific problems that exist that this project is attempting to solve?
Jan 4, 2018
A problem that occurs when moving a file up or down is that more often than not you have to move some dependent files as well. I'm working with F# since it came out, and I think these cases are rare, but they do exist. Having an algorithm that "understands" the task will provide value.
I can imagine some cases which could lead to an invalid file ordering for an fsproj file but I'm curious if I'm understanding the main motivation for attempting to a brute force method for finding a valid project ordering from an existing project.
Here are the cases I can dream up:
From my perspective it would seem to me that cases
1
and2
would be the most common and would be facilitated through support for just simple explicit position translation commands either exposed through the library to the IDE or through the CLI.The case for
4
, if it even exists in the wild, seems far less regular as it should be inherently a onetime activity per project at most and may only happen in cases where existing projects are migrated to fsproj or from an older version to a new version.As for case
5
it's not clear to me how or if this project would solve this issue as it sounds to me that the proposal is to still modify the existing fsproj file to include explicit file references to dictate compilation order. I personally have noticed the benefits of the single-pass style compilation in F# and I hear from many others who feel the same way so it's not clear to me how or if this would be a goal but I wanted to list it for completeness.So as one may be able to see is that from the cases listed above it's hard for me to understand the significance of the value for determining a valid file compilation order from an arbitrary set of F# files or an fsproj in comparison with some of the other stated goals for providing a consistent CLI and library interface for modifying file order for fsproj files. Likewise the former seems at a glance much more complex and resource intensive without as much bang for the buck in comparison to the later. I'm hopeful that somebody can set me straight though and clarify some points I may have gotten wrong or gaps in my general understanding and perhaps this can help formulate some material that can help guide the improvement of the documentation for this project to state the goals and the problems that it addresses.
The text was updated successfully, but these errors were encountered: