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

xpack 打包应用改进? #5308

Closed
Wzshun opened this issue Jul 5, 2024 · 7 comments
Closed

xpack 打包应用改进? #5308

Wzshun opened this issue Jul 5, 2024 · 7 comments

Comments

@Wzshun
Copy link

Wzshun commented Jul 5, 2024

你在什么场景下需要该功能?

target("App")
  set_kind("binary")
  add_files("src/*.cpp")
  add_deps("foo")

target("foo")
  set_kind("shared")
  add_files("src/*.cpp")

includes("@builtin/xpack")

xpack("test")
  add_targets("App")
  set_formats("zip")

几个问题:

  1. 这样写法,xpack并不会去打包App的依赖项foo
  2. 给xpack额外添加targets,如add_targets("App", "foo"),能够打包foo,但是我不希望走xmake install类似的方式(在安装位置加入了 include、lib等内容),只需要一个动态库文件即可。
  3. 控制 target在install的目录应该怎么操作呢?比方说 我想把foo库,安装到安装目录的/plugins目录?

描述可能的解决方案

描述你认为的候选方案

其他信息

@Issues-translate-bot
Copy link

Bot detected the issue body's language is not English, translate it automatically.


Title: xpack Packaging application improvements?

@waruqi
Copy link
Member

waruqi commented Jul 6, 2024

这样写法,xpack并不会去打包App的依赖项foo

这不打包进去了么

ruki:test3 ruki$ xmake pack
checking for platform ... macosx
checking for architecture ... x86_64
checking for SDK version of Xcode for macosx (x86_64) ... 14.0
checking for Minimal target version of Xcode for macosx (x86_64) ... 14.0
[ 50%]: cache compiling.release src/foo.cpp
[ 62%]: cache compiling.release src/main.cpp
[ 62%]: linking.release libfoo.dylib
[ 87%]: linking.release App
packing build/xpack/test/test.zip ..
pack ok
ruki:test3 ruki$ unzip -l build/xpack/test/test.zip
Archive:  build/xpack/test/test.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
    34776  07-06-2024 22:29   bin/App
    16496  07-06-2024 22:29   bin/libfoo.dylib
---------                     -------
    51272                     2 files

控制 target在install的目录应该怎么操作呢?比方说 我想把foo库,安装到安装目录的/plugins目录?

使用 set_libdir()set_bindir()

@Wzshun
Copy link
Author

Wzshun commented Jul 9, 2024

尝试了下确实会打包动态库。
但好像有另外一个问题。

add_rules("mode.debug", "mode.release")

includes("@builtin/xpack")

target("packIssue")
    set_kind("binary")
    add_files("src/*.cpp")
    add_deps("foo")
    set_version("1.0.0", {build = "%Y-%m-%d %H:%M"})

target("foo")
    set_kind("shared")
    add_files("src/foo/*.cpp")
    add_installfiles("src/foo/Readme.md", {prefixdir="doc"})
    --set_bindir("plugins")

xpack("packTest")
    set_formats("zip")
    add_targets("packIssue")

这里的target("foo")的add_installfiles,并没有触发。
得必须xpack里加上add_targets("packIssue", "foo"),才会安装。

此外似乎如果target是一个静态库,也不会安装。(可能我之前以为 add_installfiles,没被触发就认为xpack不会级联依赖安装)。

#使用 set_libdir(),set_bindir()
这个只能控制xpack本身,但如果我想要每个库,自行定位安装位置怎么做到呢?比方说这里的foo,我希望安装到plugins目录,其他库还是正常安装?

@Issues-translate-bot
Copy link

Bot detected the issue body's language is not English, translate it automatically.


After trying it, the dynamic library will indeed be packaged.
But there seems to be another problem.

add_rules("mode.debug", "mode.release")

includes("@builtin/xpack")

target("packIssue")
    set_kind("binary")
    add_files("src/*.cpp")
    add_deps("foo")
    set_version("1.0.0", {build = "%Y-%m-%d %H:%M"})

target("foo")
    set_kind("shared")
    add_files("src/foo/*.cpp")
    add_installfiles("src/foo/Readme.md", {prefixdir="doc"})
    --set_bindir("plugins")

xpack("packTest")
    set_formats("zip")
    add_targets("packIssue")

The add_installfiles of target("foo") here is not triggered.
You must add add_targets("packIssue", "foo") to xpack before it can be installed.

In addition, it seems that if the target is a static library, it will not be installed. (Maybe I thought that add_installfiles was not triggered before and thought that xpack would not cascade dependency installation).

#Use set_libdir(), set_bindir()
This can only control xpack itself, but if I want each library to locate the installation location by myself, how can I do it? For example, for foo here, I want to install it in the plugins directory. Can other libraries be installed normally?

@waruqi
Copy link
Member

waruqi commented Jul 10, 2024

此外似乎如果target是一个静态库,也不会安装。(可能我之前以为 add_installfiles,没被触发就认为xpack不会级联依赖安装)。

其实这块按理就不应该默认被安装。。

  1. binary 依赖静态库:那么仅仅只需要安装 binary 自身的东西,就能保证运行了,静态库都被 link 进去了,还安装来干嘛。
  2. binary 依赖动态库:那么安装 binary + 动态库自身,就能确保运行了,而动态库里面的 headerfiles 按理也不应该被安装了

所以按理不应该无脑级联安装所有,不过目前的默认安装策略确实有点乱,且不够灵活,应该默认走上面的策略,然后单独搞个策略, 针对性开启某些 target 的依赖级联。

这个要后面捋下才行。

@Issues-translate-bot
Copy link

Bot detected the issue body's language is not English, translate it automatically.


In addition, it seems that if the target is a static library, it will not be installed. (Maybe I thought that add_installfiles was not triggered before and thought that xpack would not cascade dependency installation).

In fact, this piece of software should not be installed by default. .

  1. Binary relies on static libraries: Then you only need to install binary's own things to ensure that it runs. The static libraries are linked in, so why install them?
  2. Binary depends on the dynamic library: then installing binary + the dynamic library itself will ensure its operation, and the headerfiles in the dynamic library should not be installed.

Therefore, it stands to reason that you should not install everything in a mindless cascade. However, the current default installation strategy is indeed a bit messy and not flexible enough. You should default to the above strategy, and then create a separate strategy to specifically enable the dependency cascade of certain targets.

This will have to be sorted out later.

@waruqi
Copy link
Member

waruqi commented Jul 10, 2024

我重构设计了下默认安装策略,可以看下,后面会基于这个,同步 xmake packxmake install 的安装策略。 #5325

@waruqi waruqi mentioned this issue Jul 23, 2024
20 tasks
@waruqi waruqi closed this as completed Jul 23, 2024
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