Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Build Steps #1400

Closed
redorav opened this issue Feb 11, 2020 · 8 comments
Closed

Custom Build Steps #1400

redorav opened this issue Feb 11, 2020 · 8 comments

Comments

@redorav
Copy link
Collaborator

redorav commented Feb 11, 2020

What problem will this solve?
I'm trying to add Custom Build Steps to my build, I can now see how they would be done in the vcxproj (via the Visual Studio interface) but now I would like to add them to premake.

What might be a solution?
I'm trying to find out whether premake supports this but it seems like it doesn't as I've not been able to find any mention of it in the code, so perhaps I could give it a stab.

What other alternatives have you already considered?
I've considered build rules and pre/post events, but they all follow the "input -> output" model, whereas I'm trying to run something only once if certain dependencies have been modified with respect to a single output file. The custom built step works at a project, not file, level. Here's the documentation for the feature. https://devblogs.microsoft.com/visualstudio/custom-build-steps-tools-and-events/ and https://docs.microsoft.com/en-us/cpp/build/how-to-add-a-custom-build-step-to-msbuild-projects?view=vs-2019

Where do you think I could start and what should the interface be? I can see how the properties would fit in MSBuild, would I find issues trying to do the same thing in XCode or gmake2?

In Visual Studio there are several properties relating to this

  • command line
  • description
  • outputs
  • dependencies (other than output)

These are the ones I'm mostly interested in. Does something like this make sense?

project("MyProject")
buildstepcommand("mytool.exe")
buildstepdescription("executes tool")
buildstepoutput("file.ext")
buildstepdependencies { "a.file", "b.file" }

@samsinsane
Copy link
Member

There's this using buildcommands, buildmessage, buildoutputs, and buildinputs - is this what you're looking for?

@redorav
Copy link
Collaborator Author

redorav commented Feb 12, 2020

The problem I have with those is that build commands are run once per build input, whereas I want to run the step only once, but based on multiple dependencies which could cause that one process to run. Does what I'm looking for make sense?

@redorav
Copy link
Collaborator Author

redorav commented Feb 12, 2020

Just a few more comments on this, it looks like in Visual Studio there are several ways to do custom build actions:

  1. Custom Build Tool: This is used on a per-file basis. Essentially maps to the "Custom Build Tool" in Visual Studio. Premake exposes these as buildcommands, buildmessage, etc.
  2. Rules: Another mechanism for doing the above. Premake also calls them rules
  3. Build Events: Perform certain actions before a project build takes place (if the build is to take place), or after. Premake calls these postbuildcommands and prebuildcommands.
  4. Build Steps: Perform one command as part of the project build, taking dependencies into account. Premake doesn't expose this and this is what I would like to add.

I wonder if I could reuse the names buildcommands, buildmessage, etc. but if at project scope (without any files filter) it would translate into a Build Step, otherwise it's kept as a per file thing? Would that make sense? The only reason I say this is that buildcommands doesn't do anything with no filters (it doesn't apply to all extensions, for example)

@redorav
Copy link
Collaborator Author

redorav commented Feb 15, 2020

@samsinsane I've managed to get this to work in Visual Studio by reusing the existing 4 keywords you showed me, but in the context of a project, that is, if there are no file filters present it will execute for the project you've selected. Other filters like config still work. I could directly send a PR or we could discuss it further?

@starkos
Copy link
Member

starkos commented Feb 17, 2020

A PR would probably be a good idea, since it would give us something real to discuss.

@redorav
Copy link
Collaborator Author

redorav commented Feb 17, 2020

Thanks, I've added #1403

@remram44
Copy link

Should this be closed now that the PR is in?

@redorav
Copy link
Collaborator Author

redorav commented Mar 15, 2020

@remram44 Indeed, thanks

@redorav redorav closed this as completed Mar 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants