Build outputs are infinitely recursively processed

[artemking4]

What seems to be the problem?
When using custom rules, if a buildoutput happens to use the same file extension as the rule itself, premake gets into an infinite recursion loop and later dies with stack smashing(?).

What did you expect to happen?
I had expected premake not to compile already compiled files again. Though, something like that can be by design, i.e. you do .bmp>.png>.jpg, but not .png>.png>... (unless specified so)

What have you tried so far?
A dirty hack: create a file with a different extension and then copy it to the output directory.

How can we reproduce this?

rule "sampleRule"
    fileextension ".txt"

    -- buildmessage and buildcommands dont seem to matter
    buildmessage 'Copying %{file.relpath}'
    buildcommands 'cp %{file.relpath} new_%{file.relpath}'
    buildoutputs '%{file.basename}.txt'

workspace "sample"
    configurations { "Debug", "Release" }

project "sample"
    kind "Utility"
    rules { "sampleRule" }

    files { "**.txt" }

Keep in mind that for order for this to work you need to first have #1939 installed.
My premake script uses a required script and overrides the gmake utility project generator, so the version is still relevant, nothing is touched except that.

• Visual Studio 2022 (vs2022)
• Visual Studio 2019 (vs2019)
• Visual Studio 2017 (vs2017)
• Visual Studio 2015 (vs2015)
• Visual Studio 2012 (vs2012)
• Visual Studio 2010 (vs2010)
• Visual Studio 2008 (vs2008)
• Visual Studio 2005 (vs2005)
• GNU Makefile (gmake)
• GNU Makefile 2 (gmake2)
• XCode (xcode)
• Codelite
• Other (Please list below)

What version of Premake are you using?
5.0.0-beta1

[nickclark2016]

I mean, if it requires #1939 to be installed and it's currently not in master, I don't consider it a bug. That's an issue that should be worked out in #1939. If you can show it's an issue in other exporters, then that'll make sense for us to work it as a bug.

[artemking4]

It is an issue in all exporters though, you can just change the project kind to ConsoleApp or similar to observe said behavior.

[nickclark2016]

That is a project type. An exporter is Visual Studio, Gmake (not gmake2), xcode, etc.

[artemking4]

Well, my pull request does not modify anything other than gmake2's utility project type. And as i said, this can be observed in gmake2's cpp project type too. I can create a minimal reproducible example if you need that

[nickclark2016]

Ahh got it. Yes, please go ahead and attach a minimum premake5.lua file that can reproduce it (and any supporting files needed).

[artemking4]

premake5.lua:

rule "sampleRule"
    fileextension ".txt"

    -- buildmessage and buildcommands dont seem to matter
    buildmessage 'Copying %{file.relpath}'
    buildcommands 'cp %{file.relpath} new_%{file.relpath}'
    buildoutputs '%{file.basename}.txt'

workspace "sample"
    configurations { "Debug", "Release" }

project "sample"
    kind "ConsoleApp"
    rules { "sampleRule" }

    files { "**.txt" }

alongside with an empty sample.txt file

$ premake5 --version
premake5 (Premake Build Script Generator) 5.0.0-beta1
$ premake5 gmake2
Building configurations...
Running action 'gmake2'...
Error: [string "src/base/string.lua"]:27: stack overflow in token: file.basename

[nickclark2016]

So just to follow up, would you expect the generated files to not be included in the rule's outputs?

[artemking4]

Not really, i dont think that this is by any means good. Because then if you have 2 rules, i.e. one for .cpp>.so and the other one for .so, it will not pass it through the second rule, which im pretty sure isnt what someone would want. What im saying is that the rule's outputs should not be fed to itself again.

[nickclark2016]

Completely following now. I'll try to have a fix out this weekend, as I see where this needs to go.