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

Merged
MicheleC merged 1 commits from feat/linker_flags into master 4 months ago
efferre commented 4 months ago

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 commented 4 months ago
Poster

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 commented 4 months ago
Owner

@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 commented 4 months ago
Poster

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 commented 4 months ago
Owner

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 commented 4 months ago
Owner

By the way, did you think about GPG signing?

By the way, did you think about GPG signing?
MicheleC added this to the R14.0.6 release milestone 4 months ago
MicheleC commented 4 months ago
Owner

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:

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 commented 4 months ago
Poster

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.
MicheleC deleted branch feat/linker_flags 4 months ago
The pull request has been merged.
Sign in to join this conversation.
Loading…
Cancel
Save
There is no content yet.