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

Changing the default outputdir for vsxmake is not supported by the autoupdate extension #1895

Closed
PierreEVEN opened this issue Dec 7, 2021 · 8 comments

Comments

@PierreEVEN
Copy link

PierreEVEN commented Dec 7, 2021

All is in the title

Describe the bug

When I compile the project from VisualStudio 2019, the autoupdate extension regenerate the files in the DEFAULT location instead of the custom outputdir

How to reproduce :

  1. Create a basic project with the autoupdate vsxmake plugin
add_rules("mode.debug", "mode.release")
add_rules("plugin.vsxmake.autoupdate")

target("HeadlessEngine")
    set_kind("binary")
    add_files("src/*.cpp")
  1. Create the vs project files in a CUSTOM output dir
xmake project -k vsxmake2019 my_custom_output_dir
  1. Open the vs project, add a new random source file

  2. Build from VS (the new file should normally appear after building, but it's not the case here)

What hapenned => Instead of updating the current project file, it create new VS project files in the DEFAULT folder : vsxmake2019 (instead of the custom one : my_custom_output_dir).

Related Environment

  • xmake version: 2.6.1
  • os: windows
  • target platform: windows
@PierreEVEN PierreEVEN added the bug label Dec 7, 2021
@PierreEVEN PierreEVEN changed the title changing the default outputdir for vsxmake is not supported by the autoupdate extension Changing the default outputdir for vsxmake is not supported by the autoupdate extension Dec 7, 2021
@SirLynix
Copy link
Member

SirLynix commented Dec 7, 2021

Also, installing a new VS version (2022) will make vsxmake.autoupdate to generate a vsxmake2022 folder instead of updating the vsxmake2019 one

@waruqi
Copy link
Member

waruqi commented Dec 8, 2021

I have improved it on dev, you can try

add_rules("plugin.vsxmake.autoupdate", {outputdir = "xxx"})

@waruqi
Copy link
Member

waruqi commented Dec 8, 2021

Also, installing a new VS version (2022) will make vsxmake.autoupdate to generate a vsxmake2022 folder instead of updating the vsxmake2019 one

This is to avoid VS version conflicts, and users will not frequently upgrade VS, you can reopen vsxmake2022.

@SirLynix
Copy link
Member

SirLynix commented Dec 8, 2021

I have improved it on dev, you can try

add_rules("plugin.vsxmake.autoupdate", {outputdir = "xxx"})

This shouldn't be part of xmake.lua I think, every user may change the output dir to whatever they want from the command-line.

Maybe we should store that info in a file (vsxproj?) when called from the command-line and reuse it? Same for vs version.

Also, installing a new VS version (2022) will make vsxmake.autoupdate to generate a vsxmake2022 folder instead of updating the vsxmake2019 one

This is to avoid VS version conflicts, and users will not frequently upgrade VS, you can reopen vsxmake2022.

It's not just an issue when you upgrade since you mah want to work with a lower vs version (like vs2019) while having vs2022 installed

@waruqi waruqi added this to the v2.6.2 milestone Dec 8, 2021
@waruqi
Copy link
Member

waruqi commented Dec 8, 2021

I added local cache to autoupdate and vsxmake plugin. you can try it again.

@waruqi
Copy link
Member

waruqi commented Dec 8, 2021

It's not just an issue when you upgrade since you mah want to work with a lower vs version (like vs2019) while having vs2022 installed

you can run xmake project -k vsxmake2019 now. the --kind=value will be cached

@waruqi
Copy link
Member

waruqi commented Dec 10, 2021

Does it work now?

@PierreEVEN
Copy link
Author

Does it work now?

Yup, thanks ! 🥳

I haven't tested using an older version of VS (which @SirLynix's was talking about) but the autoupdate now uses the correct directory 👍

@waruqi waruqi closed this as completed Dec 11, 2021
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

3 participants