-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
add msix/1.7 #6475
Conversation
This comment has been minimized.
This comment has been minimized.
Is there a possibility to use a dependency with non-default value for some options? My build failed because we need |
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], |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like current master changed the name of the USE_EXTERNAL_ZLIB
variable already:
https://github.com/microsoft/msix-packaging/blob/a8c86c68f18c7fb641fe5e60f31e86e176f9bd29/cmake/msix_options.cmake#L88-L94
Current master has:
https://github.com/microsoft/msix-packaging/blob/c8af99506ffd0c1513fad39cdadfac281723c3e3/cmake/msix_options.cmake#L16
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
We can omit these possibilities, shall we?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
-add_subdirectory(lib) |
conan-center-index/cmake.patch at a3144aa · conan-io/conan-center-index
https://github.com
There was a problem hiding this comment.
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!
"use_external_zlib": [True, False], |
There was a problem hiding this comment.
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.
@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 |
Accidentally closed. |
This comment has been minimized.
This comment has been minimized.
- polish the `source` method
- add required conan version
- fix the `crypto_lib` option
- add `msxml6` to the list of system libraries
This comment has been minimized.
This comment has been minimized.
- move configuration checks to `validate()`
- restrict the package
This comment has been minimized.
This comment has been minimized.
|
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 About the # 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Following previous comment)
- polish the recipe
- remove the restriction for openssl
- add cxx standard check
This comment has been minimized.
This comment has been minimized.
- reduce the patch size
This comment has been minimized.
This comment has been minimized.
- revert the `USE_MSIX_SDK_ZLIB` option renaming
All green in build 10 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two questions
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this 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.
msix/1.7
conan-center hook activated.