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

Centos7: Cmake 2.8 support #35

Closed
bbczeuz opened this issue Feb 23, 2017 · 7 comments
Closed

Centos7: Cmake 2.8 support #35

bbczeuz opened this issue Feb 23, 2017 · 7 comments

Comments

@bbczeuz
Copy link
Contributor

bbczeuz commented Feb 23, 2017

Hi,
I was trying to build the lib on Centos7. This OS ships with cmake 2.8.12
I KNOW this is an old version and is missing many nice features, but Centos7 is the newest free edition of the probably most widely used GNU/Linux distribution in an enterprise environment. So: How about keeping compatibility with Centos7? (Centos7 ships with libcurl 35, dated, but again: probably most widely used, gcc is 4.8.5 with about 95% completeness of C++11 support)
I can try to create a CMakeList.txt for cmake 2.8, but wonder about your plans to keep support for this edition? Redhat plans to provide production support for RHEL7 until 2024.

@cronnosli
Copy link

bbczeuz,

Did you tried to install a newer cmake and gcc on your centos ?
yum install epel-release
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install cmake3

You cannot maintain modern packages on RedHat without use EPEL.
This is not a problem of this project it will affect a lot of modern projects.

Anyway where did you get the numbers regarding the most widely used GNU/Linux distribution in an enterprise environment?

If you want to run Centos/RedHat as it is, in his natural state. So be prepared to not need to compile any packages on it!

@bbczeuz
Copy link
Contributor Author

bbczeuz commented Feb 23, 2017

Hi,
The main question is still open: How about supporting cmake 2.8? (Actually I've already adapted the file to support 2.8)

About the rest:

  • Centos/Rhel numbers: Personal experience. ALL companies (CH/D/US) that I've done projects for were using these distributions for infrastructure services (i.e. servers, appliances). rhel5-7, are all active these days (rhel5 is a pain, and will run out of support, but that doesn't mean that people have migrated)
  • Adding an epel dependency is all to often a no-go. Many people operate their own Satellite for package distribution; supplying an isolated environment (i.e. no external repos). Epel could be mirrored there, too, but chances are like 0%.
  • We plan to package it, so epel will only be needed on the packaging and test machines, but anyhow: that is just additional work.

@jpbarrette
Copy link
Owner

jpbarrette commented Feb 24, 2017

I see no reason why we couldn't support CMake 2.8 for unix-family platforms. I'll try to submit patch soon. However, if you already have a patch that you could send me, it would be even better.

Note that I'll do that change only for unix-family platforms, but not for Windows Platform since I don't see the same gain from supporting 2.8 for that platform (we rely on CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS for exporting symbols, to simplify the source code which requires 3.4)

@jpbarrette
Copy link
Owner

Please have a look at branch https://github.com/jpbarrette/curlpp/tree/feature/cmake-2.8-support and tell me if you have problems or if you would do it differently.

@jpbarrette
Copy link
Owner

Please can you confirm that https://github.com/jpbarrette/curlpp/releases/tag/v0.8.1-beta.2 fixes your issue? As soon as you confirm, I'll be able to release the new version.

@bbczeuz
Copy link
Contributor Author

bbczeuz commented Feb 28, 2017 via email

@bbczeuz
Copy link
Contributor Author

bbczeuz commented Feb 28, 2017

Thanks for the patch. I successfully built the lib on Centos6. Actually my branch had a similar path fix as you now added using the GNUInstallDirs include :)
I was thinking about using the cleaner and possibly more portable syntax of Cmake 3.1 instead of using add_compile_options: https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html
...but haven't succeeded in finding all the correct flags for the features used, so I merged your original CXX_STANDARD back in. See PR #37

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants