xmake icon indicating copy to clipboard operation
xmake copied to clipboard

Add config parameter to xmake build/run/clean

Open SirLynix opened this issue 10 months ago • 5 comments

Is your feature request related to a problem? Please describe.

Hello,

When using xmake from a vsxmake (or other) project, building a project will run two commands:

xmake config --mode=debug --foo=bar ...
xmake build TargetName

this works but has some issues :

  1. it requires the xmake.lua to be evaluated 2*N times (N being the number of times a single xmake command will process a xmake.lua), which is fast for most project but becomes time consumming on bigger projects having a lot of lua files included by a xmake.lua
  2. it resets xmake configuration to the one set when generating the vsxmake project (I sometime work with xmake in commandline and change configuration, but recompiling from VS breaks the config)
  3. VS is slow to launch new processes(?)

Describe the solution you'd like

Having the xmake build/clean tasks take a config parameter that it would apply temporarily (not saving it/restoring old config on exit) and changing vsxmake generator to use it would fix those issues, giving also the possibility to test a small build with a specific config without overriding the whole configuration.

Something like: xmake build --configs={mode="debug", foo="bar"}

Describe alternatives you've considered

No response

Additional context

No response

SirLynix avatar Apr 10 '25 14:04 SirLynix

This is very difficult to maintain and affects the configuration of all actions such as build, run, clean, and install. And it is only used for vsxmake.

We should write an optimization script only for vsxmake.

like this

xmake l plugin.vsxmake.build --configs=xxx target

waruqi avatar Apr 10 '25 16:04 waruqi

In addition, this still cannot avoid starting multiple xmake processes. It might be better if we have a way to start only one xmake to build.

Maybe we can then add a dummy target that depends on all targets, and in its post build custom command, execute the xmake build.

But I don't know if we can do it.

waruqi avatar Apr 11 '25 01:04 waruqi

This is very difficult to maintain and affects the configuration of all actions such as build, run, clean, and install. And it is only used for vsxmake.

We should write an optimization script only for vsxmake.

like this

xmake l plugin.vsxmake.build --configs=xxx target

A script like that would be a good way to handle it, I don't think it's only relevant for vsxmake but it would be my main usage of it.

In addition, this still cannot avoid starting multiple xmake processes. It might be better if we have a way to start only one xmake to build.

Maybe we can then add a dummy target that depends on all targets, and in its post build custom command, execute the xmake build.

But I don't know if we can do it.

When building a single target with a vsxmake project, only two xmake commands are run (xmake config and xmake build) so this would fix it. The real issue with vsxmake project is that currently "build solution" (or "clean solution") are badly handled as they run for every target (so they're doing a xmake config + xmake build or a xmake clean for every target), this is linked to #2969.

I think I know how to fix that, will do when I have time.

SirLynix avatar Apr 11 '25 06:04 SirLynix

A script like that would be a good way to handle it, I don't think it's only relevant for vsxmake but it would be my main usage of it.

But this is difficult to implement and maintain and there are many problems.

  1. xmake run only loads the global configuration, it does not modify the configuration.
  2. xmake build cannot implment this if do not modify the global configuration, which will trigger a lot of detection and global cache file updates.
  3. Adding this parameter to each action is difficult to maintain, and the configuration processing logic may not be exactly the same.

waruqi avatar Apr 11 '25 14:04 waruqi

The real issue with vsxmake project is that currently "build solution" (or "clean solution") are badly handled as they run for every target (so they're doing a xmake config + xmake build or a xmake clean for every target), this is linked to https://github.com/xmake-io/xmake/issues/2969.

I know, I mean, can we find a way to add a dummy target (BUILDALL), which is executed after all other targets.

for example:

project targets: foo, bar, zoo

create vsxmake project:

foo: <Exec Command> nothing to do </> bar: <Exec Command> nothing to do </> zoo: <Exec Command> nothing to do </> BUILDALL: <Exec Command> xmake build </>

waruqi avatar Apr 11 '25 14:04 waruqi