Merge pull request #1638 from KyrietS/master

Fix broken links in docs

website/README.md

@@ -10,7 +10,21 @@ Editing our documentation website is very simple. You don't have to build a whol
 1. Add a new Markdown file into the `docs/` folder. Follow naming conventions there.
 2. Add your Markdown file's name into the `sidebars.js`. Make sure you've kept alphabetical order among category items.
 
-*Use other files as references.*
+### Adding a reference to another documentation page
+
+Always reference another documentation page like this:
+```markdown
+[some text](Case-Sensitive-Filename.md)
+```
+
+and **never** like this:
+```markdown
+[some text](some-markdown-file)
+[some text](/docs/some-markdown-file)
+[some text](https://premake.github.io/docs/some-markdown-file)
+```
+
+*Use existing files in documentation as examples.*
 
 ## Installation
 

website/docs/Adding-New-Action.md

@@ -8,7 +8,7 @@ Premake provides the ability to create your own actions. These can be simple one
 
 This tutorial walks through the process of creating a new action that outputs solution and project information as Lua tables, which you can then use Premake to read and manipulate if you wish.
 
-* [Starting Your New Action](starting-your-new-action)
-* [Generating Project Files](generating-project-files)
+* [Starting Your New Action](Starting-Your-New-Action.md)
+* [Generating Project Files](Generating-Project-Files.md)
 * Working with Configurations
 * (More to come!)

website/docs/Adding-Source-Files.md

@@ -2,7 +2,7 @@
 title: Adding Source Files
 ---
 
-You add files—source code, resources, and so on—to your project using the [files](files) function.
+You add files—source code, resources, and so on—to your project using the [files](files.md) function.
 
 ```lua
 files {
@@ -24,7 +24,7 @@ Paths should always use the forward slash `/` as a separator; Premake will trans
 
 ## Excluding Files
 
-Sometimes you want most, but not all, of the files in a directory. In that case, use the [removefiles()](removing-values) function to mask out those few exceptions.
+Sometimes you want most, but not all, of the files in a directory. In that case, use the [removefiles()](Removing-Values.md) function to mask out those few exceptions.
 
 ```lua
 files { "*.c" }

website/docs/Adding-Unit-Tests.md

@@ -7,7 +7,7 @@ Premake includes an automated testing system that you can use the verify the beh
 
 ## Add your first test
 
-Within our [Lucky module](introducing-modules) folder, create a new folder named `tests`.
+Within our [Lucky module](Introducing-Modules.md) folder, create a new folder named `tests`.
 
 Within that folder, create a new file named `tests/test_lucky_numbers.lua` with a simple failing test:
 
@@ -43,7 +43,7 @@ lucky/
 
 Premake's automated testing module is considered an advanced, developer-only feature which is not enabled by default. To enable it, you simply need to add the line `test = require("self-test")` somewhere it will be executed before your tests run.
 
-The best place to put it is in your [system script](system-scripts), which will make the testing action available to all of your projects. But if that isn't feasible for you or your users, you can also place it in your project or testing script.
+The best place to put it is in your [system script](System-Scripts.md), which will make the testing action available to all of your projects. But if that isn't feasible for you or your users, you can also place it in your project or testing script.
 
 Premake's own code makes use of the latter approach: its `premake5.lua` script defines a custom action named "test", which in turn enables the built-in testing module:
 

website/docs/Build-Settings.md

@@ -2,19 +2,19 @@
 title: Build Settings
 ---
 
-Premake provides an ever-growing list of build settings that you can tweak; the following table lists some of the most common configuration tasks with a link to the corresponding functions. For a comprehensive list of available settings and functions, see the [Project API](project-api) and [Lua Library Additions](lua-library-additions).
+Premake provides an ever-growing list of build settings that you can tweak; the following table lists some of the most common configuration tasks with a link to the corresponding functions. For a comprehensive list of available settings and functions, see the [Project API](Project-API.md) and [Lua Library Additions](Lua-Library-Additions.md).
 
 If you think something should be possible and you can't figure out how to do it, see [Support](/community/support).
 
 |                                               |                      |
 |-----------------------------------------------|----------------------|
-| Specify the binary type (executable, library) | [kind](kind) |
-| Specify source code files  | [files](files), [removefiles](files)  |
-| Define compiler or preprocessor symbols   | [defines](defines)  |
-| Locate include files | [includedirs](includedirs) |
-| Set up precompiled headers | [pchheader](pchheader), [pchsource](pchsource) |
-| Link libraries, frameworks, or other projects | [links](links), [libdirs](libdirs) |
+| Specify the binary type (executable, library) | [kind](kind.md) |
+| Specify source code files  | [files](files.md), [removefiles](files.md)  |
+| Define compiler or preprocessor symbols   | [defines](defines.md)  |
+| Locate include files | [includedirs](includedirs.md) |
+| Set up precompiled headers | [pchheader](pchheader.md), [pchsource](pchsource.md) |
+| Link libraries, frameworks, or other projects | [links](links.md), [libdirs](libdirs.md) |
 | Enable debugging information | symbols(symbols) |
-| Optimize for size or speed | [optimize](optimize) |
-| Add arbitrary build flags | [buildoptions](buildoptions), [linkoptions](linkoptions) |
-| Set the name or location of compiled targets | [targetname](targetname), [targetdir](targetdir) |
+| Optimize for size or speed | [optimize](optimize.md) |
+| Add arbitrary build flags | [buildoptions](buildoptions.md), [linkoptions](linkoptions.md) |
+| Set the name or location of compiled targets | [targetname](targetname.md), [targetdir](targetdir.md) |

website/docs/Building-Premake.md

@@ -7,7 +7,7 @@ If you downloaded a prebuilt binary package you can skip this page, which discus
 
 ## Using a Source Code Package ##
 
-If you have one of the [official source code packages](http://premake.github.io/download.html), you'll find that project files for a variety of toolsets have already been generated for you in the `build/` folder. Find the right set for your platform and toolset and build as you normally would  (i.e. run `make`). The resulting binaries will be placed in the top-level `bin/` folder.
+If you have one of the [official source code packages](/download), you'll find that project files for a variety of toolsets have already been generated for you in the `build/` folder. Find the right set for your platform and toolset and build as you normally would  (i.e. run `make`). The resulting binaries will be placed in the top-level `bin/` folder.
 
 Skip ahead to the next section to learn more about using the source version of Premake.
 
@@ -31,7 +31,7 @@ call "%VS140COMNTOOLS%\..\..\VC\vcvarsall.bat" # Sets up the necessary environme
 nmake -f Bootstrap.mak MSDEV=vs2015 windows    # For Windows with Visual Studio 2015.
 ```
 
-On other platforms, if the bootstrap fails to build, you will need to have a working Premake executable on your system. The easiest way to get one is by [downloading prebuilt binary package](http://premake.github.io/download.html). If a binary is not available for your system, or if you would prefer to build one yourself, grab the latest source code package from that same site and follow the steps in **Using a Source Code Package**, above.
+On other platforms, if the bootstrap fails to build, you will need to have a working Premake executable on your system. The easiest way to get one is by [downloading prebuilt binary package](/download). If a binary is not available for your system, or if you would prefer to build one yourself, grab the latest source code package from that same site and follow the steps in **Using a Source Code Package**, above.
 
 Once you have a working Premake available, you can generate the project files for your toolset by running a command like the following in the top-level Premake directory:
 

website/docs/Code-Overview.md

@@ -10,7 +10,7 @@ The Premake source code is organized into a few different folders:
 
 * `src/base` contains the core Lua scripts, the code that is used to read and process your project scripts, and supporting logic for the actions and exporters.
 
-* `src/host` contains all of the C language code, logic that either can't easily be written in Lua because of the way it needs to interact with the underlying operating system, or because a Lua implementation would be too slow. We try to keep C code to a minimum and use Lua whenever we can, to enable [overrides and call arrays](overrides-and-call-arrays).
+* `src/host` contains all of the C language code, logic that either can't easily be written in Lua because of the way it needs to interact with the underlying operating system, or because a Lua implementation would be too slow. We try to keep C code to a minimum and use Lua whenever we can, to enable [overrides and call arrays](Overrides-and-Call-Arrays.md).
 
 * `src/tools` contains the adapters for command line toolsets like GCC and Clang. We will probably be migrating these toward modules in the near-ish future as well.
 
@@ -22,7 +22,7 @@ In addition to those general categories, there are a few special files of note:
 
 * `src/_premake_init.lua` sets up much of the initial configuration, including all of the project scripting functions, the default set of command line arguments, and the default project configurations.
 
-* `src/_modules.lua` contains the list of built-in modules which are automatically loaded in startup. See [Embedding Modules](embedding-modules) for more information.
+* `src/_modules.lua` contains the list of built-in modules which are automatically loaded in startup. See [Embedding Modules](Embedding-Modules.md) for more information.
 
 * `src/_manifest.lua` lists the Lua scripts that should be embedded into the Premake executable when making the release builds. There are separate manifests for Premake's core scripts and each embedded module.
 
@@ -39,17 +39,17 @@ Execution starts at `main()` in `src/host/premake_main.c`, which calls into to `
 
 * Once `src/premake_main.lua` has finished, `premake_execute()` calls `_premake_main()`, which located at the end of `src/_premake_main.lua`, and waits for it to return.
 
-At this point, execution has moved into and remains in Lua; [extending Premake by overriding functions and call arrays](overrides-and-call-arrays) now becomes possible.
+At this point, execution has moved into and remains in Lua; [extending Premake by overriding functions and call arrays](Overrides-and-Call-Arrays.md) now becomes possible.
 
-`_premake_main()` uses a [call array](overrides-and-call-arrays) to control the high-level process of evaluating the user scripts and acting on the results. Notable functions in this list include:
+`_premake_main()` uses a [call array](Overrides-and-Call-Arrays.md) to control the high-level process of evaluating the user scripts and acting on the results. Notable functions in this list include:
 
 * `prepareEnvironment()` sets more global variables and otherwise gets the script environment ready to use.
 
 * `locateUserScript()` handles finding the user's project script, i.e. `premake5.lua` on the file system.
 
 * `checkInteractive()` is responsible for launching the REPL prompt, if requested.
 
-* `runSystemScript()` runs [the user's system script](system-scripts), and `runUserScript()` runs the project script found by `locateUserScript()`.
+* `runSystemScript()` runs [the user's system script](System-Scripts.md), and `runUserScript()` runs the project script found by `locateUserScript()`.
 
 * `processCommandLine()` handles any command line options and sets the target action and arguments. This needs to happen after the project script has run, in case it defines new options or modifies the behavior of existing options—a common point of confusion.
 
@@ -59,5 +59,5 @@ At this point, execution has moved into and remains in Lua; [extending Premake b
 
 * `callAction()` passes each workspace, project, rule, and other container to the target action, causing the appropriate result--like generating a Visual Studio project or GNU makefile--to occur. This container iteration is done in `action.call()` in `src/base/action.lua`.
 
-Calling the action, via `callAction()`, is where the interesting part for most people begins. Control now transfers to one of exporters, causing the project files to be written. For more information on how *that* happens, see [Creating a New Action](adding-new-action).
+Calling the action, via `callAction()`, is where the interesting part for most people begins. Control now transfers to one of exporters, causing the project files to be written. For more information on how *that* happens, see [Creating a New Action](Adding-New-Action.md).
 

website/docs/Coding-Conventions.md

@@ -111,4 +111,4 @@ Similarly, instead of implementing the output of a particular section of the pro
 	end
 ```
 
-For an example of how to implement a new feature using these conventions, see [Overrides and Call Arrays](Overrides-and-Call-Arrays).
+For an example of how to implement a new feature using these conventions, see [Overrides and Call Arrays](Overrides-and-Call-Arrays.md).

website/docs/Command-Line-Arguments.md

@@ -2,7 +2,7 @@
 title: Command Line Arguments
 ---
 
-Premake provides the ability to define and handle new command-line arguments from within your project script using the [newaction](newaction) and [newoption](newoption) functions.
+Premake provides the ability to define and handle new command-line arguments from within your project script using the [newaction](newaction.md) and [newoption](newoption.md) functions.
 
 ## Actions and Options
 
@@ -12,7 +12,7 @@ An _action_ indicates what Premake should do on any given run. For instance, the
 
 An _option_ modifies the behavior of the action. For instance, the `dotnet` option is used to change which .NET compiler set is used in the generated files. Options can accept a value, such as `--dotnet=mono` or act as a flag, like `--with-opengl`.
 
-From within your script, you can identify the current action with the [`_ACTION`](_ACTION) global variable, a string value. You can check for an option using the [`_OPTIONS`](_OPTIONS) table, which contains a list of key-value pairs. The key is the option identifier ("dotnet"), which references the command line value ("mono") or an empty string for valueless options.
+From within your script, you can identify the current action with the [`_ACTION`](_ACTION.md) global variable, a string value. You can check for an option using the [`_OPTIONS`](_OPTIONS.md) table, which contains a list of key-value pairs. The key is the option identifier ("dotnet"), which references the command line value ("mono") or an empty string for valueless options.
 
 ```lua
 -- delete a file if the clean action is running
@@ -26,7 +26,7 @@ targetdir ( _OPTIONS["outdir"] or "out" )
 
 ## Creating New Options
 
-New command-line options are created using the [`newoption`](newoption) function, passing a table which fully describes the option. This is best illustrated with some examples.
+New command-line options are created using the [`newoption`](newoption.md) function, passing a table which fully describes the option. This is best illustrated with some examples.
 
 Here is an option intended to force the use of OpenGL in a 3D application. It serves as a simple flag, and does not take any value.
 
@@ -125,4 +125,4 @@ newaction {
 
 The actual code to be executed when the action is fired should be placed in the `execute()` function.
 
-That's the simple version, which is great for one-off operations that don't need to access to the specific project information. For a tutorial for writing a more complete action, see [Adding a New Action](adding-new-Action).
+That's the simple version, which is great for one-off operations that don't need to access to the specific project information. For a tutorial for writing a more complete action, see [Adding a New Action](Adding-New-Action.md).

website/docs/Configurations-and-Platforms.md

@@ -6,7 +6,7 @@ A *configuration* is a collection of settings to apply to a build, including fla
 
 ## Build Configurations
 
-The [previous examples](your-first-script) showed how to specify build configurations.
+The [previous examples](Your-First-Script.md) showed how to specify build configurations.
 
 ```lua
 workspace "MyWorkspace"
@@ -27,7 +27,7 @@ workspace "MyWorkspace"
    configurations { "Froobniz", "Fozbat", "Cthulhu" }
 ```
 
-The meaning of the build configuration depends on the settings you apply to it, as shown in [the earlier examples](your-first-script).
+The meaning of the build configuration depends on the settings you apply to it, as shown in [the earlier examples](Your-First-Script.md).
 
 ```lua
 workspace "HelloWorld"
@@ -42,7 +42,7 @@ workspace "HelloWorld"
       optimize "On"
 ```
 
-The [Filters](filters) section will cover this in more detail.
+The [Filters](Filters.md) section will cover this in more detail.
 
 
 ## Platforms
@@ -56,7 +56,7 @@ platforms { "Win32", "Win64", "Xbox360" }
 
 Once set, your listed platforms will appear in the Platforms list of your IDE. So you can choose a "Debug Win32" build, or a "Release Xbox360" build, or any combination of the two lists.
 
-Just like the build configurations, the platform names have no meaning on their own. You provide meaning by applying settings using the [`filter`](filter) function.
+Just like the build configurations, the platform names have no meaning on their own. You provide meaning by applying settings using the [`filter`](filter.md) function.
 
 ```lua
 configurations { "Debug", "Release" }
@@ -76,7 +76,7 @@ filter { "platforms:Xbox360" }
 
 Unlike build configurations, platforms are completely optional. If you don't need them, just don't call the platforms function at all and the toolset's default behavior will be used.
 
-Platforms are just another form of build configuration. You can use all of the same settings, and the same scoping rules apply. You can use the [`system`](system) and [`architecture`()`](architecture) settings without platforms, and you can use otherwise non-platform settings in a platform configuration. If you've ever done build configurations like "Debug Static", "Debug DLL", "Release Static", and "Release DLL", platforms can really simplify things.
+Platforms are just another form of build configuration. You can use all of the same settings, and the same scoping rules apply. You can use the [`system`](system.md) and [`architecture`()`](architecture.md) settings without platforms, and you can use otherwise non-platform settings in a platform configuration. If you've ever done build configurations like "Debug Static", "Debug DLL", "Release Static", and "Release DLL", platforms can really simplify things.
 
 ```lua
 configurations { "Debug", "Release" }