xmake-io / xmake

🔥 A cross-platform build utility based on Lua
https://xmake.io
Apache License 2.0
10.05k stars 787 forks source link

Do not ignore inherited/included configuration on debug #4351

Closed EnergoStalin closed 12 months ago

EnergoStalin commented 1 year ago

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

It's not taking in account included configs

I have structure like this

xmake.lua

-- Top level xmake
includes("compiler.lua", "somemodule/xmake.lua")

compiler.lua

-- Compiler with toolchain settings
add_rules("mode.release", "mode.debug")

add_cflags("-Wall", "-Werror", "-Wextra")
set_languages("c11")

add_toolchains("gcc")

somemodule/xmake.lua

-- Module xmake
includes("test/xmake.lua")

somemodule/test/xmake.lua

-- Test xmake
target("test")
    set_kind("binary")

When building target from the top level xmake it works perfectly because global configuration inherits top down but extension seems to ignore top level configs and going straight for target's xmake.lua even ignoring direct includes("../../compiler") in somemodule/test/xmake.lua

Describe the solution you'd like

I'd like perform config evaluation like it's xmake does not ignoring top level settings for project

Describe alternatives you've considered

I considered copy pasting compiler.lua directly into test/xmake.lua which obviously work. It Didn't work tho when including it like that includes("../compiler.lua") or via add_requireconfs.

Additional context

In conclusion it works as expected only when contents of compiler.lua inserted directly into somemodule/test/xmake.lua

xmake v2.8.3+20230926 gcc (GCC) 13.2.1 20230801 GNU gdb (GDB) 13.2 Lua 5.4.6

Vscode

Version: 1.83.1 Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc Date: 2023-10-10T23:45:31.402Z Electron: 25.8.4 ElectronBuildId: 24154031 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Linux x64 6.5.9-arch2-1 XMake: v2.2.5

waruqi commented 12 months ago

but extension seems to ignore top level configs and going straight for target's xmake.lua even ignoring direct includes("../../compiler") in somemodule/test/xmake.lua

includes does not introduce the add_cflags/add_defines target APIs directly into the current xmake.lua, it only works for targets defined in compiler.lua and its sub-xmake.lua.

you can use function to wrap it if you want to set them to test/xmake.lua

compiler.lua

function set_flags_for_compiler()
    add_cflags("-Wall", "-Werror", "-Wextra")
    set_languages("c11")
    add_toolchains("gcc")
end

test/xmake.lua

includes("compiler.lua")

set_flags_for_compiler()

target("xxx")
EnergoStalin commented 12 months ago

Thanks for the solution i already realized that it's not setting flags through includes anyway somehow i misstested it when filing issue. Should've read about scopes first instead of assuming it wrong.

It's still looks not as fancy as i was initially hoped it to be but it works even inheriting from top level xmake.

-- Desired top level xmake
includes("compiler.lua", "rules.lua", "test/xmake.lua")

-- Current top level xmake
includes("compiler.lua")
set_compiler_flags()

includes("rules.lua", "test/xmake.lua")

Since it actually inherits top level xmake configuration it's not problem anymore.

Also notifications let me down this time perhaps it's because issue was transferred after response. I would have responded 10 hours earlier if I had seen the notification.