Allow for Debian 11 and Ubuntu 22.04 LTS support with lower version of CMake

[vikasnkumar]

CMake 3.30 is too strict and the code builds just fine on Cmake 3.18 and 3.22 which are on Debian 11 and Ubuntu 22.04 LTS.

The library has been in existence for decades and forcing it to only work on most recent CMake's is a detriment to long term users and downstream applications that use this library.

[mario4tier]

I know. It is a dilemma and had to make a though call.

Why 3.30?
The minimum needed to get the .msi generation (CPack) to work for windows.

Why bending to windows?
I will be a bit judgmental here: window users typically struggle more for building the lib, so the .msi is a big step forward to them. On the opposite side, Linux devs often have more "technical agility".

Here are some alternatives for Linux:

• autotools works
• the release now includes multiple .deb variant... and .rpm is next.
• Personally, I did work around this by building the latest CMake on my ubuntu machine (was not hard to do).
• There is no "forcing": 0.4.0 is still usable until the distributions catch-up.

Alternatives?

I did not succeed to get CMakeLists specify different minimum version (base on platform)... and will welcome a PR that makes that possible.

Will revisit for unusual solutions (e.g. maintain two CMakeLists.txt files?) only if many complains or it is blocking to the large ta-lib-python crowd.

May be you can submit a comment in the CMakeLists.txt with your statement that it works with as low as 3.18 on Debian/Ubuntu.

[vikasnkumar]

Hi @mario4tier
I want to respectfully push back on a lot of your statements.

1. the ta-lib-python is not the only crowd. You have the R programming language and the Perl programming language (which I have been supporting via Alien-TALib and PDL-Finance-TA for over 11 years). All of these just use the core C library and wrap it. We are also your "customers". Perl is supported on Windows, MacOS and all the BSDs. Edit: Perl has something called Perl Data Language or PDL and it has a big user base.
2. Version 0.6.0 has been out on Sourceforge for a long time (IIRC more than 4 years), and we were using that directly until yesterday when I switched to the Git repo since Sourceforge downloads are unreliable. Pushing version back to 0.4.0 is not an acceptable solution or a workaround, so I think you should stop suggesting that to anyone.
3. Debian and Ubuntu have removed ta-lib from their repositories btw. In the old days, say in Debian 9, you could get 0.4.0 but in Debian 11 it is not available as a package nor is it on Ubuntu 22.04 LTS which a lot of servers run.
4. Autotools may work in many cases but a lot of projects also integrate ta-lib via CMake since it allows nesting within other CMake projects very easily. That's how I use it since it is more reliable for making Windows and MacOS builds for the Perl wrapper.
5. Building latest CMake every time to use a simple library like ta-lib is not a solution either for supporting a variety of systems with a variety of packaging setups, and is just unnecessary.

Here is my suggestion:

• have a lower CMake for most of your CMake. 3.18 is probably sufficient since it handles most use cases.

• It is highly unlikely that your Windows user who "struggles to get ta-lib built" will have an old CMake. You can enforce them to get a newer CMake by doing a CMAKE_VERSION variable check.

• detect if the user has a higher CMake by checking CMAKE_VERSION variable and invoke the CPack MSI generation then. This is where you can do an IF(WIN32) call. I was surprised that you said this since CPack has been around CMake 2.xx and I have been using CMake since CMake 1.6 (since 2004) so I cannot imagine what you are doing with MSI generation is suddenly so new that it needs the latest version. CPack was there 12 years ago in CMake for building Windows installers.

[vikasnkumar]

Hi @mario4tier

I updated the PR just now to handle the Windows 3.30 requirement.

Thanks.

[mario4tier]

The .msi is produced by the more recent Wix5 toolset which is supported only by the more recent version of CMake. Specifying the higher version is not without reason.

Just to be clear, I did not meant in my response to diminish the importance of your apps. It was a tough choice for me to choose who it will break for.

Thanks for the contribution, I will merge your change (may be tomorrow). I need first to change the github action to modify the CMakeLists.txt for when building for windows.

[vikasnkumar]

thanks. I appreciate what you and your team does. Let me know if you need help with anything related to supporting other languages with TA-Lib. I hope to keep maintaining it for another ten years in Perl at least.

…

On Tue, Dec 24, 2024, at 1:35 PM, Mario Fortier wrote: The .msi is produced by the more recent Wix5 toolset which is supported only by the more recent version of CMake. Specifying the higher version is not without reason. Just to be clear, I did not meant in my response to diminish the importance of your apps. It was a tough choice for me to choose who it will break for. Thanks for the contribution, I will merge your change (may be tomorrow). I need first to change the github action to modify the CMakeLists.txt for when building for windows. — Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAC6WHQOZEWJBML6QHTTMT2HGSNRAVCNFSM6AAAAABUEAVLJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRRGM2DANRUGQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>