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

add msix/1.7 #6475

Merged
merged 18 commits into from
Sep 29, 2021
Merged

add msix/1.7 #6475

merged 18 commits into from
Sep 29, 2021

Conversation

vaerizk
Copy link
Contributor

@vaerizk vaerizk commented Jul 23, 2021

msix/1.7

  • I've read the guidelines for contributing.
  • I've followed the PEP8 style guides for Python code in the recipes.
  • I've used the latest Conan client version.
  • I've tried at least one configuration locally with the
    conan-center hook activated.

@conan-center-bot

This comment has been minimized.

@vaerizk
Copy link
Contributor Author

vaerizk commented Jul 23, 2021

@SSE4 @uilianries @madebr

Is there a possibility to use a dependency with non-default value for some options? My build failed because we need char_type=char16_t for xerces-c and the default value is different.

@uilianries
Copy link
Member

@SSE4 @uilianries @madebr

Is there a possibility to use a dependency with non-default value for some options? My build failed because we need char_type=char16_t for xerces-c and the default value is different.

Unfortunately not. What you can do is changing the default option if it's invalid and cause all packages invalid.

Please, follow @Croydon review.

"crypto_lib": ["crypt32", "openssl"],
"pack": [True, False],
"skip_bundles": [True, False],
"use_external_zlib": [True, False],
Copy link
Contributor

Choose a reason for hiding this comment

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

We want to always use external libs.
Using a an included/included vendored zlib will open the possibility of having some symbols available twice.
The linker can then choose symbols from msix or from zlib.

So please remove this option and always use external zlib (=our cci package)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This option allows to choose system libraries for compression when building on some platforms:

set(COMPRESSION_LIB "zlib")
if(((IOS) OR (MACOS)) AND (NOT USE_EXTERNAL_ZLIB))
    set(COMPRESSION_LIB "libCompression")
elseif((AOSP) AND (NOT USE_EXTERNAL_ZLIB))
    set(COMPRESSION_LIB "inbox zlib")
endif()

If this option is on, the zlib package from CCI will be used.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The upstream didn't rename the variable, we did it so that it reflects the idea that when it's on, the build will use the external (CCI) package for zlib. The original name and description is:

option(USE_MSIX_SDK_ZLIB "Use zlib implementation under lib/zlib. If off, uses inbox compression library. For Windows and Linux this is no-opt." OFF)

The modified version:

option(USE_EXTERNAL_ZLIB "Use an external zlib package. If off, uses inbox compression library. For Windows and Linux this is no-opt." OFF)

Copy link
Contributor

Choose a reason for hiding this comment

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

Vendored libraries are often provided for users without package manager as a way to quickly get building without building all dependencies.
We're using conan here with the cci library. So I think it's best to remove this option and unconditionally disable using a vendored zlib.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

By the term "vendored" we meant libraries whose sources had been made a part of the library, when I wrote about system zlib I meant these ones:

https://developer.android.com/ndk/guides/stable_apis#zlib_compression

https://developer.apple.com/documentation/compression

https://github.com/microsoft/msix-packaging/blob/3fbd28851b0ac525324781ec20634a2f0515c0ef/src/msix/CMakeLists.txt#L292_L298

We can omit these possibilities, shall we?

Copy link
Contributor

Choose a reason for hiding this comment

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

What we want to avoid (at all cost) is to use the vendored zlib here: https://github.com/microsoft/msix-packaging/blob/5f977a79d4f2bd189c1d99ae8f501316a282191a/lib/CMakeLists.txt#L22

Does the current combination of options + patches completely avoid that?

Copy link
Contributor

Choose a reason for hiding this comment

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

Does the current combination of options + patches completely avoid that?

The current patch completely removes processing of the lib subdirectory:

conan-center-index/cmake.patch at a3144aa · conan-io/conan-center-index
https://github.com

Copy link
Contributor

Choose a reason for hiding this comment

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

As point out the patch delete the usage of this option so it can be removed from the recipe!

Suggested change
"use_external_zlib": [True, False],

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The option hasn't been deleted, the commit just reverts it's name to the original one.

@vaerizk
Copy link
Contributor Author

vaerizk commented Jul 26, 2021

Unfortunately not. What you can do is changing the default option if it's invalid and cause all packages invalid.

@uilianries What do you mean by "cause all packages invalid"? Are you talking about the case when the default option value doesn't satisfy any dependent package?

According to xerces-c cmake-files, for any compiler that supports char16_t this type will be chosen as the default for char_type, so we could choose char16_t as the default value. But there are two packages in CCI that depend on xerces-c atm: quickfast and gdal. If we change the default for char_type in xerces-c, it may break the build for these libraries.

@vaerizk vaerizk closed this Jul 26, 2021
@vaerizk
Copy link
Contributor Author

vaerizk commented Jul 26, 2021

Accidentally closed.

@vaerizk vaerizk reopened this Jul 26, 2021
@conan-center-bot

This comment has been minimized.

Croydon and others added 4 commits July 27, 2021 20:05
- polish the `source` method
- add required conan version
- fix the `crypto_lib` option
- add `msxml6` to the list of system libraries
@conan-center-bot

This comment has been minimized.

- move configuration checks to `validate()`
- restrict the package
@conan-center-bot

This comment has been minimized.

@vaerizk
Copy link
Contributor Author

vaerizk commented Aug 11, 2021

@jgsogo

About missing binaries:

done

@jgsogo
Copy link
Contributor

jgsogo commented Aug 12, 2021

@jgsogo

About missing binaries:

done

Hi! Sorry, maybe I did assume some implicit knowledge of how CCI works and I didn't explain myself. People are contributing to ConanCenter continuously, everyone is doing a great job, but recipes evolve and things might be broken from time to time. We try to think about ConanCenter as a whole and sometimes some PRs need to wait for other issues to be fixed and maximize the value for a given effort.

In this case, you shouldn't prevent your recipe from using openssl in Macos, it was just a request to fix that recipe and someone did it: #6588. So now, you should remove that ConanInvalidConfiguration because it is no longer a missing package. 😃

About the xerces-c issue. Here in CCI we are only building packages with the default options (for many different configurations), it is just because we cannot afford to build all the combinations.... but I'm sure that this recipe would work with other options rather than the default ones. Users at home might build it from sources so the recipe shouldn't block them. Here:

        # the current CCI xerces-c recipe is not supported
        if (self.options.xml_parser == "xerces" and
            self.options["xerces-c"].char_type != "char16_t"):
                raise ConanInvalidConfiguration("Only char16_t is supported for xerces-c")

this recipe will block those users that are building from sources. If that combination of requirements and options work, don't raise the exception, someone locally might need to use it.

Copy link
Contributor

@jgsogo jgsogo left a comment

Choose a reason for hiding this comment

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

(Following previous comment)

recipes/msix/all/conanfile.py Outdated Show resolved Hide resolved
recipes/msix/all/conanfile.py Outdated Show resolved Hide resolved
- polish the recipe
- remove the restriction for openssl
- add cxx standard check
@conan-center-bot

This comment has been minimized.

- reduce the patch size
@vaerizk vaerizk requested a review from jgsogo August 20, 2021 19:42
@conan-center-bot

This comment has been minimized.

- revert the `USE_MSIX_SDK_ZLIB` option renaming
@conan-center-bot
Copy link
Collaborator

All green in build 10 (e050a90f69494cd24755a65778701df358a08588):

  • msix/1.7@:
    All packages built successfully! (All logs)

Copy link
Contributor

@prince-chrismc prince-chrismc left a comment

Choose a reason for hiding this comment

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

Two questions

recipes/msix/all/conanfile.py Show resolved Hide resolved
list(APPEND MsixSrc PAL/Applicability/Win32/Applicability.cpp)
elseif(LINUX)
- find_package(ICU REQUIRED COMPONENTS uc)
+ target_link_libraries(${PROJECT_NAME} PRIVATE CONAN_PKG::icu)
Copy link
Contributor

Choose a reason for hiding this comment

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

Conan V2.0 wont have this namespace target

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this issue should be addressed when Conan 2.0 is released, or can you suggest any solution?

Copy link
Contributor

Choose a reason for hiding this comment

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

Does not make sense to merge something we know will break... we are making an active effort to make the migration easier

🤔 You can keep the call to find package and use the Conan global targets... here could be icu::icu

Copy link
Contributor

Choose a reason for hiding this comment

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

@prince-chrismc I think we will block the usage of CONAN_PKG, CONAN_LIBS and similar in hook soon

Copy link
Contributor

Choose a reason for hiding this comment

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

That's the best way to fix all the recipes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This namespace is provided by the cmake generator and as far as I know this generator is the only way to handle cmake settings like MT/MD passing, so right now the only way to replace this namespace is to use, for example, the cmake_find_package generator along with cmake. But if the cmake generator is removed in Conan 2.0, the recipe will require fix anyway, so does it make sense to add another generator and replace the namespace at the moment?

Copy link
Contributor

Choose a reason for hiding this comment

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

Well the new generators will be close to seamless for the cmake_find_package_multi espcisially around the injection of targets. If we stick if the original intended use of the build script it will be more future proof?

and yes there will be changes but it's not obvious what that will be... I know the CCI team has experimented with the new workflow but I personally have not so I am not sure... I have the expectation the cmake wrapper will survive

Copy link
Contributor

Choose a reason for hiding this comment

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

no, CMake wrapper is not expected to survive. all the things conan_basic_setup did previously now should be set inside the CMake toolchain file generated by conan.
it should enable more seamless and less intrusive integration.
for CCI recipes, it means few simplifications:

  • removal of wrapping CMakeLists.txt if any
  • removal of any patches/replace_in_files doing CMAKE_SOURCE_DIR/CMAKE_CURRENT_SOURCE_DIR adjustments - now recipe doesn't change project root
  • removal of any patches/replace_in_files doing insertions of conan_basic_setup, shouldn't be necessary

probably, it will have more implications on recipes, but at least these should be welcomed changes IMO
the workflow will change only with CMakeDeps/CMakeToolchain generators, for now you can keep doing that you doing

Copy link
Contributor

@jgsogo jgsogo left a comment

Choose a reason for hiding this comment

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

We really prefer to use real targets instead of CONAN_PKG:: ones, but as long as the CI is happy (no hook checking it) this is not a blocker. There will be time to adapt all the recipes.

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

10 participants