xmake icon indicating copy to clipboard operation
xmake copied to clipboard

Packages cannot expose existing rules in libraries that use xmake

Open qudix opened this issue 1 year ago • 7 comments

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

As described here, I feel that using rules through packages are held back by the fact that you cannot re-use existing rules in an xmake based library.

A good example is the commonlibsse-ng package I made and pr'd here a long while back. I haven't updated the package because I felt that using it as a git submodule instead had more immediate benefits, of which include using the commonlibsse.plugin rule is one of them.

It is defined here: https://github.com/qudix/commonlibsse/blob/dev/xmake-extra.lua#L83

And used in this template here: https://github.com/qudix/commonlibsse-template/blob/main/xmake.lua#L32

Describe the solution you'd like

Some way to explicitly expose specific rules in an xmake library to package consumers without having to copy and paste those rules again into the package definition.

Perhaps something like:

package("commonlibsse")
    ...
    add_rules("commonlibsse.plugin", { alias = "plugin" })

which would grab the rule defined as commonlibsse.plugin in the libraries own xmake.lua or other included script, and expose it to the consumer who can then use it as @commonlibsse/plugin

this ignores a lot of the complexity as I'm not familiar enough with the xmake codebase to know of a better way to do this.

Describe alternatives you've considered

No response

Additional context

No response

qudix avatar Oct 21 '24 17:10 qudix

you can try to copy rule script files of your xmake project to package:installdir("rules"), it should work.

package("xxx")
    on_install(function (package)
        os.cp("plugin/*.lua", package:installdir("rules"))
    end)

like this.

https://github.com/xmake-io/xmake/blob/a7aab9dc7e64bd2a211c4d7937a7ffd7d6993a4d/xmake/modules/private/action/require/impl/actions/install.lua#L398

waruqi avatar Oct 22 '24 08:10 waruqi

This doesn't seem very clean, not to mention I'd have to do a text replace on an rules to rename them, otherwise in my example consumers would have to do add_rules("@commonlibsse/commonlibsse.plugin").

There's also the additional problem where rules that need to use target:extraconf(...) need to explicitly use their own name to get the extra configuration, but that changes depending on whether the rule is coming from a package or not: https://github.com/qudix/commonlibsse/blob/dev/xmake-extra.lua#L103

rule("commonlibsse.plugin")
...
    target:extraconf("rules", "commonlibsse.plugin")

vs in a package:

rule("plugin")
...
    target:extraconf("rules", "@commonlibsse/plugin")

qudix avatar Oct 22 '24 15:10 qudix

If you distribute rules through packages, you must add the package name prefix, @packagename/

waruqi avatar Oct 22 '24 16:10 waruqi

yes, that's what I said, that's a problem here

qudix avatar Oct 22 '24 16:10 qudix

try target:extraconf("rules", "@commonlibsse/plugin") or target:extraconf("rules", "commonlibsse.plugin")

or you can patch it when install them

waruqi avatar Oct 23 '24 03:10 waruqi

There needs to be better integration than just manually patching

qudix avatar Oct 23 '24 03:10 qudix

How about having some kind of rule object passed by xmake in callbacks? like:

rule("commonlibsse.plugin")
    on_config(function(target, opt)
        local conf = target:extraconf("rules", opt.rule:name()) -- or even opt.rule:targetconf(target)

SirLynix avatar Oct 23 '24 07:10 SirLynix