20 votesKevin Ransom commented
I’m afraid this proposal does not resonate with me. It has a number of deficiencies in my opinion:
1. It repeats information stored elsewhere in every other build system:
• Fake specifies a source file ordering
• Msbuild projects specify source file ordering
• Project.json specifies a source file ordering
2. For a loose collection of F# files in a directory this ordering needs to be specified anyway and so the scenario we are trying to address is not really addressed, I think project.json is as good a way to specify it as an F# file as any
3. I agree with Jared that specifying a source files requirements is a more natural, and source code reuse friendly mechanism for specifying dependencies.
4. A project file can contain a file with the same name in two different directories and so the dependency will need to be path qualified again making the file less friendly in reuse scenarios
5. We already have a model for script files based on #load … this is not aligned with that approach.
• I actually prefer #requires “foo.fs”, and a topological sort, it certainly degenerates in to a form that satisfies this proposal, although there is a preprocessing step that requires opening and reading all of the files which will slow down builds a tad. We can also allow #requires to be a synonym for #load allowing script files to build correctly.
6. I also think that we can probably write a tool that integrates with the dotnet new that reads the source code for loose files and looks at type dependencies and open statements and performs a topological sort that will work. Because it is just a tool, it wouldn’t pollute the compiler and would only run on dotnet new, or when other tooling invoked it.
And so …
I think we need to either :
1. Do nothing … require developers to specify file ordering in project.json
a. Perhaps write a tool
2. Or add #requires “foo.fs” and do a topologival sort to specify dependencies.
39 votesKevin Ransom shared this idea ·