edx编辑器和xmake适配遇到的一些问题

[heheda123123]

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

edx（edx介绍 https://zhuanlan.zhihu.com/p/635336347 ）和xmake的适配

1 有命令能关闭“编译输出的格式化”和“高亮”吗？
https://gitee.com/scu319hy/edx/issues/I76FIV#note_18886685_link

2 添加include路径时，自动去掉了尾部的"/"，能保留吗
如图提到了可能会引发的问题

3 支持导出标准的数据格式
https://gitee.com/scu319hy/edx/issues/I76FIV#note_18892725_link
edx和clion的都采用了codeblocks的工程做为数据交换格式

描述可能的解决方案

1 给xmake加个命令指定输出原始的编译信息

描述你认为的候选方案

No response

其他信息

No response

[Issues-translate-bot]

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

---

Title: Can the output information compiled by xmake turn off formatting and highlighting?

In what scenario do you need this function?

When doing the adaptation of edx and xmake, I used cmake before
Is there a command to turn off "formatting of compiled output" and "highlighting"?
https://gitee.com/scu319hy/edx/issues/I76FIV

describe possible solutions

Add a command to xmake to specify the output of the original compilation information

Describe what you think is a candidate

No response

other information

No response

[heheda123123]

一个典型的codeblocks项目文件
testwx31.txt

[Issues-translate-bot]

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

---

A typical codeblocks project file
testwx31.txt

[waruqi]

1 有命令能关闭“编译输出的格式化”和“高亮”吗？

这个高亮是编译器输出的，xmake 只是设置了 -fdiagnostics-color=always 开启了而已

按理，如果你运行 xmake 时候捕获了 stdout，xmake 会自动关闭这个的，不会输出高亮，不需要额外的关闭，内部有 isatty 判断

如果非要强行关，可以运行时候配置 XMAKE_COLORTERM=nocolor 环境变量。

输出警告，加 -w 肯定有效果，完整输出不处理，走 -v

2 添加include路径时，自动去掉了尾部的"/"，能保留吗
如图提到了可能会引发的问题

不能保留

3 支持导出标准的数据格式

不支持 codeblocks 格式输出，但是可以执行 xmake l xxx.lua自定义脚本，实现任意格式输出，参考。

https://github.com/xmake-io/xmake-vscode/blob/master/assets/target_informations.lua

xmake l target_informations.lua

可以在这基础上，输出自己关心的数据，也可以自己输出符合 codeblocks 格式的数据。。

更多跟 ide 的交互，错误获取等，可以参考 xmake-vscode 插件的实现，大部分功能，这里面都有类似实现。

[Issues-translate-bot]

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

---

1 Is there a command to turn off "formatting of compiled output" and "highlighting"?

This highlight is output by the compiler, xmake just set -fdiagnostics-color=always to enable it

It stands to reason that if you capture stdout when you run xmake, xmake will automatically close this, no output highlighting, no additional closing is required, there is isatty judgment inside

If you have to forcibly close it, you can configure the XMAKE_COLORTERM=nocolor environment variable at runtime.

Output warning, adding -w will definitely have an effect, the complete output will not be processed, use -v

2 When adding the include path, the trailing "/" is automatically removed, can it be kept?
The problems that may arise are mentioned in the figure

can't keep

3 Support exporting standard data formats

It does not support codeblocks format output, but you can execute xmake l xxx.lua custom script to achieve arbitrary format output, refer to.

https://github.com/xmake-io/xmake-vscode/blob/master/assets/target_informations.lua

xmake l target_informations.lua

On this basis, you can output the data you care about, or you can output data that conforms to the codeblocks format. .

[scu319hy]

我是EDX的作者

1. 关于高亮和格式化
   相同的代码在cmake下输出是这样的
   
   在xmake下是这样的
   
   可以看到，xmake输出是做了格式化的，文件路径变为相对路径了。并且在前面加了高亮的"error:"。cmake使用了-fdiagnostics-color=always，但并没有这种效果。

2. 关于警告加-w的不显示的问题。msvc下
   同样的代码在cmake是这样
   
   而在xmake下是这样
   
   当然，gcc下加-w是有效果的。

3. 关于工程/目标信息生成的问题。
   建议能官方支持一种标准的交换数据格式。方便其它工具集成。

通过脚本插件的形式去捕获这些数据最大的弊端是api接口缺少规范性。
我必须维护一段与xmake强依赖的代码。并且在远程编译时，我还要把这段代码传到服务器上去...
如果是用相对标准的交换数据文件，就能减少这种依赖性。
就算xmake版本变化，它也能够自成体系。而不是我再去根据它的版本变化来维护不同的插件。

[Issues-translate-bot]

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

---

I am the author of EDX

1. About highlighting and formatting
   The output of the same code under cmake is like this
   
   This is the case under xmake
   
   It can be seen that the xmake output is formatted, and the file path becomes a relative path. And add the highlighted "error:" in front. cmake uses -fdiagnostics-color=always, but it doesn't have this effect.

2. About the problem of not displaying the warning plus -w. under msvc
   The same code in cmake is like this
   
   And this is the case under xmake
   
   Of course, adding -w under gcc is effective.

3. Questions about project/target information generation.
   It is recommended to officially support a standard exchange data format. Easy to integrate with other tools.

The biggest disadvantage of capturing these data in the form of script plug-ins is the lack of standardization of the API interface.
I have to maintain a piece of code which is strongly dependent on xmake. And when compiling remotely, I have to pass this code to the server...
This dependency can be reduced if a relatively standard exchange data file is used.
Even if the xmake version changes, it can be self-contained. Instead of me going to maintain different plugins according to its version changes.

[waruqi]

可以看到，xmake输出是做了格式化的，文件路径变为相对路径了。并且在前面加了高亮的"error:"。cmake使用了-fdiagnostics-color=always，但并没有这种效果。

除了最开头那个 error: 前缀，后面是编译器的输出。。这边所有错误，不仅仅是编译错误，只要运行出错，执行到了 raise("xxx")

都会显示 error: xxx

这个前缀是改不了的，但是高亮问题，上面说了 用 XMAKE_COLORTERM=nocolor 去运行 xmake 就能禁用高亮

参考：https://github.com/xmake-io/xmake-vscode/blob/c02f7c188dd9ebcabbd67a30507eee3d1f35d883/src/xmake.ts#L145

关于警告加-w的不显示的问题。msvc下

我这里可以，确保配置了 set_warnings("all") 对 msvc 开启所有警告输出

如果还是没有，可以看下 xmake -v 里面的完整编译参数，复制出来，手动执行下 看看是否有警告输出，或者跟 cmake 对下编译 flags

关于工程/目标信息生成的问题。
建议能官方支持一种标准的交换数据格式。方便其它工具集成。
通过脚本插件的形式去捕获这些数据最大的弊端是api接口缺少规范性。
我必须维护一段与xmake强依赖的代码。并且在远程编译时，我还要把这段代码传到服务器上去...
如果是用相对标准的交换数据文件，就能减少这种依赖性。
就算xmake版本变化，它也能够自成体系。而不是我再去根据它的版本变化来维护不同的插件。

可以考虑内置，但目前暂时没时间支持，并且对这个格式 也不是很了解。

或者你可以先参考我上面说的 xmake l codeblocks.lua 方式，输出 codeblocks 格式输出，调通后，直接提 pr 过来到这个目录下 https://github.com/xmake-io/xmake/tree/master/xmake/plugins/project 就行了。

后面就能改用 xmake project -k codeblocks 执行。

[Issues-translate-bot]

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

---

It can be seen that the xmake output is formatted, and the file path becomes a relative path. And add the highlighted "error:" in front. cmake uses -fdiagnostics-color=always, but it doesn't have this effect.

Except for the error: prefix at the very beginning, the following is the output of the compiler. . All errors here, not just compilation errors, as long as there is an error in operation, the execution reaches raise("xxx")

Will display error: xxx

This prefix cannot be changed, but the highlighting problem, as mentioned above, can disable highlighting by running xmake with XMAKE_COLORTERM=nocolor

Reference: https://github.com/xmake-io/xmake-vscode/blob/c02f7c188dd9ebcabbd67a30507eee3d1f35d883/src/xmake.ts#L145

About the problem of not displaying the warning plus -w. under msvc

I can do it here, make sure to configure set_warnings("all") to enable all warning output for msvc

If not, you can look at the complete compilation parameters in xmake -v, copy them out, and execute them manually to see if there is a warning output, or compile flags with cmake

Questions about project/target information generation.
It is recommended to officially support a standard exchange data format. Easy to integrate with other tools.
The biggest disadvantage of capturing these data in the form of script plug-ins is the lack of standardization of the API interface.
I have to maintain a piece of code which is strongly dependent on xmake. And when compiling remotely, I have to pass this code to the server...
This dependency can be reduced if a relatively standard exchange data file is used.
Even if the xmake version changes, it can be self-contained. Instead of me going to maintain different plugins according to its version changes.

It can be considered built-in, but currently there is no time to support it, and I don't know much about this format.

Or you can refer to the xmake l xxx.lua method I mentioned above to output the codeblocks format output. After tuning, directly bring the pr to this directory https://github.com/xmake-io/xmake/tree /master/xmake/plugins/project will do.

You can use xmake project -k codeblocks to execute later.