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

Fix same bug, add cmake to ci, refactor cmake #177

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

KangLin
Copy link
Contributor

@KangLin KangLin commented Jul 23, 2020

No description provided.

@KangLin KangLin force-pushed the master branch 15 times, most recently from 45dcb38 to 84e9a17 Compare July 24, 2020 07:52
@KangLin KangLin changed the title Refactor cmake Fix same bug, add cmake to ci, Refactor cmake Jul 29, 2020
@KangLin KangLin changed the title Fix same bug, add cmake to ci, Refactor cmake Fix same bug, add cmake to ci, refactor cmake Jul 29, 2020
@ftylitak
Copy link
Owner

@KangLin thank you very much for your contribution. As soon as you are done with the changes, poke me for a review.

@KangLin KangLin force-pushed the master branch 2 times, most recently from e22865e to 038f606 Compare September 11, 2020 04:49
@ftylitak
Copy link
Owner

@KangLin thank you for the changes to the minimum version of cmake!

Since I do not personally use cmake, to complete the review I would kindly request from people that already use QZXing with cmake in their project to give it a try.

@dobey and @Milerius , would it be possible to try the proposed CMakelist from this Pull Request to your projects? Does it affect you in any way?

I really appreciate the help and effort from all of you!

Kind regards.


option(QZXING_QML "Use qml" ${QZXING_QML})
if(QZXING_QML)
target_sources(${PROJECT_NAME} PRIVATE QZXingImageProvider.cpp QZXingImageProvider.h)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you also need to add target_compile_definitions(${PROJECT_NAME} PRIVATE QZXING_QML) in here as well, as I'm still having to add_definitions() for it to be built.

Copy link
Contributor Author

@KangLin KangLin Sep 18, 2020

Choose a reason for hiding this comment

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

I don't understand why you use this? You only set -DQZXING_QML=ON or -DQZXING_MULTIMEDIA=ON when run cmake configure.
When run cmake configure. It is default is ON.
You only add follow code in your CMakeLists.txt:

    find_package(QZXing)
    add_executable(YOUR_PROJECT)
    target_link_libraries(${PROJECT_NAME} QZXing)

If you use qzxing source code in your project:

add_subdirectory(${QZXing_DIR}/src ${CMAKE_BINARY_DIR}/QZXing)
target_link_libraries(${PROJECT_NAME} PUBLIC QZXing)

Copy link
Contributor

@dobey dobey Sep 18, 2020

Choose a reason for hiding this comment

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

Setting only QZXING_QML=ON doesn't work because you are not setting the necessary build define to trigger the feature in the code. Thus, I still have to do add_definitions(-DQZXING_XML) in order to get the code compiled properly, otherwise there is API missing from the resulting library.

For QZXING_MULTIMEDIA it is fine, because you added the target_compile_definitions() for it in this CMakeLists.txt when it is enabled. But the target_compile_definitions() is missing for the QZXING_QML feature.

Copy link
Contributor Author

@KangLin KangLin Sep 20, 2020

Choose a reason for hiding this comment

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

The QZXING_QML is added in follow code:

LIST(APPEND EXPORT_DEFINES QZXING_QML)
# Export defines by configure_file
target_compile_definitions(${PROJECT_NAME} PUBLIC ${EXPORT_DEFINES})

This is modified in the commit later. Please read all commits.

Copy link
Contributor Author

@KangLin KangLin Sep 20, 2020

Choose a reason for hiding this comment

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

See commit 4b67917

@dobey
Copy link
Contributor

dobey commented Sep 17, 2020

would it be possible to try the proposed CMakelist from this Pull Request to your projects? Does it affect you in any way?

Had to make a few other changes to get things building again with the changes, and I still had to manually add a compile definition (which I mentioned in an inline comment). And I'm not sure why the default build was changed from static to shared here.

But it looks mostly OK otherwise.

@KangLin
Copy link
Contributor Author

KangLin commented Sep 18, 2020

would it be possible to try the proposed CMakelist from this Pull Request to your projects? Does it affect you in any way?

Had to make a few other changes to get things building again with the changes, and I still had to manually add a compile definition (which I mentioned in an inline comment). And I'm not sure why the default build was changed from static to shared here.

But it looks mostly OK otherwise.

@dobey If you need static library, please set -DBUILD_SHARED_LIBS=OFF. Please see the README.md of changed.

@dobey
Copy link
Contributor

dobey commented Sep 18, 2020

@dobey If you need static library, please set -DBUILD_SHARED_LIBS=OFF. Please see the README.md of changed.

Yes, I understood this. What I meant was, is that it's not clear from this merge request why it's being changed to be an installed shared library, or why the library name was changed to the capitalized version (beyond the fact that the project(QZXing) line was not changed, I mean). There's no description of rationale for the changes in the PR description, nor any linked issue ticket to refer to and understand why the changes are being made.

@KangLin
Copy link
Contributor Author

KangLin commented Sep 20, 2020

@dobey If you need static library, please set -DBUILD_SHARED_LIBS=OFF. Please see the README.md of changed.

Yes, I understood this. What I meant was, is that it's not clear from this merge request why it's being changed to be an installed shared library, or why the library name was changed to the capitalized version (beyond the fact that the project(QZXing) line was not changed, I mean). There's no description of rationale for the changes in the PR description, nor any linked issue ticket to refer to and understand why the changes are being made.

  1. I had add dll in cmake and pro.
  2. Modern systems generally use dynamic libraries. Because it can reduce the size of the application.

If you do not want to change, please comment the following line:

SET(BUILD_SHARED_LIBS ON CACHE BOOL "Build shared libs")

@dobey
Copy link
Contributor

dobey commented Sep 23, 2020

If you do not want to change, please comment the following line:

OK. This is problematic. Even when I have done set(BUILD_SHARED_LIBS OFF) in my CMakeLists.txt before including the qzxing subdirectory, it is still building qzxing as a shared lib, and is installing the library and headers with make install, which is not acceptable. Also the SO version seems wrong for the shared library build. The following lines appear when I do (cd build && make DESTDIR=/tmp/install install) in my app using qzxing:

-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/libQZXing.so.4.0.1-1-ga432920
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/libQZXing.so
-- Installing: /tmp/install/usr/include/QZXing.h
-- Installing: /tmp/install/usr/include/QZXing_global.h
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/cmake/QZXing/QZXingConfig.cmake
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/cmake/QZXing/QZXingConfig-coverage.cmake
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/cmake/QZXing/QZXingConfigVersion.cmake
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/pkgconfig/QZXing.pc

Copy link
Contributor

@dobey dobey left a comment

Choose a reason for hiding this comment

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

Needs to not install headers, pkgconfig file, or shared objects (nor build them) when BUILD_SHARED_LIBS is set to off.

@KangLin
Copy link
Contributor Author

KangLin commented Sep 24, 2020

If you do not want to change, please comment the following line:

OK. This is problematic. Even when I have done set(BUILD_SHARED_LIBS OFF) in my CMakeLists.txt before including the qzxing subdirectory, it is still building qzxing as a shared lib, and is installing the library and headers with make install, which is not acceptable. Also the SO version seems wrong for the shared library build. The following lines appear when I do (cd build && make DESTDIR=/tmp/install install) in my app using qzxing:

-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/libQZXing.so.4.0.1-1-ga432920
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/libQZXing.so
-- Installing: /tmp/install/usr/include/QZXing.h
-- Installing: /tmp/install/usr/include/QZXing_global.h
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/cmake/QZXing/QZXingConfig.cmake
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/cmake/QZXing/QZXingConfig-coverage.cmake
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/cmake/QZXing/QZXingConfigVersion.cmake
-- Installing: /tmp/install/usr/lib/x86_64-linux-gnu/pkgconfig/QZXing.pc

This is wrong usage. -DBUILD_SHARED_LIBS=OFF can only be specified on the command line:

cmake . -DBUILD_SHARED_LIBS=OFF 

@KangLin
Copy link
Contributor Author

KangLin commented Sep 24, 2020

Needs to not install headers, pkgconfig file, or shared objects (nor build them) when BUILD_SHARED_LIBS is set to off.

See a68853c

@KangLin
Copy link
Contributor Author

KangLin commented Oct 2, 2020

@ftylitak Please merge it.

@dobey
Copy link
Contributor

dobey commented Oct 2, 2020

Sorry, I've been very busy and haven't been able to look deeper into this again, but please do not merge this yet. I don't need to be having headers and pkgconfig and shared libraries installed along with my apps when I'm explicitly telling qxzing to build static (as it was doing automatically already before).

It still also seems to be a lot of changes mixed together with no specific rationale as to why each individual part is being done, or why they all need to be done at once in a single large change.

@ftylitak
Copy link
Owner

ftylitak commented Oct 5, 2020

@dobey thank you for your excellent review. I agree with your concerns. Within this week I will try to find the most convenient approach to not change the default behavior that the library already has while getting the benefits from @KangLin work.

Thank you both.

@KangLin
Copy link
Contributor Author

KangLin commented Oct 9, 2020

Sorry, I've been very busy and haven't been able to look deeper into this again, but please do not merge this yet. I don't need to be having headers and pkgconfig and shared libraries installed along with my apps when I'm explicitly telling qxzing to build static (as it was doing automatically already before).

It still also seems to be a lot of changes mixed together with no specific rationale as to why each individual part is being done, or why they all need to be done at once in a single large change.

It is recommended that you use it as an external library, When you are use cmake.
If you must use it as embed the source code. you use cmake --build . --target install-runtime. It will not install the development library.

@dobey
Copy link
Contributor

dobey commented Oct 9, 2020

Sorry, I've been very busy and haven't been able to look deeper into this again, but please do not merge this yet. I don't need to be having headers and pkgconfig and shared libraries installed along with my apps when I'm explicitly telling qxzing to build static (as it was doing automatically already before).
It still also seems to be a lot of changes mixed together with no specific rationale as to why each individual part is being done, or why they all need to be done at once in a single large change.

It is recommended that you use it as an external library, When you are use cmake.
If you must use it as embed the source code. you use cmake --build . --target install-runtime. It will not install the development library.

The README talks specifically about embedding qzxing and your changes here expressly break that. Your adding of BUILD_SHARED_LIBS as a cache option overrides the internal CMake value. Removing the line you've added results in a static lib. Instead, you can pass -DBUILD_SHARED_LIBS=on when building if what you want is a shared lib. When it's not set to ON, I think no files should be installed. If I had to specify -DBUILD_SHARED_LIBS=OFF then I'm pretty sure that would break Android builds for my apps, considering for Android the app must be built as a shared object. There's also no need to change the output directories when building.

@KangLin
Copy link
Contributor Author

KangLin commented Oct 10, 2020

The README talks specifically about embedding qzxing and your changes here expressly break that. Your adding of BUILD_SHARED_LIBS as a cache option overrides the internal CMake value. Removing the line you've added results in a static lib. Instead, you can pass -DBUILD_SHARED_LIBS=on when building if what you want is a shared lib. When it's not set to ON, I think no files should be installed. If I had to specify -DBUILD_SHARED_LIBS=OFF then I'm pretty sure that would break Android builds for my apps, considering for Android the app must be built as a shared object. There's also no need to change the output directories when building.

You misunderstood. BUILD_SHARED_LIBS only controls whether to generate dynamic libraries. The installation target is controlled by the INSTALL command. See: https://cmake.org/cmake/help/latest/command/install.html?highlight=install#targets

Your android program should modify the installation target and add COMPONENT. The qzxing has add COMPONENT Runtime. You can refer to the modification.

@KangLin
Copy link
Contributor Author

KangLin commented Oct 21, 2020

@ftylitak Please merge it. The commit do not change the default behavior .

@dobey
Copy link
Contributor

dobey commented Oct 21, 2020

You misunderstood. BUILD_SHARED_LIBS only controls whether to generate dynamic libraries.

No. I did not misunderstand. Your adding it as a cache option breaks the default behavior of cmake. Setting it to OFF does not result in a static qxzing build. I tried it. I had to remove it from your changes to get a static build. You also aren't using it or any other option as a determination to install development files or not. I shoudn't need to patch qzxing to keep the same behavior that I have now when building my application with a static qzxing from git.

There is still no specified issue that this claims to fix, nor does it provide any specific rationale for the many changes. IMO it needs to at least be split up (add CI builds in one change, open issues for whatever bug(s) your'e referring to, and then maybe do refactoring if necessary separately). As it is, this is a massive set of changes which breaks current and expected behavior for developers embedding qzxing in their applications.

ftylitak added a commit that referenced this pull request May 6, 2021
Integration of code parts from #177 provided by @KangLin to fix CI
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.

4 participants