premake and vs2022 linux project

[PreciousRoy0]

Hi,

I am trying to figure out how to generate a linux project for vs2022.

i found this. https://github.com/LORgames/premake-vslinux
but i have no idea how to load modules and have no idea if it should even work for vs2022.
I have also had a look at the docs but i have not found anything up until now.

this project type allows you to remotely debug on a linux machine.

Edit:
i found this https://premake.github.io/docs/system but it seems it does not work for what i want. any ideas?

[samsinsane]

The docs covers using modules. As for that module, I originally wrote it for VS2015, it might work with VS2017, VS2019 and VS2022 but you may have to make some modifications to get it working. I stopped using the project type as it wasn't very good with multiple projects, maybe that has changed though.

[PreciousRoy0]

well i have created a project with 3 separate libs manually and it works just fine for me, so they might have fixed it in the newer versions. i will have a look loading the module and letting you know if it works.

edit:
it does not work with the current version.
Error: ...ontroller/Vendor/Bin/Premake/premake-vslinux/vslinux.lua:14: unable to override 'archFromConfig'; no such function

i have no clue how it works, but i will have a look at it anyways.

[samsinsane]

I had some time to look into this there's a number of issues.

1. Projects with multiple projects are still aren't very good. The Premake project itself does not build because the projects are put into a different structure relative to each other. This is the same problem that existed in VS2015, however, there's multiple settings to alleviate this issue while VS2015 only had a single setting - which is weirdly no longer supported.
2. That error you pointed out is due to VS moving into the module system, so require "vstudio" will fix the issue.
3. The entire module checks if the action is VS2015, changing all the == to >= fixes that problem.
4. Not a huge issue but _HAS_EXCEPTIONS=0 is output even though it's not valid outside of MSC
5. The toolset defaults to msc, so it attempts to link system libraries as libName.lib instead of -lName
6. Files that aren't listed in the project file aren't copied over, this causes problems
7. The new externalincludedirs API doesn't work with the VSLinux project type and has to be piped through the same mechanism as includedirs
8. If a project uses the headers of another project but doesn't links or dependson it, there's a race condition that can cause the first project to build before the second project has had its files copied to the remote machine. This is how static libraries tend to be built and there's no real "fix" for this.
9. There's a remote output directory which does not default to using the local output directory information, RemoteOutRelDir needs to be added.
10. The deploy checkbox in the configuration manager is not checked, so the build isn't deployed (back to the device that built it???)
11. The debug information is left to default which defaults to the local debugger, attempting to run the program will run it on the Windows machine, not the Linux machine. Need to output the bare minimum .vcxproj.user file to default to use remote machine.
12. No ability to change compiler from GCC to Clang, or other.

There's built in support for using WSL directly instead of as a remote machine, I haven't investigated this at all.

I've managed to fix a few these but what I've done isn't useful on its own, I'll try to clean up the changes soon, push a branch and hopefully one day soon get back to it and fix the rest of the issue.