Add basic support for CMake configuration and build

[bbenoist]

Description of the wrapped tool:

CMake, is a cross-platform, open-source build system. CMake is a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice.

See the official website for more information about CMake.

Features:

• Configure and build any CMake project with FakeLib's CMakeHelper.
• Supports the most used CMake option switches.
• Strong CMake variable declaration to avoid conversion issues.
• Executable search algorithm working on both Windows and Unix.
• Toolchain file support.
• Setting unwrapped CMake arguments manually remains possible.
• Setting CMake arguments manually remains possible.

It has been tested on both Windows (with VS 2012 and 2013) and the Ubuntu/Vagrant box (g++) using a simple C++ project.

[bbenoist]

@forki The CMakeHelper generated documentation includes two F# examples which does not seems to be colored by FSharp.Formatting. I did not find a way to fix it 😢

[bbenoist]

@forki I have tried to add a specific unit-test for CMakeHelper but strugle at determining what is the best way to do so.

Here is a brief desciption of what's expected:

Requiremed file system at runtime

Here is the file system which should be present at runtime

|-- <optional-directory-structure> // CMake does not requires a structured relation between the build and source directories.
| |-- CMakeTest // A directory containing some source code to be built with CMake.
| | |-- CMakeLists.txt
| | |-- main.cxx
|-- <optional-directory-structure> // CMake does not requires a structured relation between the build and source directories.
| |-- CMakeTest-Build // Created by `ensureDirectory`. This is the directory containing every file generated by CMake and the build tools it manages.
| | |- <generated-files>

Required build tools

In order to execute the routines of CMakeHelper, the following tools should be available:

• CMake: Not available on NuGet but a portable package is available on Chocolatey under the name cmake.portable.
• A native build instructor: Visual Studio 2013 (the same version as FAKE) on Windows and GNU Make on *nix.
• A C++ compiler: Detected by CMake, can be MSVC on Windows and g++ on *nix

Example test

At best, the test should be something like the following:

let sourceDir = "./CMakeTest"
let buildDir = "./CMakeTest-Build"
CleanDir buildDir
ensureDirectory buildDir
CMakeGenerate (fun p ->
    { p with
        SourceDirectory = sourceDir
        BinaryDirectory = buildDir
        Generator = if isUnix then "Unix Makefiles" else "Visual Studio 12 2013"
    }
)
CMakeBuild (fun p-> {p with BinaryDirectory = buildDir})

Any opinion about this?

[forki]

Hi,

thanks for contributing.

Integration tests are very hard to do. If you are going to use this stuff in production then I don't think you need to provide such tests. I will always ask you before I merge changes on this.

[forki]

please remove the AutoOpen

[bbenoist]

OK, I was not aware that some modules are not auto-opened because of their low-usage... As FAKE scripts tends to hide as most F# specifics as possible ("It is using an easy domain-specific language (DSL) so that you can start using it without learning F#."), I believed that removing the need for specifying any module name was a design choice.

As not auto-opening CMakeHelper forces end-users to explicitly use the module name at each function call, I would like to rename:

• CMakeHelper into CMake
• CMakeGenerate into Generate
• CMakeBuild into Build

Usages of the helper would be cleaner because of their <Noun>.<Verb> form.

Are you OK with this?

[forki]

Yes that's much better. We try to minimize the autoopens since had name
conflicts.
On May 5, 2015 1:04 PM, "bbenoist" notifications@github.com wrote:

In src/app/FakeLib/CMakeHelper.fs
#785 (comment):

@@ -0,0 +1,286 @@
+[]

OK, I was not aware that some modules are not auto-opened because of their
low-usage... As FAKE scripts tends to hide as most F# specifics as possible
("It is using an easy domain-specific language (DSL) so that you can
start using it without learning F#."), I believed that removing the need
for specifying any module name was a design choice.

As not auto-opening CMakeHelper forces end-users to explicitly use the
module name at each function call, I would like to rename:

• CMakeHelper into CMake
• CMakeGenerate into Generate
• CMakeBuild into Build

Usages of the helper would be cleaner because of their . form.

Are you OK with this?

—
Reply to this email directly or view it on GitHub
https://github.com/fsharp/FAKE/pull/785/files#r29659378.

[bbenoist]

Integration tests are very hard to do. If you are going to use this stuff in production then I don't think you need to provide such tests. I will always ask you before I merge changes on this.

Yes, I intend to use it on production code but only on Windows as the .NET software I am working on cannot work with Mono.
In fact, I already had to make such testing to ensure a working Linux support.
Making it publicly available just takes a me a few seconds but would make people reusing CMakeHelper more autonomous.

Are you OK with adding a dedicated example in the Samples directory instead?

[forki]

Are you OK with adding a dedicated example in the Samples directory instead

yes

[forki]

is this ready to merge?

[bbenoist]

Not yet, French May is filled with holydays this year 😅
It should be OK during the week...

[bbenoist]

@forki I have finished my improvements. You can now merge it if you are OK with its content.

[forki]

very cool. thanks a lot