Build infrastructure

[tomasaschan]

This is just a Hello World project with an entry point console app, a library to contain the actual implementation, and a test project, to have something to evaluate the test project against.

Todo:

• Hello world project
• Manage dependencies with Paket
• Fake script for orchestration
• GitVersion for semantic versioning
• Linux support (probably easiest to be inspired by the SAFE example
• Hook up with CI servers (e.g. Travis for Linux and Appveyor for Windows, but suggestions/opinions are welcome)

Maybe out-of-scope:

• Decide on a name for the project (current working hypothesis is FSharp.Project.FileOrderer, but that could definitely be improved)

[tomasaschan]

I'm struggling a little with getting Fake working on my machine

I have installed with choco install fake -pre, and created a script file with the contents listed [here]: http://fake.build/fake-commandline.html

fake --help works fine, but fake run ./build.fsx fails with build errors in the script

-> Compilation failed:
  D:\Code\F# Foundation\AProjectHasNoName\src\build.fsx (10,15)-(10,20): Error FS0039: The value or constructor 'trace' is not defined. Maybe you want one of the following:
     Trace
     TraceData
     TraceMessage
  D:\Code\F# Foundation\AProjectHasNoName\src\build.fsx (11,22)-(11,27): Error FS0001: Type mismatch. Expecting a
      'Target.TargetParameter -> unit'
  but given a
      'unit -> 'a'
  The type 'Target.TargetParameter' does not match the type 'unit'

I assume the problem is that the references aren't resolved correctly, but I can't find any information on how to restore/build a script - how do i get this going?

[forki]

usually you install FAKE with paket as repo level package. Something that's still missing from new NuGet ;-)

Anyway cool start!

[forki]

https://github.com/SAFE-Stack/SAFE-BookStore might be a good thing to copy.
It has build.sh and build.cmd that use paket restore and start the FAKE build.

[forki]

please remove the pinned versions from the dependencies file. usually only the lock file has the pins.

[forki]

BTW: Thanks so much for doing the first step!

[forki]

nice progress. pinging @matthid to take a look at the FAKE 5 stuff

[matthid]

I think you are mixing up FAKE 4 and FAKE 5 APIs, also you no longer use the FAKE nuget package. You can get rid of the FAKE header by annotating a group in paket.dependencies. Please let me know if this was too short ;)

[tomasaschan]

I think you are mixing up FAKE 4 and FAKE 5 APIs

Probably :) Any specific points I should be looking at? (It's probably easier to nip it in the bud while the build script is small...)

you no longer use the FAKE nuget package. You can get rid of the FAKE header by annotating a group in paket.dependencies

Would you mind elaborating on this, and/or link to some docs on how to do it correctly? I'd love to learn!

[tomasaschan]

The bash build script works under WSL, because WSL can run windows executables natively (yes, it's black magic, but it works!). I don't have an environment with mono available, so I can't test whether it works there; anyone who can is welcome to run ./src/build.sh --use-mono from the project root to verify that it works as intended.

Also, @forki, I'm not sure I understand how this section of the SAFE build script; it sets an $OS variable if it's not already set, but I don't have an environment in which it is... Under what circumstances is that variable set to Windows_NT?

[tomasaschan]

This seems to work sufficiently well with Appveyor now, for building and testing on Windows; see https://ci.appveyor.com/project/tlycken/aprojecthasnoname for the latest build log.

That log is obviously hooked up to my fork; a maintainer of this project will have to sign into Appveyor and enable it for this project for it to start working here. (There is also, probably, stuff we can do in terms of build status reporting back to GitHub that I haven't implemented.)

[tomasaschan]

Now, Travis-CI is active (also for my fork) building on Linux here: https://travis-ci.org/tlycken/AProjectHasNoName. Not sure why the builds are queued for so long before they start, but it's bed-time here in GMT+1, so I'll have to wait and see tomorrow if everything actually works 😅

But, barring build failures on Travis, we're ready for serious review! 🎉

[forki]

Let's default to trust. I promoted you to maintainer so I hope you can set up appveyor and Travis. ;-) #13

[forki]

I think we can ignore that weird part of the bookstore script for now. I have no memory of it. I assume some contributor had issues on their machine or it was to get phantomjs working on windows or something.

[forki]

Please also change the readme "tools" section and add the tools that you have selected. Links to the corresponding websites may be useful as well. Thanks

[forki]

This looks very very good!

One thing I'd personally like to see (maybe in later PR) is a releasenotes.md document and extraction of the version and release notes from there. The bookstore build script should have that as well.

But let's get started with this here.

[forki]

Would it be possible to use build.cmd instead? Or additionally? I have couple of machines where Powershell is disabled for some reason.

[tomasaschan]

Sure, no problem.

[tomasaschan]

Let's default to trust.

I like it! :)

I think we can ignore that weird part of the bookstore script for now. I have no memory of it. I assume some contributor had issues on their machine or it was to get phantomjs working on windows or something.

After looking around, the most likely reason to have that seems to be Cygwin environments, possibly in combination with non-default shells (e.g. zsh or dash, as mentioned in comments). Since WSL is available on Windows, and there's a separate flag to decide whether to use mono, I'll just remove that.

Please also change the readme "tools" section and add the tools that you have selected.

Will do.

One thing I'd personally like to see (maybe in later PR) is a releasenotes.md document and extraction of the version and release notes from there.

Yeah, I deliberately left everything related to packaging and releasing out of this PR. We obviously have to think about what artifacts to expose, how to package them and where to publish them, and we should also discuss when to release a new version (with or without a pre-release tag). I've seen both "I pushed a tag to the repository" and "I filled in the Create Release form on the GitHub website" as "create release" actions, and I'm fine with either, but the workflow for release notes etc needs to be different depending on what we choose.

Also, we need a name :)