add support to LDFLAGS env variable for modules and shared libs #10

已合并
MicheleC 5 年前 将 1 次代码提交从 feat/linker_flags 合并至 master
efferre 评论于 5 年前
协作者

CMAKE_*_LINKER_FLAGS inherith from LDFLAGS. The current implementation of CMakeLists.txt
overrides this behaviour.

CMAKE_*_LINKER_FLAGS inherith from LDFLAGS. The current implementation of CMakeLists.txt overrides this behaviour.
efferre 评论于 5 年前
发布者
协作者

I have already prepared the patches for all the other repositories. If this patch looks fine for you, I can proceed by pushing the feat/linker_flags of all the other repositories creating the respective pull requests.

I have already prepared the patches for all the other repositories. If this patch looks fine for you, I can proceed by pushing the feat/linker_flags of all the other repositories creating the respective pull requests.
SlavekB 评论于 5 年前
所有者

@efferre, now I finally understand the commits that have begun to appear here today!

First I was confused when a branch feat/linker_flags appeared on the main TDE/tde repository and then a strange commit in TDE/experimental repository. Because the branch on the main TDE/tde repository was messing up for automation scripts on VPS, I removed it.

Now your commit already makes good sense. Please, have you tested whether CMAKE_SHARED_LINKER_FLAGS is treated as a list? If it is used as a list, it would be better to use

list( APPEND CMAKE_SHARED_LINKER_FLAGS "-Wl,-no-undefined" )

instead of

set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ..." )

If it is used as a string, then your commit looks like an appropriate solution.

@efferre, now I finally understand the commits that have begun to appear here today! First I was confused when a branch feat/linker_flags appeared on the main [TDE/tde](../tde) repository and then a strange commit in [TDE/experimental](../experimental) repository. Because the branch on the main TDE/tde repository was messing up for automation scripts on VPS, I removed it. Now your commit already makes good sense. Please, have you tested whether CMAKE_SHARED_LINKER_FLAGS is treated as a list? If it is used as a list, it would be better to use ``` list( APPEND CMAKE_SHARED_LINKER_FLAGS "-Wl,-no-undefined" ) ``` instead of ``` set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ..." ) ``` If it is used as a string, then your commit looks like an appropriate solution.
efferre 评论于 5 年前
发布者
协作者

I am sorry for the noise but I have been making experience with git submodules and with gitea REST API :-P Right now I have pushed only changes to tdelibs repo as pilot test, I can easily continue with the others now that I have a script to iterate over all the 65 modified submodules :-)

The CMAKE_*_LINKER_FLAGS variables are here used as strings. I could use the

string( APPEND ... )

form in the patches but I don't think it makes a big difference comparing to how is implemented now.

If you agree I will continue with the pushes and pull requests

I am sorry for the noise but I have been making experience with git submodules and with gitea REST API :-P Right now I have pushed only changes to tdelibs repo as pilot test, I can easily continue with the others now that I have a script to iterate over all the 65 modified submodules :-) The CMAKE_*_LINKER_FLAGS variables are [here](https://github.com/Kitware/CMake/blob/master/Modules/CMakeCommonLanguageInclude.cmake) used as strings. I could use the string( APPEND ... ) form in the patches but I don't think it makes a big difference comparing to how is implemented now. If you agree I will continue with the pushes and pull requests
SlavekB 评论于 5 年前
所有者

Thank you for verifying the list × string. In this case, the existing patch is ok. Using string( APPEND ... ) is not possible because it is a new in CMake 3.4.0 while we hold CMake 2.8.x support.

You can go ahead and push the remaining pull requests.

Thank you for verifying the list × string. In this case, the existing patch is ok. Using `string( APPEND ... )` is not possible because it is a new in CMake 3.4.0 while we hold CMake 2.8.x support. You can go ahead and push the remaining pull requests.
SlavekB 评论于 5 年前
所有者

By the way, did you think about GPG signing?

By the way, did you think about GPG signing?
MicheleC5 年前 添加了里程碑 R14.0.6 release
MicheleC 评论于 5 年前
所有者

Fabio, when you create the other 64 PRs of this type, please add the milestone R14.0.6 to them, since we will also backport this change to the current stable branch.

And keep up the good work :-) 👍

Fabio, when you create the other 64 PRs of this type, please add the milestone R14.0.6 to them, since we will also backport this change to the current stable branch. And keep up the good work :-) :+1:
efferre 评论于 5 年前
发布者
协作者

I have completed the pull requests targeting to milestone R14.0.6.

Right now I am not using GPG, in case I'll consider it in the future.

I have completed the pull requests targeting to milestone R14.0.6. Right now I am not using GPG, in case I'll consider it in the future.
MicheleC5 年前 关闭此合并请求
MicheleC5 年前 删除了分支 feat/linker_flags
该合并请求已作为 d8177b4058 被合并。
登录 并参与到对话中。
无审核者
未选择里程碑
未指派成员
3 名参与者
通知
到期时间

未设置到期时间。

依赖工单

没有设置依赖项。

参考:TDE/tdelibs#10
正在加载...
这个人很懒,什么都没留下。