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

CMake fixes + CMake search for OpenSSL (macOS) #1383

Merged
merged 13 commits into from Apr 24, 2020

Conversation

Clovel
Copy link
Contributor

@Clovel Clovel commented Apr 5, 2020

  • Homebrew sometimes appends the version of a package to it' directory name. Thus, one could have /usr/local/Cellar/openssl@1.1/ instead of /usr/local/Cellar/openssl/, or even both. I fixed the search for OPENSSL_ROOT_DIR and limited it's contents to one path only.
  • Added the <package>-config-version.in.cmake file configuration for CMake find_package usage.
  • Corrected condition in <package>-config.in.cmake for Boost usage. There was a @CPPREST_USES_BOOST@ AND OFF condition, which is always false. The result was that the Boost libraries and includes were not included in the users CMake project.
  • Use CMAKE_INSTALL_INCLUDEDIR to install headers. cpprestsdk already uses CMAKE_INSTALL_LIBDIR & CMAKE_INSTALL_BINDIR

@msftclas
Copy link

msftclas commented Apr 5, 2020

CLA assistant check
All CLA requirements met.

@Clovel Clovel changed the title CMake typo fixes + CMake search for OpenSSL (macOS) CMake fixes + CMake search for OpenSSL (macOS) Apr 5, 2020
Signed-off-by: Clovis Durand <cd.clovel19@gmail.com>
Signed-off-by: Clovis Durand <cd.clovel19@gmail.com>
…ig.in.cmake

Signed-off-by: Clovis Durand <cd.clovel19@gmail.com>
Signed-off-by: Clovis Durand <cd.clovel19@gmail.com>
@garethsb
Copy link
Contributor

garethsb commented Apr 7, 2020

  • Corrected condition in <package>-config.in.cmake for Boost usage. There was a @CPPREST_USES_BOOST@ AND OFF condition, which is always false. The result was that the Boost libraries and includes were not included in the users CMake project.

See this commit and the comment upon it... fc1f692

@Clovel
Copy link
Contributor Author

Clovel commented Apr 7, 2020

  • Corrected condition in <package>-config.in.cmake for Boost usage. There was a @CPPREST_USES_BOOST@ AND OFF condition, which is always false. The result was that the Boost libraries and includes were not included in the users CMake project.

See this commit and the comment upon it... fc1f692

Comments on a lone commits will be lost in the mass of the project. I still commented.

People need this to use find_package(cpprestsdk). If this stays in master, we must change the CMake instructions to add Boost requirements.

And

And anyway :

  1. If this causes problems with versions of CMake before 3.9, then add that as a condition instead.
  2. If cpprestsdk requires Boost, then we must keep Boost as a CMake requirement. If there are issues, then the project must be fixed.
    This repair only hides the problem. And the cpprestsdk instructions are to up to date to take this into account. A work around must be described for users of this project.

@Clovel
Copy link
Contributor Author

Clovel commented Apr 7, 2020

I don't have time to look into the whole issue. I tried to use cpprestsdk for one of my projects. If this repository's project doesn't work as intended, I won't use it. CMake is a widely used build tool. A project like cpprestsdk should have a working CMake package mechanism.

It should also have a GitHub Action for macOS.

@garethsb
Copy link
Contributor

garethsb commented Apr 7, 2020

I agree with you, I commented because in the time I invested in reviewing your changes I found that (lost) background.

@Clovel
Copy link
Contributor Author

Clovel commented Apr 7, 2020

I agree with you, I commented because in the time I invested in reviewing your changes I found that (lost) background.

Somebody needs to find what the cause of the issue is, so that this can be patched.

Thanks for researching the background of this change.

@garethsb
Copy link
Contributor

garethsb commented Apr 8, 2020

  • Added the <package>-config-version.in.cmake file configuration for CMake find_package usage.

I've been missing having the version info available for a long time. The find_package docs seem to indicate there are more variables we should/could set. I wonder if we can use write_basic_package_version_file to do it?

@Clovel
Copy link
Contributor Author

Clovel commented Apr 8, 2020

I think the result is the same. My solution is inspired by the files I found on my computer for the Qt CMake Version files. I took a look at other projects that implement this the way I did.

If you believe there is another, better way to do this, I’ll take a look.

However, the link you gave seems to describe a relatively similar method to generate the configuration file.

@garethsb
Copy link
Contributor

garethsb commented Apr 9, 2020

I think the result is the same.

Ah yes, sorry, I realise your code must ultimately be derived from same root as current CMake config version file template for COMPATIBILITY AnyNewerVersion - https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in

I'm not sure on C++ REST SDK backward compatibility policy between major/minor releases but maybe SameMajorVersion is appropriate for it?

@Clovel
Copy link
Contributor Author

Clovel commented Apr 9, 2020

I'm not sure on C++ REST SDK backward compatibility policy between major/minor releases but maybe SameMajorVersion is appropriate for it?

Maybe. I'm not familiar enough with the project to know, sorry.

@c72578
Copy link
Contributor

c72578 commented Apr 9, 2020

COMPATIBILITY AnyNewerVersion is often preferred in upstream projects and causes less (sometimes needless) downstream issues. The primary goal is usually to just provide the version for cmake and not to restrict things. Downstream projects, which use cpprestsdk can still implement a version check, if they need to.

@garethsb
Copy link
Contributor

garethsb commented Apr 22, 2020

I agree with you, I commented because in the time I invested in reviewing your changes I found that (lost) background.

Somebody needs to find what the cause of the issue is, so that this can be patched.

Thanks for researching the background of this change.

See #593 - the issue is the use of COMPONENTS in find_dependency which wasn't supported before CMake 3.9 (released 2017). I agree it would be better to bump minimum required version from 3.1 (released 2014) to >=3.9 and delete the AND OFF.

@Clovel, how do you think about bumping cmake_minimum_required to 3.9 in this PR? It should be done in Release/CMakeLists.txt of course, but preferably also (root) CMakeLists.txt, README.md (example) and there's also Build_iOS/CMakeLists.txt.

👍

@Clovel
Copy link
Contributor Author

Clovel commented Apr 22, 2020 via email

@Clovel
Copy link
Contributor Author

Clovel commented Apr 22, 2020

@Clovel, how do you think about bumping cmake_minimum_required to 3.9 in this PR? It should be done in Release/CMakeLists.txt of course, but preferably also (root) CMakeLists.txt, README.md (example) and there's also Build_iOS/CMakeLists.txt.

Done.

@garethsb
Copy link
Contributor

Great. What do you think about updating the cmake_minimum_required in the README.md as well?

We need @BillyONeal's review now. :-)

Signed-off-by: Clovis Durand <cd.clovel19@gmail.com>
@Clovel
Copy link
Contributor Author

Clovel commented Apr 22, 2020

Great. What do you think about updating the cmake_minimum_required in the README.md as well?

I missed that. Fixed it.

@BillyONeal
Copy link
Member

If you're trying to fix macos can you turn that back on in azure-pipelines.yml?

@garethsb
Copy link
Contributor

garethsb commented Apr 22, 2020

FWIW, Homebrew was excised in c813671.

And the other macOS test configs were removed in 3a3cc20.

Signed-off-by: Clovis Durand <cd.clovel19@gmail.com>
@Clovel
Copy link
Contributor Author

Clovel commented Apr 23, 2020

If you're trying to fix macos can you turn that back on in azure-pipelines.yml?

Done.

EDIT : I'm trying to fix the CMake build on macOS, amongst other things. I might revert this and leave it for another PR if it blocks merging.

@BillyONeal
Copy link
Member

#1392 might fix it

@garethsb
Copy link
Contributor

I was about to say I couldn't see where the submodule was checked out! Thanks, @BillyONeal!

Copy link
Contributor

@c72578 c72578 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The .exe extension should be removed from ninja.exe in case of osx

- task: CMake@1
inputs:
workingDirectory: 'build.release'
cmakeArgs: '-G Ninja -DCMAKE_MAKE_PROGRAM=../vcpkg/downloads/tools/ninja-1.10.0-osx/ninja.exe -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../vcpkg/scripts/buildsystems/vcpkg.cmake ..'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ninja-1.10.0-osx/ninja.exe->ninja-1.10.0-osx/ninja

cmakeArgs: '-G Ninja -DCMAKE_MAKE_PROGRAM=../vcpkg/downloads/tools/ninja-1.10.0-osx/ninja.exe -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../vcpkg/scripts/buildsystems/vcpkg.cmake ..'
- script: |
cd build.debug
../vcpkg/downloads/tools/ninja-1.10.0-osx/ninja.exe
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ninja-1.10.0-osx/ninja.exe->ninja-1.10.0-osx/ninja

displayName: 'Run Tests debug'
- script: |
cd build.release
../vcpkg/downloads/tools/ninja-1.10.0-osx/ninja.exe
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ninja-1.10.0-osx/ninja.exe->ninja-1.10.0-osx/ninja

- task: CMake@1
inputs:
workingDirectory: 'build.debug'
cmakeArgs: '-G Ninja -DCMAKE_MAKE_PROGRAM=../vcpkg/downloads/tools/ninja-1.10.0-osx/ninja.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=../vcpkg/scripts/buildsystems/vcpkg.cmake ..'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ninja-1.10.0-osx/ninja.exe->ninja-1.10.0-osx/ninja

@BillyONeal
Copy link
Member

Megaderp :)

@BillyONeal
Copy link
Member

@Clovel iOS is still toast. Do you want to investigate that or just disable it?

@BillyONeal
Copy link
Member

The .exe extension should be removed from ninja.exe in case of osx

Fixed!

@Clovel
Copy link
Contributor Author

Clovel commented Apr 24, 2020

@Clovel iOS is still toast. Do you want to investigate that or just disable it?

I’ll take a look in the coming days. If I don’t feel it, I’ll disable the build plan.

@BillyONeal
Copy link
Member

@Clovel iOS is still toast. Do you want to investigate that or just disable it?

I’ll take a look in the coming days. If I don’t feel it, I’ll disable the build plan.

This passed so I'll merge and do a release, if you end up fixing it that'd be much appreciated :)

@BillyONeal BillyONeal merged commit 319dd31 into microsoft:master Apr 24, 2020
@BillyONeal
Copy link
Member

Thanks for your contribution!

schultetwin1 pushed a commit to schultetwin1/cpprestsdk that referenced this pull request Apr 29, 2020
PR microsoft#1383 switched to use ${CMAKE_INSTALL_INCLUDEDIR} as the destination
to install cpprestsdk headers.

That change did not update the INTSTALL_INTERFACE for the cpprest target
and also did not update all the places where the include directory was
hard coded.
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

Successfully merging this pull request may close these issues.

None yet

5 participants