This new 'using' API, and a slight addition to the storage of all properties, allows us to mark settings as either public, private or interface.

using then allows you to use import public & interface properties from other projects, effectively creating a way for a project to say... "if you use me, you need these settings".

This is currently in a proof of concept stage, and any feedback or additional unit-tests would be extremely helpful.

path.translate now uses the target OS separator by default instead of Windows separator. Fixes #86

The wiki will need to be updated to reflect this change when/if it's merged.

On windows 10 with a c++ project, using premake5 vs2017 will result in a solution that targets the Windows SDK 8.1, not the new 10.0.* SDK Versions.

Example error message when trying to build a bog standard 'Hello World' C++ solution created with Premake5 (compiled from source on commit 66362c0 ):

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141\Toolset.targets(34,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".

This will always happen on a machine that only has VS2017 installed, without the 8.1 SDK, which is the default state. On such a machine, the 'Retarget Projects' right click option shows the following: .

While this is a quickfix, I feel that the default behavior for the vs2017 action should be to use the 10.0 SDK that is guaranteed to be installed, not the 8.1 SDK that will become less and less used as more devs upgrade to using only 2017.

We should not assume that someone running the vs2017 action has VS2015 or the older SDK installed.

Edit: I just saw #450 and the addition of the systemversion, so at least I have a nicer workaround now with systemversion("10.0.15063.0"), but I still feel that it would be a more reasonable default than 8.1.

What does this PR do?

Adds support for "external" headers to Visual Studio 2022. This adds three new APIs:

• externalwarnings - Controls warning levels for headers considered "external" (/external:Wn, <ExternalWarningLevel>)
• externalanglebrackets - When set to "On" treats all headers included with angle brackets as "external" (/external:anglebrackets, <TreatAngleIncludeAsExternal>)
• externalincludedirs - Include directory paths to treat as "external" (/external:Ipath, <>)

This is a different take on this support than #1701. Here instead of repurposing sysincludedirs, I added a new concept of externalincludedirs. I think these two things are fundamentally different as "external" in this context means "not part of my project" which doesn't necessarily mean "system". For example, I use these for some third-party non-system libraries, which I include using double quotes and not angle brackets.

MSVC Docs: https://docs.microsoft.com/en-us/cpp/build/reference/external-external-headers-diagnostics?view=msvc-170

How does this PR change Premake's behavior?

Existing behavior should be unaffected, all new functionality is behind new APIs.

Anything else we should know?

Add any other context about your changes here.

closes #1692

Did you check all the boxes?

• [x] Focus on a single fix or feature; remove any unrelated formatting or code changes
• [x] Add unit tests showing fix or feature works; all tests pass
• [x] Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
• [x] Follow our coding conventions
• [x] Minimize the number of commits
• [x] Align documentation to your changes

When working with single file library, it easier to include them in the project as sources ( e.g. sqlite3.c, duktape.c, ... )

The problem is there's no way to specify c++ specific build options (similar to CFLAGS and CPPFLAGS )

I propose to add a cppbuildoption that would only apply to c++ files, and I can implement it.

Any remarks before I start?

This is the original change list re-applied to HEAD....

Obviously, as per discussion, this thing needs more work before we can merge... but I just wanted to re-open the pull request.

On a fresh clone, bootstrap.sh or bootstrap.bat can be used to prepare the initial premake executable on Windows, OSX and Linux. The bootstrap scripts are stripped from the source releases.

What problem will this solve? Confusion.

Throughout the example code indents are used as a stylized format for the example code snippets. As someone new to remake this was highly misleading because indent in a language with no other scoping indicators generally means scope (and even where there are indicators, any whitespace is usually inserted to reinforce some existing scope to the reader). I appreciate that there are places where scope is explained, however even then, it is 3 sections in, and having seen previous examples there is confusion around what exactly is meant by scope in the explanation. Ultimately, in premake5 scope seems to mean "anything after this" unless another thing like this one is declared. Nothing wrong with that, but the indents in the examples do not help to communicate that. I didn't really understand the explanation of scope until I spent 4 hours messing around with a test project that had, at the time, inexplicable outcomes. And the confusion I had can be directly traced back to those indents.

What might be a solution? Forgoing indents in the examples entirely would be best, since then "cherry picking" the docs would make clear there are no indented scopes, and if that were surprising, might prompt further doc investigation.

What other alternatives have you already considered? Something which explains the basic scoping in the first example, at that point in the doc. If it said right away "all these ident are meaningless, here's how the scope works here" I'd be 4 hours younger :) This wouldn't catch hardcore cherry pickers, but most will at least skim the first example and text around it.

Anything else we should know? It actually works nicely, and quite intuitively, once the actual scoping mechanism is correctly understood, it's just getting to the correctly part .

What problem will this solve?

The GitHub wiki, where the documentation is currently stored, has been subject to spam and is currently locked down.

Ideally, the documentation would just be a collection of Markdown files in a docs/ folder, something like this; that would allow us to update the docs right alongside the code and submit it all together in a single pull request. Downside is that we lose GitHub's wiki page search feature.

What might be a solution?

Set up an open source documentation website package like Docusaurus or MkDocs to format and serve the documentation.

What other alternatives have you already considered?

That's pretty much it. Don't think re-opening the wiki is a viable option.

Anything else we should know?

Bonus points if we can serve documentation for different versions of Premake from the same site, i.e 5.x vs. 6.x.

Update: We're bring a new Docusaurus-based site online now. Left to do:

• [x] Bootstrap new site (@KyrietS)
• [x] Port reference pages (@KyrietS)
• [x] Port user guide pages (@starkos)
• [x] Fill in home and download pages (@starkos)
• [x] Set up publishing action (@KyrietS)
• [x] Set up search (@KyrietS)
• [x] Redirect all wiki content to new locations

I guess it's painfully obvious, but that's more reason to start changing something. Premake does not present itself very well to the world. Googling premake brings me to (In order):

• The github page
• The sourceforge page
• industrious one page
• bitbucket page

That is 4 different pages!

It's good that github is the first entry, since it's the latest one, but why are the other ones still active ?

• Sourceforge shows content from version 3.7 and that version 4.0 is released, but the old documentation remains.
• Bitbucket shows that content has moved to gibhub, but:
  • It's not highlighted red or anything.. anyone used to skipping headers and introductions will not read it.
  • There is still documentation about premake5.

Googling Premake5 will bring you to bitbucket first! I think that the old places are still up & running is the reason why google lists them as high as they are right now.

Almost all discussion entries about premake show something like "not updated since 2010". This is probably another symptom of the above.

Looking at the main page (Github), it shows 5.0 alpha and 4.4 beta. People don't like alpha or beta. They like stable releases. 5.0 has been alpha since at least 2013.

My suggestions:

• Remove all content from the old pages, replace it with a link to the new page. This should help prevent search engines from indexing old pages as high as currently.
• If possible, add an automatic redirect to the new page.
• Remove the forum from http://industriousone.com/forums/premake. The content there is so old there is probably no use for keeping it.
• If the google group is the currently active forum, then by all means put a link to it on the github page and readme.md.
• Put a link to the github wiki into the readme.md on github. Few projects use the wiki on github, so if you don't point people to it, they won't try to look for it.
• Add a short & nice description of the project into the readme.md.
• And most of all, cut features as much as needed to get 5.0 golden.
  • Don't make this into Duke Nukem Forever.

A nice example of a helpful readme.md is Ashley:

• Appealing logo
• Short but informative description
• Every link you need to get started using it
• Information about the community and how to contribute

I really like premake, but it saddens me to see it not using its full potential.

I am attempting to make 2 solution files in my project. One that contains all projects, and a second that contains a subset of the same projects.

Your wiki page on the subject indicates this is possible, but I'm not seeing a way through with the API as it is.

a) I can't specify the same project name without re-specifying all the details I already did further up in the same script. b) The externalproject command requires a bunch of details. For instance, the uuid. And, the location. Both of which are internally known already (or only).

There ought to be a way to refer to the existing project declaration. Do you have plans for a "projectref" command?

The upshot of what i'm asking for is to generate a second solution with references to already generated project files.

What's your question? Is is possible to add parameterds /MT and C++20 dialect from your config script?

Anything else we should know? I don't know how to make /MT by default in VS2022 project files.

What's your question?

I want override malloc with the mimalloc single object file:

gcc -o myprogram mimalloc-override.o  myfile1.c ...

Anything else we should know?

Use cmake link object libraries: https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries-via-target-objects

What does this PR do?

Adds Support for Unity builds in visual studio 2019+. Adds one new flag "enableUnityBuild" with options On and Off.

How does this PR change Premake's behavior?

Adds Unity Build/Jumbo Build support.

Anything else we should know?

Unity builds really speed up compile time, being able to set them per config and project is a nice feature and something I personally needed.

Did you check all the boxes? Honestly I did this in a hurry and was a neat feature that I wanted myself, if there is anything in particular I should be adding then feedback is welcome.

What does this PR do?

Handle entrypoint for msc (for no vs* action).

How does this PR change Premake's behavior?

Just change msc toolset for entrypoint "somefunc"

Anything else we should know?

Tested locally (not on https://github.com/Jarod42/premake-sample-projects as usual #2003 (--cc=msc) would be required there to test it properly.

Did you check all the boxes?

• [x] Focus on a single fix or feature; remove any unrelated formatting or code changes
• [x] Add unit tests showing fix or feature works; all tests pass
• [ ] Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
• [x] Follow our coding conventions
• [x] Minimize the number of commits
• [ ] Align documentation to your changes

What does this PR do?

Allow to specify "--cc=msc" as command line (in addition to gcc/clang).

How does this PR change Premake's behavior?

Just the command line to specify cc

Anything else we should know?

Tested on https://github.com/Jarod42/premake-sample-projects/tree/windows_ninja (More specifically that action run).

Did you check all the boxes?

• [x] Focus on a single fix or feature; remove any unrelated formatting or code changes
• [ ] Add unit tests showing fix or feature works; all tests pass
• [ ] Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
• [x] Follow our coding conventions
• [x] Minimize the number of commits
• [ ] Align documentation to your changes

You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!

What seems to be the problem? In Visual Studio 2022 and 2019 when loading up a project with the postbuildcommands option set. The paths are not in quotes which causes the script when run to give unexpected results and throws errors because it cannot handle spaces in paths. Also in one of the filepaths Premake adds a '/' at the end which makes the path invalid.

What did you expect to happen? Post build i expect the event to copy a DLL file from the DLL project output to the Exe Project output directories.

What have you tried so far? Manually wrapping the directories and file paths in quotes after Premake generates the projects.

How can we reproduce this? Create a solution in Visual Studio and create a solution with 2 projects in it. Then create a post build event in the lua script that must have a space in the directory or paths.

What version of Premake are you using? premake5 (Premake Build Script Generator) 5.0.0-beta1

Anything else we should know? You have a good tool here, this is a minor bug but drives me crazy, i would love to see it fixed.