[openimageio] Re-fix the usage

Merging to master caused all my changes in portfile.cmake to be rolled back.
Re-fix them:

Restore FindOpenEXR.cmake since it calls find_dependency(OpenEXR CONFIG) and it contains the required macro FOUND_OPENEXR_WITH_CONFIG in OpenImageIOConfig.cmake.
Correct FindLibsquish.cmake and vcpkg-cmake-wrapper.cmake installation path.

Related: #19916.

@jmacey  Can you please test this PR?
Thanks.

@jmacey Can you please test this PR?
Thanks.

This now builds fine (Windows) but still fails to copy squish.dll to the target directory.

but still fails to copy squish.dll to the target directory.

@jmacey Can you provide me a repro step?

basically when I build under windows using cmake, the following files are copied into the target directory (build/Debug)
-a----        10/09/2021     09:33         212992 boost_filesystem-vc142-mt-gd-x64-1_76.dll
-a----        10/09/2021     09:33         170496 boost_thread-vc142-mt-gd-x64-1_76.dll
-a----        10/09/2021     08:19         376832 Half-2_5_d.dll
-a----        10/09/2021     08:14        1461248 heif.dll
-a----        10/09/2021     08:19         470016 Iex-2_5_d.dll
-a----        10/09/2021     08:20        5532672 IlmImf-2_5_d.dll
-a----        10/09/2021     08:19         156160 IlmThread-2_5_d.dll
-a----        10/09/2021     08:19         241664 Imath-2_5_d.dll
-a----        10/09/2021     07:52        1008640 jpeg62.dll
-a----        10/09/2021     08:07        1922048 libde265.dll
-a----        10/09/2021     07:53         423424 libpng16d.dll
-a----        10/09/2021     08:12        8110592 libx265.dll
-a----        10/09/2021     09:34         428544 lzmad.dll
-a----        10/09/2021     10:34       15184896 OpenImageIO_d.dll
-a----        10/09/2021     10:33        2268672 OpenImageIO_Util_d.dll
-a----        10/09/2021     09:35        1012224 tiffd.dll
squish.dll is missing and the exe will not run, If I manually copy the file to the target it works fine, I'm guessing this is from the cmake build / link process (it's different under mac and linux as they add relative link paths or use static libs).
Jon

From: Jack·Boos·Yu @.>
Sent: 10 September 2021 10:50
To: microsoft/vcpkg @.>
Cc: Jon MacEy @.>; Mention @.>
Subject: Re: [microsoft/vcpkg] [openimageio] Re-fix the usage (#20092)
but still fails to copy squish.dll to the target directory.
@jmaceyhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjmacey&data=04|01|jmacey%40bournemouth.ac.uk|39ceb932badf4437ee0308d974407b99|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668642566979287|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=PPFjfqBuAZF3QNYx9D%2FHFtygqUIq8FdjvbwwknXVOkQ%3D&reserved=0 Can you provide me a repro step?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvcpkg%2Fpull%2F20092%23issuecomment-916779222&data=04|01|jmacey%40bournemouth.ac.uk|39ceb932badf4437ee0308d974407b99|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668642566979287|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=EY5eYrcKq0j4Hkj0D2HoCf2nZKbO%2B%2F%2Be%2FJp%2Fd%2FlJOXY%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAACK4G6HKHDJVV3I55MSZX3UBHIH3ANCNFSM5DY3OAKQ&data=04|01|jmacey%40bournemouth.ac.uk|39ceb932badf4437ee0308d974407b99|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668642566989284|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=IzNMLeG%2F%2BYn%2BlDTly4P8d9%2FR2ePU9MsYSFduOyd2izc%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|jmacey%40bournemouth.ac.uk|39ceb932badf4437ee0308d974407b99|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668642566989284|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=6Y0U%2FrzMdCUfyBEOKbt8HvQkaBJW%2FSq6OPTEiJdtEEY%3D&reserved=0 or Androidhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|jmacey%40bournemouth.ac.uk|39ceb932badf4437ee0308d974407b99|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668642566989284|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=My5RskdGCSbyKMh3X%2By9Ze2oeMhZo6I9JL%2Bnx1DFptw%3D&reserved=0.

BU is a Disability Confident Employer and has signed up to the Mindful Employer charter. Information about the accessibility of University buildings can be found on the BU AccessAble webpages.
This email is intended only for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email, which must not be copied, distributed or disclosed to any other person.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Bournemouth University or its subsidiary companies. Nor can any contract be formed on behalf of the University or its subsidiary companies via email.

@jmacey  Did you use the X_VCPKG_APPLOCAL_DEPS_INSTALL feature?

No and have never had to use this before for any other library.
Jon
On 13 Sep 2021, at 03:05, Jack·Boos·Yu @.***> wrote:

@jmaceyhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjmacey&data=04|01|jmacey%40bournemouth.ac.uk|1da45d5189ab414e822608d9765afbfc|ede29655d09742e4bbb5f38d427fbfb8|0|0|637670955416181616|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=bZ54d9wISytAzTmdcyBQ%2BtsfrF5Qls6GCD45clgCqKk%3D&reserved=0 Did you use the X_VCPKG_APPLOCAL_DEPS_INSTALL feature?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvcpkg%2Fpull%2F20092%23issuecomment-917777193&data=04|01|jmacey%40bournemouth.ac.uk|1da45d5189ab414e822608d9765afbfc|ede29655d09742e4bbb5f38d427fbfb8|0|0|637670955416191605|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=htoNLYsejN1YYTXeBLfhNjOk9OUrgy3o5xsUUonTFqo%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAACK4GY7KJ6EKGZ5MZM5OL3UBVL7FANCNFSM5DY3OAKQ&data=04|01|jmacey%40bournemouth.ac.uk|1da45d5189ab414e822608d9765afbfc|ede29655d09742e4bbb5f38d427fbfb8|0|0|637670955416191605|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=HbM%2FzfqAluIrbqObH2Wl81Ho0UXBB%2BvHa3mv%2BzDXWLg%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|jmacey%40bournemouth.ac.uk|1da45d5189ab414e822608d9765afbfc|ede29655d09742e4bbb5f38d427fbfb8|0|0|637670955416191605|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=n%2FTvFlBT8D6B65R%2FRxEl7wyzlgeI4BjlXaUhT2SXF%2F8%3D&reserved=0 or Androidhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|jmacey%40bournemouth.ac.uk|1da45d5189ab414e822608d9765afbfc|ede29655d09742e4bbb5f38d427fbfb8|0|0|637670955416201602|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=MwFz9yI3WnuRDmVse%2BZHZbkI%2FVtgK6S%2FU2zPQy7pswA%3D&reserved=0.

BU is a Disability Confident Employer and has signed up to the Mindful Employer charter. Information about the accessibility of University buildings can be found on the BU AccessAble webpages.
This email is intended only for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email, which must not be copied, distributed or disclosed to any other person.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Bournemouth University or its subsidiary companies. Nor can any contract be formed on behalf of the University or its subsidiary companies via email.

 It is created in the vcpkg tree.

Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvcpkg%2Fpull%2F20092%23issuecomment-917869179&data=04|01|jmacey%40bournemouth.ac.uk|afef699a2a8b49cb270c08d9767c9308|ede29655d09742e4bbb5f38d427fbfb8|0|0|637671099674711497|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=%2F9%2FenLaroL15%2B%2BIvPNiSYYlwnqSt8rXC2Vp8qOgnh%2Bw%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAACK4G2TCBYRB5WUX7TRSHTUBWIE3ANCNFSM5DY3OAKQ&data=04|01|jmacey%40bournemouth.ac.uk|afef699a2a8b49cb270c08d9767c9308|ede29655d09742e4bbb5f38d427fbfb8|0|0|637671099674711497|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=y%2BjMgaapyEqknFIdXXwh68PtQh5VzicWa84UILDu8qA%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|jmacey%40bournemouth.ac.uk|afef699a2a8b49cb270c08d9767c9308|ede29655d09742e4bbb5f38d427fbfb8|0|0|637671099674721490|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=GHvOE1V8Xcs2Suykgh0k0V5S7KOOivEtzYO44cnbO68%3D&reserved=0 or Androidhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|jmacey%40bournemouth.ac.uk|afef699a2a8b49cb270c08d9767c9308|ede29655d09742e4bbb5f38d427fbfb8|0|0|637671099674721490|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=XdijJ2%2B%2FuRz2hWGrzQIMvTwD2gHwm1OfK6hZh3HAe4I%3D&reserved=0.

BU is a Disability Confident Employer and has signed up to the Mindful Employer charter. Information about the accessibility of University buildings can be found on the BU AccessAble webpages.
This email is intended only for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email, which must not be copied, distributed or disclosed to any other person.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Bournemouth University or its subsidiary companies. Nor can any contract be formed on behalf of the University or its subsidiary companies via email.

After reading the source code, I think that's a oiio bug.
In src/dds.imageio/CMakeLists.txt:
if (Libsquish_FOUND)
    # External libsquish was found -- use it
    add_oiio_plugin (ddsinput.cpp
                     LINK_LIBRARIES Libsquish::Libsquish
                     )
...

In src/cmake/add_oiio_plugins.cmake:
macro (add_oiio_plugin)
    cmake_parse_arguments (_plugin "" "NAME" "SRC;INCLUDE_DIRS;LINK_LIBRARIES;DEFINITIONS" ${ARGN})
...
            set (format_plugin_libs ${format_plugin_libs} ${_plugin_LINK_LIBRARIES} PARENT_SCOPE)
...

In src/libOpenImageIO/CMakeLists.txt:
...
target_link_libraries (OpenImageIO
...
        PRIVATE
...
            ${format_plugin_libs} # Add all the target link libraries from the plugins
...

squish wasn't exported in the cmake config files but oiio requires it.
@lgritz  Can you please take a look?

It seems like this port is trying to vendor libsquish when it should depend on the libsquish port instead?

@BillyONeal No, oiio just use the internal FindLibsquish.cmake and oiio depends on libsquish.

@BillyONeal No, oiio just use the internal FindLibsquish.cmake and oiio depends on libsquish.

If it wants to make squish.dll (as reported by @jmacey ) that doesn't sound like an internal-only use. (I know this isn't the bug you're necessarily trying to fix in this PR but ideally we would de-vendor that dependency)

The way I see it is that squish is a dependency as is boost OpenEXR etc so should be copied. For example if you build the core oiio you don’t get the libraw libraries but if you build with the raw option you do. I guess squish is now core because of one of the default compressed formats so needs to be copied.
Sent from my iPad
On 16 Sep 2021, at 05:25, BillyONeal @.***> wrote:

@BillyONealhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBillyONeal&data=04|01|jmacey%40bournemouth.ac.uk|76607dc9457f437828b508d978c9f19c|ede29655d09742e4bbb5f38d427fbfb8|0|0|637673630999304320|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=gcQBjrXoZCZcOkI6eZxBAdFa3rKbbmlFiukdeOOKFys%3D&reserved=0 No, oiio just use the internal FindLibsquish.cmake and oiio depends on libsquish.
If it wants to make squish.dll (as reported by @jmaceyhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjmacey&data=04|01|jmacey%40bournemouth.ac.uk|76607dc9457f437828b508d978c9f19c|ede29655d09742e4bbb5f38d427fbfb8|0|0|637673630999304320|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=RiMLrmKB7WeF%2B9%2F%2FOWsF%2BbyyoeXVwvFBLEreHpGp%2BKc%3D&reserved=0 ) that doesn't sound like an internal-only use. (I know this isn't the bug you're necessarily trying to fix in this PR but ideally we would de-vendor that dependency)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvcpkg%2Fpull%2F20092%23issuecomment-920564872&data=04|01|jmacey%40bournemouth.ac.uk|76607dc9457f437828b508d978c9f19c|ede29655d09742e4bbb5f38d427fbfb8|0|0|637673630999314315|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=JYMtQSSFsN042aX%2BqVhkYeIuoWfjKKk4kPLU1dgJbuY%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAACK4GZ4TFYCY6VMZHMXS33UCFWRTANCNFSM5DY3OAKQ&data=04|01|jmacey%40bournemouth.ac.uk|76607dc9457f437828b508d978c9f19c|ede29655d09742e4bbb5f38d427fbfb8|0|0|637673630999314315|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Zm13KVJvCZXOSnKySJHsgKeI6oCs5UDLCku5bZjrZXA%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|jmacey%40bournemouth.ac.uk|76607dc9457f437828b508d978c9f19c|ede29655d09742e4bbb5f38d427fbfb8|0|0|637673630999324306|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=rsXojI2DttJRhq7ki%2FLrIHKY25AiZd6uh5%2Fd4jDhmfw%3D&reserved=0 or Androidhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|jmacey%40bournemouth.ac.uk|76607dc9457f437828b508d978c9f19c|ede29655d09742e4bbb5f38d427fbfb8|0|0|637673630999324306|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=mHYEYQVKGpoWJTYGOLLQvnSzpgLh3V2TxA2XqkwXllM%3D&reserved=0.

BU is a Disability Confident Employer and has signed up to the Mindful Employer charter. Information about the accessibility of University buildings can be found on the BU AccessAble webpages.
This email is intended only for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email, which must not be copied, distributed or disclosed to any other person.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Bournemouth University or its subsidiary companies. Nor can any contract be formed on behalf of the University or its subsidiary companies via email.

@BillyONeal No, oiio just use the internal FindLibsquish.cmake and oiio depends on libsquish.

If it wants to make squish.dll (as reported by @jmacey ) that doesn't sound like an internal-only use. (I know this isn't the bug you're necessarily trying to fix in this PR but ideally we would de-vendor that dependency)

No, it won't, I confirmed that.

@JackBoosY
I see, there was some confusion here. I was under the impression that I said "this vendors libsquish" and you said, effectively, "it vendors a custom version of libsquish that it only uses internally". But what you actually said was "it does depend on the libsquish port" and Bill was blind.
It still seems like the targets exported by OpenImageIoConfig.cmake should be finding libsquish on their own rather than forcing customers to add Libsquish::Libsquish ?

To clarify for other reviewers, the situation is:

The port libsquish does not provide any kind of cmake bindings.
The port openimageio installs share/OpenImageIO/FindLibsquish.cmake -- and it provides Libsquish::Libsquish even though it isn't itself an owner of Libsquish.

The usage text ends up being:

The package openimageio:x86-windows provides CMake targets:
find_package(Modules CONFIG REQUIRED)
target_link_libraries(main PRIVATE OpenImageIO::OpenImageIO)
find_package(OpenImageIO CONFIG REQUIRED)
target_link_libraries(main PRIVATE Libsquish::Libsquish OpenImageIO::OpenImageIO OpenImageIO::OpenImageIO_Util)

The package openimageio:x86-windows provides CMake targets:

find_package(Modules CONFIG REQUIRED)
target_link_libraries(main PRIVATE OpenImageIO::OpenImageIO)

This does not work:
C:\Users\bion\Desktop>C:\Dev\vcpkg\vcpkg.exe list | findstr openimageio
openimageio:x86-windows                            <IP_ADDRESS>#2        A library for reading and writing images, and a ...

C:\Users\bion\Desktop>type CMakeLists.txt
cmake_minimum_required(VERSION 3.21)
project(demo CXX)

add_executable(main main.cpp)

find_package(Modules CONFIG REQUIRED)
target_link_libraries(main PRIVATE OpenImageIO::OpenImageIO)

C:\Users\bion\Desktop>type main.cpp
#include <stdio.h>

int main() {
    puts("Hello world.");
    return 0;
}

C:\Users\bion\Desktop>cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=C:/Dev/vcpkg/scripts/buildsystems/vcpkg.cmake -S . -B out
-- The CXX compiler identification is MSVC 19.29.30133.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x86/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at C:/Dev/vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package):
  Could not find a package configuration file provided by "Modules" with any
  of the following names:

    ModulesConfig.cmake
    modules-config.cmake

  Add the installation prefix of "Modules" to CMAKE_PREFIX_PATH or set
  "Modules_DIR" to a directory containing one of the above files.  If
  "Modules" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  CMakeLists.txt:6 (find_package)

-- Configuring incomplete, errors occurred!
See also "C:/Users/bion/Desktop/out/CMakeFiles/CMakeOutput.log".

C:\Users\bion\Desktop>

I merged this anyway because I observe that the problems I'm reporting here aren't problems caused by this PR.

@BillyONeal That's because vcpkg wrongly analysis the installed cmake files.

Hi, I'm the main author of OpenImageIO.
Libsquish is an optional dependency. If it's found externally by OIIO's FindLibsquish, that library will be used.
If Libsquish is NOT found externally, it will use embedded source code rather than the library.
In neither case does OIIO produce a libsquish library.
If it's against vcpkg's policy to for one package to embed the code of another package that's also in vcpkg, then all you need to do is (from vcpkg's perspective) make the vcpkg libsquish be a necessary package dependency for OpenImgeIO, in which case, the library will be used and the internally embedded version of libsquish will be ignored entirely.
Is there something I'm doing wrong that I can fix?

On wrong usage information, cf. https://github.com/microsoft/vcpkg/issues/20190. I

Hi Larry,
This issue is quite new, I used OpenImage IO all of last academic year (as students were using home machines vcpkg made it so much easier to install), this issue has cropped up in the last 3 months or so. I'm guessing a flag is missing to tell it to use Squish rather than the internal one as you say.
The issue only really manifests on Windows as the DLL needs to be copied to the executable target directory where as in Mac and Linux they are linked statically by default.

I apologize, as I do not use Windows myself, so sometimes things that break under Windows can go unnoticed (though our GitHub Actions CI does build and test on Windows, and seem to work) and I'm definitely not at all knowledgeable about how the DLLs need to be placed on Windows.
From what I understand, if vcpkg already builds libsquish and OIIO's FindLibsquish is able to find it (maybe setting $Libsquish_ROOT can help if it's not being found), that should all work, I think. Additionally, if it's not found, the libsquish.dll shouldn't come into play at all, since OIIO will use the fully embedded version.
In any case, if there's a change I can make on the OIIO side that will help this process, please let me know (or, better, submit a PR to OpenImageIO).

@lgritz Another issue please see my comment.

@JackBoosY this may just reflect my Windows ignorance, but in the case where the external libsquish is found, doesn't libOpenImageIO link against it? Doesn't that automatically pull it in when a downstream app links against libOpenImageIO?
Are you saying I need to additionally mention it somehow in the OpenImageIOConfig? Why is that not necessary for any of the other libraries we use?

@lgritz According to the official document https://cmake.org/cmake/help/latest/command/target_link_libraries.html#id4 and https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_LINK_LIBRARIES.html, all dependencies that must be linked in use should be declared as PUBLIC to use export to export them to INTERFACE_LINK_LIBRARIES.

I can't see a new PR can you send a link please.

From: Jack·Boos·Yu @.>
Sent: 10 September 2021 09:42
To: microsoft/vcpkg @.>
Cc: Jon MacEy @.>; Mention @.>
Subject: Re: [microsoft/vcpkg] [openimageio] Re-fix the usage (#20092)
@jmaceyhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjmacey&data=04|01|jmacey%40bournemouth.ac.uk|1c3a0287de3b47223a8e08d97436f3ee|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668601627536230|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=lMbrhF%2F3nhIiwHV62Mhdosa%2Fs53m5iS8SzZm0AL2V50%3D&reserved=0 Can you please test this PR?
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvcpkg%2Fpull%2F20092%23issuecomment-916737542&data=04|01|jmacey%40bournemouth.ac.uk|1c3a0287de3b47223a8e08d97436f3ee|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668601627536230|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=h3PnUpEoRIlmoZAU3r7UQ0bj%2BOc44Gsu719uq85T3AQ%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAACK4G6CSRJ6MKRZZ4N5FTDUBHAIBANCNFSM5DY3OAKQ&data=04|01|jmacey%40bournemouth.ac.uk|1c3a0287de3b47223a8e08d97436f3ee|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668601627546226|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=gfIj7oDfi1d6nBxf5dvOSVTibx2vXJbVAkjPaeSWh6Y%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|jmacey%40bournemouth.ac.uk|1c3a0287de3b47223a8e08d97436f3ee|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668601627546226|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Llq68Bkv5N%2FmPPxaT9cl8BHMME02hfiFWgObpUDh%2FQo%3D&reserved=0 or Androidhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|jmacey%40bournemouth.ac.uk|1c3a0287de3b47223a8e08d97436f3ee|ede29655d09742e4bbb5f38d427fbfb8|0|0|637668601627556219|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=lbLvSqOYqnsT6j7nqpU4Zv%2BfaUeSkHpiATeyyVr3hH8%3D&reserved=0.

BU is a Disability Confident Employer and has signed up to the Mindful Employer charter. Information about the accessibility of University buildings can be found on the BU AccessAble webpages.
This email is intended only for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email, which must not be copied, distributed or disclosed to any other person.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Bournemouth University or its subsidiary companies. Nor can any contract be formed on behalf of the University or its subsidiary companies via email.

@JackBoosY But it's not part of OIIO's public interface. OIIO internals call into libsquish, but downstream apps that use OIIO's APIs don't need to call libsquish APIs. Is that not the meaning of PRIVATE here? If I've misunderstood, then what would be an example of where PRIVATE would be the right designation?

@lgritz Even if you only use it internally, it needs to be on your customers' link lines. If you make it PUBLIC, cmake will add those bits to customers' link lines transitively.

@JackBoosY I modified OIIO's CI so that the Windows tests for sure use vcpkg's libsquish (it had previously just used the embedded version), and it seems to work. What's different?
@BillyONeal OK, I can accept that I've misunderstood these modifiers (though they sure have worked for me for a long time). But then, can you explain to me what is an example of when PRIVATE would be appropriate? What's it for, if I have to use PUBLIC for anything that needs to be available to downstream clients at link time?
Is this Windows specific? Because on Linux and OSX, when libOpenImageIO.so links to libsquish.so, a downstream program only needs to link against libOpenImageIO.so. I only need to mark as PUBLIC if the downstream app might directly call into libsquish (i.e., if libsquish types or APIs are part of OIIO's public API).

For me this is a specific vcpkg / windows thing. If I build anything against olio the program builds but will not run as squish.dll is not copied into the target directory. If I copy the squish.dll into the directory I will work.
This is quite a new thing (last 3-4 months as I don’t update vcpkg that often), It first manifested with the spurious AND in the original error report which has now been fixed. Now I get the squish problem which is not a build / link error but a runtime one on Windows only.
Sorry can’t be specific as to when this error started to occur but I know for certain all was fine in my 2nd Semester so this was around Feb until June when the students submitted their work. Think this points to a bigger issue with vcpkg versions and ports but I guess that discussion is for another day.
Also building for source doesn’t cause to many issues either, however I can’t expect all UG students to do this hence using vcpkg for ease :-)
On 17 Sep 2021, at 17:27, Larry Gritz<EMAIL_ADDRESS>wrote:
@BillyONealhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBillyONeal&data=04|01|jmacey%40bournemouth.ac.uk|893cc96beb314ee61e0508d979f811b7|ede29655d09742e4bbb5f38d427fbfb8|0|0|637674928614551188|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=2WSVVBK62oNsWuDqgSFHXyCbCFnSe6ERackrXfknnS8%3D&reserved=0 OK, I can accept that I've misunderstood these modifiers (though they sure have worked for me for a long time). But then, can you explain to me what is an example of when PRIVATE would be appropriate? What's it for, if I have to use PUBLIC for anything that needs to be available to downstream clients at link time?

BU is a Disability Confident Employer and has signed up to the Mindful Employer charter. Information about the accessibility of University buildings can be found on the BU AccessAble webpages.
This email is intended only for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email, which must not be copied, distributed or disclosed to any other person.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Bournemouth University or its subsidiary companies. Nor can any contract be formed on behalf of the University or its subsidiary companies via email.

@BillyONeal OK, I can accept that I've misunderstood these modifiers (though they sure have worked for me for a long time). But then, can you explain to me what is an example of when PRIVATE would be appropriate? What's it for, if I have to use PUBLIC for anything that needs to be available to downstream clients at link time?

I'm not aware of great uses for PRIVATE libraries that work across platforms, but on Windows where each DLL is an island, if you know the result is a DLL, you don't transitively need customers to supply libraries on their link lines. I think there may be similar cases for *nix but I understand that less.
The more common example is to have private/internal headers that customers aren't supposed to have in their environment but that a project uses internally.

On Unix/Linux, with dynamic libraries, if you have libA that depends on libB only for internals (doesn't expose B in A's public API), that dependency to B can be PRIVATE, and libA linking against libB is enough to ensure that when appC links against libA, it will automatically pull in libB. At least for shared libraries. For static, you may need to specify them, but my impression was that CMake handled the decisions about whether to add B explicitly to the linkage for A depending on whether it was static or dynamic.
Is that not possible in Windows?
So the general guidance is that I should pretty much always be using PUBLIC, regardless of whether a dependency is exposed through my APIs, in order to guarantee that the transitive link needs are met?
I probably have a lot of places to fix, then.

Doing some more reading...
Generally, dynamic libraries encode their dependency information (what they were linked against when you linked the library itself). Static libraries do not. So what CMake is supposed to do is understand this, and for PRIVATE library dependencies, pass on the library interface if it's static but not dynamic.
If I understand correctly, marking everything as PUBLIC seems like overkill.
However, I can believe that what happens is that, if static libs are used for libsquish, although cmake will pass along the library dependency in our exported config, a downstream consumer still won't have the FindLibsquish.cmake, and so may not have a good way to find the library when it needs it for linking?

@lgritz
F:\vcpkg\packages\openimageio_x86-windows\bin> dumpbin /DEPENDENTS .\OpenImageIO.dll
Microsoft (R) COFF/PE Dumper Version 14.16.27045.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file .\OpenImageIO.dll

File Type: DLL

  Image has the following dependencies:

    OpenImageIO_Util.dll
    squish.dll
    heif.dll
    jpeg62.dll
    zlib1.dll
    libpng16.dll
    tiff.dll
    IlmImf-2_5.dll
    Imath-2_5.dll
    Half-2_5.dll
    Iex-2_5.dll
    boost_thread-vc141-mt-x32-1_75.dll
    KERNEL32.dll
    MSVCP140.dll
    WS2_32.dll
    VCRUNTIME140.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll

  Summary

       4C000 .data
       8A000 .rdata
       2F000 .reloc
        1000 .rsrc
      4CA000 .text
        1000 _RDATA

@JackBoosY so the PUBLIC/PRIVATE is ok the way it is, the problem was just that the debug OIIO build was selecting the release squish build?
That sounds like it's probably a bug in my FindLibsquish.cmake. Let me see if I can produce a fix for that.

You know what? OIIO's CI tests Windows, but only release build. Adding a debug build to see if I can reproduce.

AFAIU multiple issues are discussed here.

Windows, vcpkg issue: app-local deployment of squish.dll. Independent of export cmake configuration.
All platforms, OIIO issue: Passing linking information for static linkage. Yes, this means PUBLIC in cmake, but Libs.private in pkg-config. And populating the link interface when consuming OIIO mea
All platforms: OIIO/vcpkg/user integration: OIIO comes with a set of cmake find modules. These modules must be installed with OIIO, in order to populate the target link interface when consuming OIIO. The problem is that these modules are not prepared to deal with vcpkg debug+relase setup, in particular the use of different binary names (d debug suffix). For some dependencies, this is patched in vcpkg's port.

@lgritz  The result of dumpbin proves that if we want to use oiio.lib, you must add squish.lib to the link queue, which means that libsquish should be exported to the INTERFACE_LINK_LIBRARIES of openimageioTargets.cmake, which means that PUBLIC should be used instead of PRIVATE.

Windows, vcpkg issue: app-local deployment of squish.dll. Independent of exported cmake configuration. But possible related to build types/item 3, [OpenImageIO] [libsquish] Dependent squish library is not copied in debug mode #20233 (comment).

When users use libsquish through vcpkg, they should use Findlibsquish.cmake installed in share/OpenImageIO, which also solves this issue.

All platforms, OIIO issue: Passing linking information for static linkage. Yes, this means PUBLIC in cmake, but Libs.private in pkg-config. And populating the link interface when consuming OIIO mea

Yes, agreed.

All platforms: OIIO/vcpkg/user integration: OIIO comes with a set of cmake find modules. These modules must be installed with OIIO, in order to populate the target link interface when consuming OIIO. The problem is that these modules are not prepared to deal with vcpkg debug+relase setup, in particular the use of different binary names (d debug suffix). For some dependencies, this is patched in vcpkg's port.

As I said in 1, even if libsquish does not export its config.cmake/targets.cmake, we can use the installed Findlibsquish.cmake to find and use it.

As I said in 1, even if libsquish does not export its config.cmake/targets.cmake, we can use the installed Findlibsquish.cmake to find and use it.

Basically yes. But:

FindLibsquish.cmake must be patched to handle the debug import lib which is actually named squishd.lib and thus does not match squish:
https://github.com/OpenImageIO/oiio/blob/eb4b84e74d38db139bf07ed321a3d63523fa6464/src/cmake/modules/FindLibsquish.cmake#L21-L25
And similar for webp, unless patching to use the exported config.
And maybe more.

OIIO's FindLibsquish.cmake must only be added to the search path when resolving OIIO's dependencies. Otherwise it collide with user projects.

File list for libsquish, from microsoft.vcpkg.ci:
libsquish:/bin/squish.dll
libsquish:/debug/bin/squishd.dll
libsquish:/debug/lib/squishd.lib
libsquish:/include/squish.h
libsquish:/include/squish_export.h
libsquish:/lib/squish.lib
libsquish:/share/libsquish/copyright
libsquish:/share/libsquish/vcpkg_abi_info.txt

@dg0yt Fine, I will make a PR to export the libsquish targets.

So what CMake is supposed to do is understand this, and for PRIVATE library dependencies, pass on the library interface if it's static but not dynamic.
If I understand correctly, marking everything as PUBLIC seems like overkill.

@lgritz After reading another PR, I would like to another insight:
The effect of the PUBLIC and PRIVATE keywords is consistent over various target_... cmake commands.
The purpose is less obvious for target_link_libraries (PRIVATE perhaps only useful for header-only libraries or file-less configuration sets) but it is quite obvious for target_compile_definitions:
if(BUILD_SHARED_LIBS)
    target_compile_options(lcms2 PRIVATE -DCMS_DLL_BUILD)
    target_compile_options(lcms2 PUBLIC -DCMS_DLL)
endif()
target_compile_options(lcms2 PRIVATE -DUNICODE -D_UNICODE)

CMake doesn't require any PUBLIC/PRIVATE/INTERFACE keywords for target_link_libraries, but everything is public then, and you must not mix the forms.

I don't buy the "only header libraries are PRIVATE", that seems to contradict everything I read in Craig Scott's book, "Professional CMake," and many other sources.
From Professional CMake, 9th ed, p. 248,

CMake handles some special cases specific to linking static libraries. If a library A is listed as a PRIVATE dependency for a static library target B, then A will effectively be treated as a PUBLIC dependency as far as linking is concerned (and only for linking). This is because the private A library will still need to be added to the linker command line of anything linking to B in order for symbols from A to be found at link time. If B was a shared library, the private library A that it depends on would not need to be listed on the linker command line. This is all handled transparently by CMake, so the developer typically doesn’t need to concern themselves with the details beyond specifying the PUBLIC, PRIVATE and INTERFACE dependencies with target_link_libraries().

I  believe that PRIVATE is the right designator to use here, because the squish library is used internally to OIIO, but is not part of the exported API. If squish is a dynamic library, there is no need to propagate this transitive dependency because it's handled by the linker; if squish is a static library, CMake already is supposed to know that (for this one case) it needs to treat it as public and propagate the dependency. I think we're using PUBLIC/PRIVATE correctly, but something else is going wrong for this one library (circumstantial evidence: if I was really using PRIVATE incorrectly, wouldn't ALL the libraries have the same failures?).

CMake handles some special cases specific to linking static libraries. If a library A is listed as a PRIVATE dependency for a static library target B, then A will effectively be treated as a PUBLIC dependency as far as linking is concerned (and only for linking).

Okay. I would prefer to see "special cases" in the CMake documentation, not in secondary literature. And CMake documentation just has the following:

Libraries and targets following PRIVATE are linked to, but are not made part of the link interface.

I guess the behaviour comes down to this code:
https://github.com/Kitware/CMake/blob/6261210a671aa20d691b816df6a2237777995b06/Source/cmTargetLinkLibrariesCommand.cxx#L482-L499
which uses $<LINK_ONLY:...> when PRIVATE is used while touching a static library. It seems right ... but cmake documentation also states

Content of ... except when evaluated in a link interface while propagating Transitive Usage Requirements, in which case it is the empty string.

I am confused now :confused:

"Linked to, but not part of the link interface" is terse, but has all the information. For shared libraries, A linking B means that an app linking A only needs to name A (which itself retains the reference to B). But for static libraries, this is not the case; an app using A needs to also link B explicitly, and CMake is supposed to track this.
Here's some primary documentation that implies this: https://cmake.org/cmake/help/v3.21/guide/tutorial/Selecting Static or Shared Libraries.html#mathfunctions-cmakelists-txt-add-library-static
In this example, SqrtLibrary is a static library with a compiled component, and the MathFunctions library calls target_link_libraries(MathFunctions PRIVATE SqrtLibrary) so it's definitely not the case that PRIVATE is only for header-only libraries. They expect this example to work, presumably.
Also, to add the the confusion, I'm using PRIVATE for all the external libraries, yet there is only this one library that we are having trouble with. To me, that indicates that to really understand what's going on, we need to understand what is different about this library.
I have a few hypotheses, but not having a Windows machine and being a total vcpkg noob, I'm not sure which are plausible, but maybe you can recognize which have merit:

Maybe my FindLibsquish.cmake is subtly broken and is causing this difficulty (not hard to believe; we've already established that it's broken as far as finding the right debug version of the library).
Maybe all the other libraries pick up dynamic libraries, but the vcpkg recipe for libsquish is only building a static version of the library, and that's causing problems somehow (either by itself, or some flaw in my build system that isn't very robust with static libraries)?
Maybe that static libsquish library is not built with POSITION_INDEPENDENT_CODE property enabled and so can't be mixed with the other dynamic libraries?
Maybe libsquish is fine, and the problem for downstream is simply that I am not installing FindSquish.cmake and calling find_dependency(libsquish) in my exported cmake config, so the downstream app fails at link time simply because it can't find libsquish, not because there's anything wrong with it or with the exports?

Also, https://cmake.org/cmake/help/v3.21/prop_tgt/LINK_INTERFACE_LIBRARIES.html :

By default linking to a shared library target transitively links to targets with which the library itself was linked. For an executable with exports (see the ENABLE_EXPORTS target property) no default transitive link dependencies are used. This property replaces the default transitive link dependencies with an explicit list. When the target is linked into another target using the target_link_libraries() command, the libraries listed (and recursively their link interface libraries) will be provided to the other target also. If the list is empty then no transitive link dependencies will be incorporated when this target is linked into another target even if the default set is non-empty. This property is initialized by the value of the CMAKE_LINK_INTERFACE_LIBRARIES variable if it is set when a target is created. This property is ignored for STATIC libraries.

Can you tell if the vcpkg libsquish is generating shared, static, or both? I'm still gravitating toward suspecting that the problem here might be that the vcpkg libsquish build itself is maybe making a static library only that is not correctly set up to mix properly with the other dynamic libraries?

To hammer a previous point with a concrete example: Why does PRIVATE link against gif library work, and against libtiff works, but PRIVATE link against squish does not? I think that when we can articulate the answer to that question, we'll know how to solve the problem for squish once and for all.

@lgritz wrote:

Why does PRIVATE link against gif library work, and against libtiff works, but PRIVATE link against squish does not?

Let's refer to "libsquish", to avoid confusion with the software named "Squish" which has an official Find module in CMake.
Depending on actual values are given is to target_link_libraries, the exported config is different for various libraries. I built openimageio[gif,webp]:x64-linux from vpckg master now (so with vcpkg patches). The INTERFACE_LINK_LIBRARIES for OpenImageIO::OpenImageIO has the following entries:
OpenImageIO::OpenImageIO_Util
$<$<TARGET_EXISTS:Imath::Imath>:Imath::Imath>
$<$<TARGET_EXISTS:Imath::Half>:Imath::Half>
$<$<TARGET_EXISTS:IlmBase::Imath>:IlmBase::Imath>
$<$<TARGET_EXISTS:IlmBase::Half>:IlmBase::Half>
IlmBase::IlmBaseConfig
IlmBase::Half
IlmBase::IexMath
IlmBase::IlmBaseConfig
IlmBase::IlmBaseConfig
IlmBase::IlmBaseConfig
IlmBase::Iex
Threads::Threads
-pthread
$<LINK_ONLY:$<$<TARGET_EXISTS:OpenEXR::OpenEXR>:OpenEXR::OpenEXR>>
$<LINK_ONLY:$<$<TARGET_EXISTS:OpenEXR::IlmImf>:OpenEXR::IlmImf>>
$<LINK_ONLY:$<$<TARGET_EXISTS:IlmBase::IlmThread>:IlmBase::IlmThread>>
$<LINK_ONLY:$<$<TARGET_EXISTS:IlmBase::Iex>:IlmBase::Iex>>
$<LINK_ONLY:OpenEXR::IlmImfConfig>
$<LINK_ONLY:OpenEXR::IlmImfConfig>
$<LINK_ONLY:IlmBase::Iex>
$<LINK_ONLY:IlmBase::Half>
$<LINK_ONLY:IlmBase::Imath>
$<LINK_ONLY:IlmBase::IlmThread>
$<LINK_ONLY:ZLIB::ZLIB>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::Half>
$<LINK_ONLY:IlmBase::IexMath>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::Iex>
$<LINK_ONLY:Threads::Threads>
$<LINK_ONLY:Libsquish::Libsquish>
${_IMPORT_PREFIX}/lib/libgif.a
$<LINK_ONLY:heif>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libjpeg.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libjpeg.a>
$<LINK_ONLY:OpenEXR::IlmImfConfig>
$<LINK_ONLY:OpenEXR::IlmImfConfig>
$<LINK_ONLY:IlmBase::Iex>
$<LINK_ONLY:IlmBase::Half>
$<LINK_ONLY:IlmBase::Imath>
$<LINK_ONLY:IlmBase::IlmThread>
$<LINK_ONLY:ZLIB::ZLIB>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::Half>
$<LINK_ONLY:IlmBase::IexMath>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::IlmBaseConfig>
$<LINK_ONLY:IlmBase::Iex>
$<LINK_ONLY:Threads::Threads>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libjpeg.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libjpeg.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libtiff.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libtiffd.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/liblzma.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/liblzmad.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libjpeg.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libjpeg.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libz.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libz.a>
$<LINK_ONLY:m>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libjpeg.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libjpeg.a>
$<LINK_ONLY:ZLIB::ZLIB>
$<LINK_ONLY:WebP::WebP>
$<LINK_ONLY:WebP::WebPDemux>
$<LINK_ONLY:ZLIB::ZLIB>
$<LINK_ONLY:$<$<TARGET_EXISTS:OpenColorIO::OpenColorIO>:OpenColorIO::OpenColorIO>>
$<LINK_ONLY:$<$<TARGET_EXISTS:OpenColorIO::OpenColorIOHeaders>:OpenColorIO::OpenColorIOHeaders>>
$<LINK_ONLY:$<$<BOOL:>:pugixml::pugixml>>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libbz2.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libbz2d.a>
$<LINK_ONLY:ZLIB::ZLIB>
${_IMPORT_PREFIX}/lib/libboost_filesystem.a
${_IMPORT_PREFIX}/lib/libboost_system.a
${_IMPORT_PREFIX}/lib/libboost_thread.a
$<LINK_ONLY:-lpthread>
${_IMPORT_PREFIX}/lib/libboost_chrono.a
${_IMPORT_PREFIX}/lib/libboost_date_time.a
${_IMPORT_PREFIX}/lib/libboost_atomic.a
$<LINK_ONLY:rt>
$<LINK_ONLY:dl>

So the form varies:

libsquish: $<LINK_ONLY:Libsquish::Libsquish>
gif: ${_IMPORT_PREFIX}/lib/libgif.a
tiff: Given tiff's dependencies, a series of entries:$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libtiff.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libtiffd.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/liblzma.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/liblzmad.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libjpeg.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libjpeg.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libz.a>
$<$<NOT:$<CONFIG:DEBUG>>:${_IMPORT_PREFIX}/lib/libz.a>
$<$<CONFIG:DEBUG>:${_IMPORT_PREFIX}/debug/lib/libz.a>
$<LINK_ONLY:m>

This illustrates the pros and cons of the variants:

libsquish is added as a target. So it must be imported as a target, too. In a config file, this can be done with find_dependency. Given the oiio's own FindLibSquish.cmake module, this implies that the module must be deployed and made available via CMAKE_MODULE_PATH.
gif is added as path to the archive file. CMake doesn't have to resolve anything in this case.
However, it won't link the debug binary in a debug build, which can lead to subtle errors when linking an executable to both variants.
tiff is added as path to the archive, with release and debug variants. This is the proper form when using paths.
But all its transitive usage requirements are listed explicitly, i.e. it repeats details of the build of tiff. This would be independent of these details, and much shorter, with target TIFF::TIFF (plus find_dependency).

Would it be better if I only used targets for dependencies that reliably export config files (and have a corresponding find_dependency in my OpenImageIOConfig.cmake), and for all other cases, use old fashioned ${FOO_LIBRARIES} variable?

@lgritz  Yes, using module mode to find dependencies can avoid calling find_dependency.

Yes, using module mode to find dependencies can avoid calling find_dependency.

I agree on the "Yes, but I don't undestand the second part. IMO the modern principles are:

Prefer targets over ${FOO_LIBRARIES}, because they carry various properties at once, including transitive usage requirements.
Prefer config files over Find modules because config file are exported from the build of the exporting package, exactly based on the configuration, instead of needing to guess ex-post.
Prefer find_dependency over find_package when looking for dependencies from config scripts. find_dependency is a useful macro, but it is not made for Find modules.

The downside are that

not all packages provide config files
the official Find modules provided by CMake only slowly added targets

so you have to be careful about minimum versions to be installed on the user side.
@lgritz Thanks for your persistence on clarifying PRIVATE with target_link_libraries.

I had somewhat recently start switching to targets, even for my Find* modules, mostly because of the compactness (just say the target in target_link_libraries, and it also takes care of the includes for you) and simply because I thought it was "modern" usage. I did not consider any downsides, which now I see. I should probably simply back out of that, and to back to the variables at least for the things where I've written my own Find modules, which tend to be fairly simple (maybe too simple). I never considered the "missing for my exported config" issue, probably because I tend to use dynamic libraries myself, where the transitive linkage takes care of itself.
I appreciate your patience with me on this. I'm trying to get it right, but especially not being a windows user and tending not to use static libraries, I think I was not myself bumping into some of the edge cases that are now more apparent to me.

Yeah, vcpkg comes with static, and it comes with combined debug+release. It is not really an edge case, but that's why custom find modules often fail. At least, please make use of select_library_configurations where possible. I usually take CMake's FindZLIB.cmake as a guideline.

Hopefully this will make things a little easier for downstream builders: https://github.com/OpenImageIO/oiio/pull/3108
Basically, my new strategy is:
(a) Use upstream config files and their targets exclusively in cases where they are reliable and available across all versions of the upstream dependency that we support.
(b) When config files aren't always available, use Find modules distributed with CMake, and use targets if it provides them and they seem to work in all CMake versions we support (we presume that if distributed with CMake, they probably work well).
(c) When those aren't available, such as for less popular libraries like libsquish, use our own custom Find modules and in that case, exclusively use the cmake variables -- not the targets! -- because downstream libraries won't know about those targets.


Fix code scanning alert - Uncontrolled data used in network request

Tracking issue for:

[ ] https://github.com/puneeth072003/CODESOURCERER/security/code-scanning/4

@soorya-u can you work on this

I'll look into it


ytsearch: doesn't work

I am using lavaplayer with jda.
It worked well when I used it before, but it doesn't work now.
All functions except ytearch operate normally.
Is there a solution?

Please post more information such as the stacktrace, your lavaplayer version etc.

event.getChannel().sendMessage("Searching...").queue(response -> {             if (myId == 0) myId = response.getMember().getIdLong();             audioPlayerManager.loadItem("ytsearch:" + argument, new FunctionalResultHandler(null, list -> {                 response.delete().queue();                 event.getChannel().sendMessage("There are search results").queue();             }, () -> { response.delete().queue(); event.getChannel().sendMessage("No search results.").queue(); }, e -> { response.delete().queue(); event.getChannel().sendMessage("Error: " + e.getMessage()).queue(); }));
This is part of my code.
It says "No search results." whichever word I enter.
And I'm using the most recent version of the lavaplayer.

can you post your logs in a bin service of your choice? (I recommend https://bin.bardy.me)

Fixed myself


Set Min windows size

Can i somehow set a minimum window size?

@Laetar not out of the box for now. Likely in next version.
But yes, you can - https://github.com/chromelyapps/Chromely/issues/203

@mattkol that broke some stuff for me when running a frameless window.
When that handler is registered, I'm getting a narrow white drag bar, and the window can't be resized.

It seems the cause isn't the min max section of the code, but just handling the message and registering the singleton.
I'm doing this:
container.RegisterSingleton(typeof(IChromelyNativeHost), typeof(IChromelyNativeHost).Name, typeof(CustomNativeWindow));

The base class was the problem. There's still the bug when resizing the window, where the layout only updates after the mouse is released.

Frameless window is not optimal. We have had a lot of progress over time on this, but there are still issues for sure. If it is not one of the issues we are tracking you can log it.
Thanks.


Add support for adding module dependencies

This PR allows to specify module dependencies in manifest according to this guide (I hope it's up to date): https://learn.microsoft.com/en-us/minecraft/creator/documents/gametestbuildyourfirstgametest
Fixes #113

There seems to be a spelling error in the schema.

Also, behavior is expected to change soon with Beta <IP_ADDRESS> (see Technical Updates heading). Perhaps add upcoming module names?


SSAO renders reversed in orthographic Camera3D

Tested versions

Reproducible in: v4.3.beta2.official [b75f0485b], v4.3.beta1.official [a4f2ea91a], v4.3.dev6.official [89850d553]
Not reproducible in: earlier v4.x.x snapshots

System information
Godot v4.3.dev6 - Ubuntu 24.04 LTS 24.04 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4090 (nvidia; 535.183.01) - AMD Ryzen 9 7950X 16-Core Processor (32 Threads)
Issue description
SSAO renders reversed in Camera3D set in orthographic projection. Looks like the issue was introduced in v4.3.dev6.official [89850d553] Earlier versions work correctly.

Steps to reproduce
You can toggle the camera preview in the editor or play the main scene.
Minimal reproduction project (MRP)
ssao_orthographic_mrp.zip

@godotengine/rendering Probably another reverse Z victim?

@godotengine/rendering Probably another reverse Z victim?

Yep. Most likely. Should be an easy fix in that case


Latest JSreport 1.8.2 Installation Problem with specific Port Num

Hello Sir, i downloaded jsreport-win.zip(1.8.2) file for installing in windows 10. Using jsreport configure command in command prompt  i configured and one dev.config.json file was created. in this configuration i have given 3002 as my port number.After this, using  jsreport win-install command i installed jsreport output showed your jsreport service is running. Again i typed jsreport start command it is throwing error and the service which was installed is not working with that port number.Can you please help me how to install this latest version with User required port number[ex : 3002]. And also i am using old version jsreport and i want to upgrade engines and receipes also in my visual studio[.net].  Tell me how to upgrade relevant nuget packages for supporting this latest version.

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>cd/
C:>cd jsreport-win
C:\jsreport-win>jsreport configure
? For which environment would you like to generate configuration? dev
? Do you want to enable web server? Yes
? Which protocol should web server use? http
? Specify the http port for web server: 3002
? Do you want to enable authentication in web server? No
? Do you want to persist jsreport objects in disk? No, memory connection will be used
? Do you want jsreport to enable local file access? No
config saved in: C:\jsreport-win\dev.config.json
C:\jsreport-win>jsreport win-install
Platform is win32
Installing windows service "jsreport-server-exe" for app..
Service "jsreport-server-exe" is running.
C:\jsreport-win>jsreport start
2017-11-01T17:43:02.076Z - info: Initializing<EMAIL_ADDRESS>in development mode using configuration file dev.config.json
2017-11-01T17:43:02.079Z - info: Using extension import-export
2017-11-01T17:43:02.079Z - info: Using extension templates
2017-11-01T17:43:02.079Z - info: Using extension jsrender
2017-11-01T17:43:02.079Z - debug: Extension authentication is disabled, skipping
2017-11-01T17:43:02.079Z - info: Using extension cli
2017-11-01T17:43:02.079Z - info: Using extension handlebars
2017-11-01T17:43:02.079Z - info: Using extension debug
2017-11-01T17:43:02.079Z - info: Using extension express
2017-11-01T17:43:02.110Z - info: Using extension fop-pdf
2017-11-01T17:43:02.110Z - info: Using extension tags
2017-11-01T17:43:02.110Z - info: Using extension phantom-pdf
2017-11-01T17:43:02.110Z - info: Using extension fs-store
2017-11-01T17:43:02.126Z - debug: Extension fs-store was disabled
2017-11-01T17:43:02.126Z - info: Using extension authorization
2017-11-01T17:43:02.126Z - debug: Extension authorization was disabled
2017-11-01T17:43:02.126Z - info: Using extension images
2017-11-01T17:43:02.126Z - info: Using extension child-templates
2017-11-01T17:43:02.126Z - info: Using extension browser-client
2017-11-01T17:43:02.126Z - info: Using extension licensing
2017-11-01T17:43:02.126Z - info: Using extension data
2017-11-01T17:43:02.126Z - info: Using extension text
2017-11-01T17:43:02.126Z - info: Using extension reports
2017-11-01T17:43:02.142Z - info: Using extension resources
2017-11-01T17:43:02.142Z - info: Using extension base
2017-11-01T17:43:02.142Z - info: Using extension studio
2017-11-01T17:43:02.142Z - info: Using extension html-to-xlsx
2017-11-01T17:43:02.157Z - info: Using extension scripts
2017-11-01T17:43:02.157Z - info: Using extension assets
2017-11-01T17:43:02.157Z - info: Using extension scheduling
2017-11-01T17:43:02.157Z - info: Using extension xlsx
2017-11-01T17:43:02.157Z - info: Using extension sample-template
2017-11-01T17:43:02.157Z - debug: Creating samples is disabled
2017-11-01T17:43:02.157Z - info: Using extension public-templates
2017-11-01T17:43:02.157Z - debug: Extension public-templates was disabled
2017-11-01T17:43:02.195Z - info: Creating memory store
2017-11-01T17:43:02.257Z - info: Creating default express app.
2017-11-01T17:43:02.358Z - error: Error when starting http server on port 3002 Error: listen EADDRINUSE :::3002
at Object.exports._errnoException (util.js:907:11)
at exports._exceptionWithHostPort (util.js:930:20)
at Server._listen2 (net.js:1250:14)
at listen (net.js:1286:10)
at Server.listen (net.js:1382:5)
at jsreportRuntime.js:142086:12
at Promise._execute (jsreportRuntime.js:42873:9)
at Promise._resolveFromExecutor (jsreportRuntime.js:45151:18)
at new Promise (jsreportRuntime.js:44747:10)
at startAsync (jsreportRuntime.js:142078:10)
at startExpressApp (jsreportRuntime.js:142112:12)
at null. (jsreportRuntime.js:142247:12)
at jsreportRuntime.js:186821:33
at jsreportRuntime.js:186801:16
at tryCatcher (jsreportRuntime.js:47158:23)
at Promise._settlePromiseFromHandler (jsreportRuntime.js:129469:31)
at Promise._settlePromise (jsreportRuntime.js:129526:18)
at Promise._settlePromise0 (jsreportRuntime.js:129571:10)
at Promise._settlePromises (jsreportRuntime.js:129650:18)
at Async._drainQueue (jsreportRuntime.js:42090:16)
at Async._drainQueues (jsreportRuntime.js:42100:10)
at Immediate.Async.drainQueues [as _onImmediate] (jsreportRuntime.js:41974:14)
at processImmediate [as _immediateCallback] (timers.js:396:17)
2017-11-01T17:43:02.358Z - error: Error occured during reporter init Error: listen EADDRINUSE :::3002
at Object.exports._errnoException (util.js:907:11)
at exports._exceptionWithHostPort (util.js:930:20)
at Server._listen2 (net.js:1250:14)
at listen (net.js:1286:10)
at Server.listen (net.js:1382:5)
at jsreportRuntime.js:142086:12
at Promise._execute (jsreportRuntime.js:42873:9)
at Promise._resolveFromExecutor (jsreportRuntime.js:45151:18)
at new Promise (jsreportRuntime.js:44747:10)
at startAsync (jsreportRuntime.js:142078:10)
at startExpressApp (jsreportRuntime.js:142112:12)
at null. (jsreportRuntime.js:142247:12)
at jsreportRuntime.js:186821:33
at jsreportRuntime.js:186801:16
at tryCatcher (jsreportRuntime.js:47158:23)
at Promise._settlePromiseFromHandler (jsreportRuntime.js:129469:31)
at Promise._settlePromise (jsreportRuntime.js:129526:18)
at Promise._settlePromise0 (jsreportRuntime.js:129571:10)
at Promise._settlePromises (jsreportRuntime.js:129650:18)
at Async._drainQueue (jsreportRuntime.js:42090:16)
at Async._drainQueues (jsreportRuntime.js:42100:10)
at Immediate.Async.drainQueues [as _onImmediate] (jsreportRuntime.js:41974:14)
at processImmediate [as _immediateCallback] (timers.js:396:17)
An error has occurred when trying to initialize jsreport.. seems like there is already a server running in port: 3002
{ [Error: listen EADDRINUSE :::3002]
code: 'EADDRINUSE',
errno: 'EADDRINUSE',
syscall: 'listen',
address: '::',
port: 3002 }

i have answered here about your problem. does that help or make sense? if you execute jsreport win-install you should have jsreport running on port 3002 and you should be able to verify it by opening a browser tab with http://localhost:3002, is it not the case?

Working fine sir, tan q
On Nov 6, 2017 7:26 AM, "BJR Matos"<EMAIL_ADDRESS>wrote:

Closed #22 https://github.com/pofider/html-to-xlsx/issues/22.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pofider/html-to-xlsx/issues/22#event-1326773588, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AakBPiBWtPhAABMJWMBu9Dg-IQQh9tg-ks5szmc7gaJpZM4QOicU
.


Do not reconcile unmanaged ResourceGroups

Hi 👋
We use Kpt and ResourceGroup inventories in addition to Config Sync. They serve different use cases for our clusters. We don't have a need for status to be populated in ResourceGroups and are therefore disabling it using overrides on each of our *Sync resources. ResourceGroups that are created outside of Config Sync, however, are reconciled by default, so we need to explicitly annotate each of them with configsync.gke.io/status: disabled. This includes inventories created by Kpt elsewhere, which ends up with a situation where Kpt inventories are reconciled by Config Sync, and that cannot be easily remedied since Kpt doesn't propagate locally defined annotations to the in-cluster inventory: https://github.com/kptdev/kpt/pull/4165.
Would it be reasonable to limit the scope of the ResourceGroup controller to only look at resources labeled with app.kubernetes.io/managed-by: configmanagement.gke.io? Alternatively, to provide a way to opt out of the ResourceGroup reconciler altogether?

Would it be reasonable to limit the scope of the ResourceGroup controller to only look at resources labeled with app.kubernetes.io/managed-by: configmanagement.gke.io?

Yes I think this would be reasonable

Alternatively, to provide a way to opt out of the ResourceGroup reconciler altogether?

The scope of this change would be quite a bit larger, so I think this would be harder to approve. I expect we would want more user feedback before exploring this approach.

@fredriksommar @sdowell What's the status here? Is this already implemented, or is it an up-for-grabs feature to take a stab at? (I've started thinking a little about tech stuff as I mentally ramp up for returning to work next week after almost three months of leave...)

Was the actual problem here that the statuses were being updated or just that it was removing your custom annotations?
Seems like we could have preserved your annotations with server-side apply, without disabling the status updates. Just because you're not using the statuses doesn't mean nobody is...

A bit of both, I'd say; we don't need the status updates and want to avoid the additional load on the API server from them, and we were also missing annotations we needed to retain.
I would also argue that the expected (or least surprising) behavior for using ResourceGroups alongside but independently of Config Sync is that the latter ignores the former, since ResourceGroup is a resource type not strictly coupled to Config Sync. In other words, why should I get different behavior on them when they're created by something else (like kpt apply) if I also happen to use Config Sync, compared to if I don't?
If there's a use case for having status updates on ResourceGroups not owned by Config Sync we could roll forward to also allow some other label or annotation to opt them in again.

FWIW, I don't think this is a big deal, but it is technically a breaking change, which we try to avoid. That said, it's only breaking for people who use both kpt and Config Sync, and only if they actually rely on the ReaourceGroup status being updated continuously.
The resource-group-controller (RGC) was originally designed to be separate from Config Sync, so it could also be used with kpt to aggregate the status of managed objects. This is used by "nomos status", but that only works if there's also a RootSync/RepoSync.
AFAIK, there aren't actually any tools or users that I know of that take advantage of this other than Config Sync. So it's hard to say if the change will really impact anyone at all, other than Spotify.
The primary benefit is that you don't have to do a ton of GETs and LISTs to determine current package status. kpt doesn't currently take advantage of this. Hypothetically it could, tho.


commit not handling child refs (noindex branch)

(let [entity-id "6037b7a5-5a77-48a3-a294-8dba786d8e9d"
            tag-id "2b47b800-1b64-4669-a709-528c8d29f572"
            gql-entity (with-meta
                         {:__typename "release"
                          :id         entity-id
                          :created    "2021-05-10T09:39:28"
                          :release/id entity-id
                          :tags       [(with-meta {:__typename "tag"
                                                   :id         tag-id
                                                   :tag/id     tag-id}
                                                  {::dx/entity-key :tag/id})]}
                         {::dx/entity-key :release/id})
            db (dx/commit (dx/create-dx) [[:dx/put gql-entity]])]
        {:db db                                             ; << can see invalid ident for tag in here
         :pull (dx/pull db
                        [:__typename
                         ;{:tags [:*]} ; << enable this to see bug
                         :created]
                        [:release/id entity-id])})

fixed in latest commit


Use optional in collectionView:shouldShowMenuForItemAtIndexPath:

When I added new menu item for the collection view, I encountered problem in
open func collectionView(_ collectionView: UICollectionView, shouldShowMenuForItemAt indexPath: IndexPath)
There are cases where the indexpath is nil, thus trigger runtime error.

I tried to fix it by adding optional for indexPath: IndexPath.

Codecov Report

Merging #310 into master will decrease coverage by 0.03%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #310      +/-   ##
==========================================
- Coverage   64.21%   64.17%   -0.04%
==========================================
  Files          63       63
  Lines        3532     3517      -15
==========================================
- Hits         2268     2257      -11
+ Misses       1264     1260       -4

Impacted Files
Coverage Δ

...Controller/BaseChatViewController+Presenters.swift
45.9% <0%> (-0.77%)
:arrow_down:

...rogressIndicatorView/CircleProgressIndicatorView.m
47.24% <0%> (-2.01%)
:arrow_down:

...nents/CircleProgressIndicatorView/CircleIconView.m
45.19% <0%> (-0.51%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 46361a9...f2fffe6. Read the comment docs.

Hello @raisaanjani92. Sorry for the late response. Can I ask you to put a comment
before guard statement?
// Note: IndexPath set optional due to https://github.com/badoo/Chatto/issues/310
// Might be related: https://bugs.swift.org/browse/SR-2417

Done, thank you!

Seems like there could be an easier way to handle this rather than changing the optionality and creating warnings.  This was done back in 2017?  Perhaps time to revisit this and create a better solution?  How can the nil bug be reproduced?  Just asking because I am not able to reproduce this.


Tracking issue

Configuration file changes

[x] https://github.com/Redocly/redocly-cli/issues/697
[x] https://github.com/Redocly/redocly-cli/issues/696
[x] https://github.com/Redocly/redocly-cli/issues/714
[x] https://github.com/Redocly/redocly-cli/issues/793
[x] #833
[x] https://github.com/Redocly/redocly-cli/issues/839
[x] https://github.com/Redocly/redocly-cli/pull/917
[x] https://github.com/Redocly/redocly-cli/issues/900

After the breaking changes above, we can release a release candidate (e.g. 1.0.0-rc.1).
Goal: release by October 31st.
gantt
    title Possible release timeline
    dateFormat  YYYY-MM-DD
    section Breaking changes
    Config file changes           :2022-10-21, 10d
    section Release candidates
    Get community feedback      :2022-10-31  , 55d
    Revisions      : 24d
    General release : 1d

Bugs

[x] https://github.com/Redocly/redocly-cli/issues/767
[x] https://github.com/Redocly/redocly-cli/issues/757
[x] https://github.com/Redocly/redocly-cli/issues/702
[x] https://github.com/Redocly/redocly-cli/issues/700
[x] https://github.com/Redocly/redocly-cli/issues/750
[x] https://github.com/Redocly/redocly-cli/issues/462
[x] https://github.com/Redocly/redocly-cli/issues/424
[x] #846
[x] https://github.com/Redocly/redocly-cli/issues/211

Features/improvements

[x] https://github.com/Redocly/redocly-cli/issues/481
[x] https://github.com/Redocly/redocly-cli/issues/480
[ ] https://github.com/Redocly/redocly-cli/issues/477
[x] https://github.com/Redocly/redocly-cli/issues/392
[x] https://github.com/Redocly/redocly-cli/issues/440
[ ] https://github.com/Redocly/redocly-cli/issues/779
[x] https://github.com/Redocly/redocly-cli/issues/780
[ ] ignore to support wildcard paths
[x] Add support for message placeholders in assertions

Content

[x] Split rules and decorators docs
[ ] Rework custom plugin docs
[ ] Blog posts

Unrelated

[x] https://github.com/Redocly/redocly-cli/issues/699
[x] https://github.com/Redocly/redocly-cli/issues/732

Closing since we're declaring the current code base stable and I think we have more or less everything on this list :tada:


Remove htmltidy from CTT tracker

There is a  problem when calling htmltity to parse the ctt html response:

Server goes with a ton of ram used

The best option for now is to try to remove this dependency so all can run smooth again.

done


stick to one naming convention for factories.

At the moment we have inventory.rb (singular) and users.rb (plural).  We should stick to one and maybe even append the file with _factory.rb

Good point. Shouldn't the factories match the model that it is referencing?

Yeah that's how I have done it in my past projects.  So we would just need to change users.rb to user.rb

Factories are plural.
rails g model test and look at the GENERATED factory (or maybe we need to turn factory generation on) I believe factories are always plural.

The factory that was created when I generated the Organization model was plural.

^^

ok I'll make a quick fix on inventory.rb


gits_diff code isn't working

@psvkaushik , Can you please respond on the current status?

The git diff code is working fine. It has been corrected. Please verify the same. Once verified will close this issue.


When note is added to findings send notification (alert)

Is your feature request related to a problem? Please describe
When a note is added there is no notification returning to the tester.
Describe the solution you'd like
When note is added, a notification should return to the testers such as "Peer Review" functionality.
Describe alternatives you've considered
Implement "Peer Review" function when inside an issue instead of having the option only when looking at the Product.
Additional context
Function to implement notifications:

Peer review is available inside a finding:

Unless you mean a notification for a note being added to a finding which I don't believe exists today

OK. The 'enhancement' label has been added to this issue.


fix: disable create cert button when not connected to a wallet

Changes the create cert button on preflight checklist to a connect wallet if the wallet isn't connect.

Thanks for your contribution @jonasgrilleres


UID 000 not found in trusty

Please paste the output of the following command here: sudo edit-chroot -all

chronos@localhost / $ sudo edit-chroot -all
name: trusty
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20160715134041~master:0dc76a22
release: trusty
architecture: amd64
targets: xfce
host: version 8350.68.0 (Official Build) stable-channel swanky
kernel: Linux localhost 3.10.18 #1 SMP Tue Aug 2 21:11:23 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Not unmounting /mnt/stateful_partition/crouton/chroots/trusty as another instance is using it.
Please describe your issue:
I'm completely new to this, any help would be appericated. I've been trying to download steam.
If known, describe the steps to reproduce the issue:

Not sure what's the problem here.
Please provide more info and reopen if necessary.


What's new in .NET 8 Preview 3 [WIP]

What's new in .NET 8 Preview 3
This issue is for teams to highlight work for the community that will release in .NET 8 Preview 3
To add content, use a new conversation entry. The entry should include the team name and feature title as the first line shown in the template below.
Required
## Team Name: Feature title

[link to the tracking issue or epic item for the work]

Tell the story of the feature and anything the community should pay particular attention
to be successful in using the feature.

Optional
Below are three additional items to consider. These will help the .NET 8 blog team and the community throughout the release.

[ ] Link to documentation.

Where can we send people to learn more about the feature?

[ ] Link to where you'd like people to provide feedback for this feature.

Where can people best comment on the direction of this feature?

[ ] Whether you would like assistance from the .NET 8 writers to craft a story for this feature.

Please @JonDouglas or @JeremyLikness in your comment if so.

Index of .NET 8 releases
Preview 1: https://github.com/dotnet/core/issues/8133
Preview 2: https://github.com/dotnet/core/issues/8134
Preview 3: https://github.com/dotnet/core/issues/8135
Preview 4: https://github.com/dotnet/core/issues/8234
Preview 5: https://github.com/dotnet/core/issues
Preview 6: https://github.com/dotnet/core/issues
Preview 7: https://github.com/dotnet/core/issues
RC 1: https://github.com/dotnet/core/issues
RC 2: https://github.com/dotnet/core/issues

SDK: Simplified Output Path format

https://github.com/dotnet/designs/pull/281
https://github.com/dotnet/sdk/pull/29599

TODO: @baronfel to fill in with details

SDK: Add dotnet workload clean command

https://github.com/dotnet/sdk/pull/30266
https://github.com/dotnet/sdk/issues/30008

TODO: @baronfel to fill in with details
Tell the story of the feature and anything the community should pay particular attention
to be successful in using the feature.

SDK: Misc. Breaking Changes

https://github.com/dotnet/docs/issues/34471

The .NET SDK tries to make changes without causing behavioral breaks, but sometimes that's either not possible or the breaking change is just obviously correct.  The first breaking change we'll talk about for the SDK in preview 3 is the latter category. The .NET SDK has a few ways to change the locale of the dotnet CLI, and for all of them actually setting the language would cause the CLI to set UTF-8 as the encoding of the standard input and output streams, even if the host system didn't support them. That's just wrong, so we changed that. The actual breaking part of this though is that the dotnet CLI also persisted those changes in the terminal session after the application closed, so any CLI applications running after the dotnet CLI would be running in an encoding other than what the user may have actually intended.  If your application relied on this ill-behavior on our part, you should look at using commands like chcp on Windows to change the codepage encodings to what you need.

Introducing ValidateOptionsResultBuilder
To implement the IValidateOptions.Validate(String, TOptions) method effectively, you need to create a ValidateOptionsResult instance that describes the validation result. However, generating a high-quality instance can be cumbersome and may result in layered validation errors. This means that if there are multiple errors, the validation process often stops at the first error. As a result, you may have to go through an iterative process of editing and running the code until all the errors are resolved.
The ValidateOptionsResultBuilder has been introduced to facilitate the creation of a ValidateOptionsResult object. This builder allows for the accumulation of multiple errors.
Usage example

ValidateOptionsResultBuilder builder = new();
builder.AddError("Error: invalid operation code");
builder.AddResult(ValidateOptionsResult.Fail("Invalid request parameters"));
builder.AddError("Malformed link", "Url");

// Build ValidateOptionsResult object has accumulating multiple errors.
ValidateOptionsResult result = builder.Build();

// Reset the builder to allow using it in new validation operation.
builder.Clear();

Building multi-platform container images
It is now common to use both Arm64 and x64 machines on a regular basis. x64 machines have been around for decades, however, Arm64 dev machines (like Apple Macs) and Arm64 cloud nodes are relatively new. Docker supports using and building multi-platform images that work across multiple environments. We've developed a new pattern that enables you to mix and match architectures with the .NET images you build.
Imagine you are on an Apple Mac and want to target an x64 cloud service in Azure. You can build the image by using the --platform switch as follows.
docker build --pull -t app --platform linux/amd64 .

Using the new pattern, you'd update just one line in your Dockerfile (the build stage):
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/nightly/sdk:8.0-preview-alpine AS build

That line enables the SDK to run on the local machine architecture, which will make it run faster and compatibly (since .NET doesn't support QEMU).
This sample demonstrates the pattern. You can also try it if you clone that repo.
Improving multi-platform container support goes into much more detail on this topic.

CodeGen
Arm64

PR#83089 that converts OR(condition, condition) to CCMP lets the JIT emit CCMP on arm64 for bitwise-or between relational comparisons.

AVX-512

@DeepakRajendrakumaran enabled zmm registers to accelerate a subset of Vector512 methods, e.g., Create() and Zero using AVX512, in PR#80960.
@anthonycanino implemented light-weight K register ExtractMostSignificantBits for Vector512 in PR#80820.
The subset of Vector APIs is being added for Vector512 hardware acceleration. In this preview, @DeepakRajendrakumaran added Load* and Store* in PR#82953 and get_One, get_AllBitSet, createScalar(), createScalarUnsafe() in PR#83402. PR#83354 added And, AndNot, Or, OnesComplement and Xor.
PR#83089 that converts  OR(cond, cond) to CCMP, mentioned in Arm64 section, also benefits AVX-512.

PGO

PR#82775 enabled interlocked profiling for basic block counts.
The profile synthesis is supported in PR#82926, PR#83068, PR#83185, and PR#83567.
PR#83002 enabled more intrinsics in Tier0, e.g., get_IsValueType.

General Optimizations

PR#79381 extends emitter peephole optimization and eliminated mov in more scenarios.
PR#82793 folded unreachable cases for switch in early phase of JIT, importer, and improved throughput up to 0.06%.
PR#82917 added System.Runtime.CompilerServices.Unsafe.BitCast for efficient type reinterpretation.
PR#81635 defers expansion of runtime lookups so that they can be better optimized.
PR#83274 unifies unrolling limits and chooses sensible (generally larger) values.

Breaking change: Multi-platform .NET 8 tags no longer support Windows containers
Multi-platform container images make it easy to use the same tags in multiple environments, leaving docker pull to pull content that matches the environment. Up until .NET 8, our multi-platform tags have included support for both Linux (Debian) and Windows (Nano Server). They will only reference Linux (Debian) images with .NET 8 and later. This change was made for .NET 8 Preview 3.
This change was made because Windows multi-platform tags don't work well with respect to selecting the best version. It is better to specify the Windows version you want. This change is discussed in much more detail in Switch multi-platform tags to Linux only.
Pulling a .NET 8 multi-platform tag will result in the following behavior, when "Windows Containers" mode is enabled.
>docker pull mcr.microsoft.com/dotnet/nightly/runtime:8.0-preview
8.0-preview: Pulling from dotnet/nightly/runtime
no matching manifest for windows/amd64 10.0.22621 in the manifest list entries

Going forward, you will need to use one of the following tags, for Windows

mcr.microsoft.com/dotnet/aspnet:8.0-preview-nanoserver-ltsc2022
mcr.microsoft.com/dotnet/aspnet:8.0-preview-nanoserver-1809
mcr.microsoft.com/dotnet/aspnet:8.0-preview-windowsservercore-ltsc2022
mcr.microsoft.com/dotnet/aspnet:8.0-preview-windowsservercore-ltsc2019


Filepaths containing spaces don't work

Using doclets on any files whose paths contain spaces will not work. This is because file paths are not surrounded by quotes when passed to the jsdoc interpreter.

thanks for reporting 👍


add current view to eventPropGetter

Do you want to request a feature?
What's the current behavior?
Based on the current behaviour it would be nice if eventPropGetter would also forward the current view. Agenda will most likely take other styles than month/week/day views:
https://jquense.github.io/react-big-calendar/examples/index.html#prop-eventPropGetter
What's the expected behavior?
add view to the function call as prop.
Hope this feature request might solve styling issue for others too?

+1
Currently setting state with the onView callback to work around this in case it's helpful for anyone.
    constructor(props) {
        super(props);

        this.state = {
            view: MONTH,
        };
    }

    eventPropGetter = () => {
        const { view } = this.state;

        if (view === MONTH || view === AGENDA) {
            return {
                style: {
                    backgroundColor: 'transparent',
                    color: '#000',
                },
            };
        }

        return {
            style: {
                backgroundColor: '#337AB7',
                color: '#FFF',
            },
        };
    }

    onView = (view) => {
        this.setState(() => ({ view }));
    }

Passing the current view to this method is necessary because the style object is applied in the Agenda view, which is a table structure. I had a very hard time figuring out why my agenda view was totally messed up, until I finally remembered that I was setting display: block in eventPropGetter. If the context of the applied styles were the same, it would not be necessary, but since this applies to the table rows and cells in Agenda view, we really need information to work with.


Button - Enhancements

Enhancements to the Button component

there are following problems with button:
Button does not merge styles and classNames, should work with instead of overwrite
Some more refinements
Default type should be clearer
Refs not forwarded

issue code - HOV-49


Burmilla v1.9.1 ISO's console boot up takes a very long time

Burmilla v1.9.1 ISO's console boot up takes a very long time, about 5+ minutes.
The console stops at message "BurmillaOS v1.9.1 started.", and silently it will be stuck there for about 5+ minutes.
I am not sure what it is waiting on.
This can be reproduced by using a VirtualBox VM that boots the ISO. non-ISO based booting (e.g. boot from hard drive after installation) does not seem to have this same issue.
The next message on dmesg is "random: crng init done". maybe it is initializing the random number generator? It feels an unexpected long time for that.
Another guess would be it is downloading something, but even for that 5+ minutes seems too long.

okay, I tried it again. It actually took about 1 min or so, but one has to press some key to call out the console prompt.

Why is this issue closed? It's still an issue for me.

reopening then.
it seems that I need to press an "Enter" or something, and eventually the prompt will show up. sometimes it is rather fast, sometimes it is not.
if there is not key press, the prompt does not come out, and it is unclear when it starts accepting key press.

Like commented on https://github.com/burmilla/os/issues/50#issuecomment-764735136 boot process is asynchronous which why it depends on platform which order those gets loaded. Especially when booting from ISO.
However as BurmillaOS is based on RancherOS so I would like understand if there is measurable difference between those too? Especially compared to RancherOS with Debian console.

rancheros v1.5.6 's official isod oes not have this issue. neither does v1.5.8
I do not thing those are using the debian console though. maybe the console is the issue?
and for this issue, I do not see the burmilla splash (the BurmillaOS ascii art). it is more like the console takes a much longer time than rancher to get ready for use.

RancherOS defaults to that super tiny and completely useless console called for default. To simplify maintenance and having to more useful toolset on console we decided to use Debian as baseline and drop other on https://github.com/burmilla/os/issues/9
If you want test RancherOS boot with Debian console it should be possible by giving kernel parameter
rancher.console=debian

on boot menu.
And to test exactly same way you need generate custom iso with cached Debian console https://rancher.com/docs/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/#building-with-a-different-console

hmm... from my point of view, the current console in the burmilla's iso no longer has utilities like parted, mkdosfs, which can be important for hacking around the install procedure.. so it is even more useless in this context at least for me..
also note that the current console has a fairly non-trivial .bashrc, but does not have a .bash_profile file, so the .bashrc is not executed in most cases..

hmm... from my point of view, the current console in the burmilla's iso no longer has utilities like parted, mkdosfs, which can be important for hacking around the install procedure.. so it is even more useless in this context at least for me..

Yea this is the second reason why I wanted to lock to just one console. On RancherOS there is six different console options and each of those have different tooling/features/issues.
Now when we have just one we can fix those just once one. Feel free to open up PR about adding those.

also note that the current console has a fairly non-trivial .bashrc, but does not have a .bash_profile file, so the .bashrc is not executed in most cases..

Those was added on https://github.com/burmilla/os/pull/31 to enable colors to console. At least on my envs those works fine no matter if I login from console or using SSH. Improvements are welcome.

oh, there is the .profile file, so my claim was wrong. sorry.
will look into possible PRs.
still needs more investigation on why the long delay on showing the prompt though.

Sure but would be good if someone can investigate if that was issue already on RancherOS with Debian console or if that was created by switching to Debian buster.

I have been playing a lot with QEMU now and I haven't seen this issue on there so looks like virtual box related issue.
Can you try boot on virtual box using debug option from boot menu to see if that will give us more details about where it is stuck?

this issue also occurs on bare metal. it is not only virtual box related.

Hmm. Looks that I managed to duplicate it also iPXE boot with rancher.debug=true kernel parameter:

However it would be nice if you can check if debug messages are same on virtual box/bare metal when it gets stuck?

I see that stuff is stuck at Calling GET /containers/console/json I think it is trying to start the console container?

I used rancher.debug=true. And that's all related output in /var/log/message:
May 27 07:11:39 rancher kernel: [    1.817617] usb 1-1: SerialNumber: 42
May 27 07:11:39 rancher kernel: [   38.647389] random: crng init done
May 27 07:11:39 rancher kernel: [   39.116214] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
May 27 07:11:39 rancher kernel: [   41.143686] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
May 27 07:11:39 rancher kernel: [   41.145063] Bridge firewalling registered
May 27 07:11:39 rancher kernel: [   41.202602] Initializing XFRM netlink socket
May 27 07:11:39 rancher kernel: [   41.214327] IPv6: ADDRCONF(NETDEV_UP): docker-sys: link is not ready
May 27 07:11:39 rancher kernel: [   60.545162] cgroup: system-docker-r (354) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
May 27 07:11:39 rancher kernel: [   60.545819] cgroup: "memory" requires setting use_hierarchy to 1 on the root
May 27 07:11:39 rancher acpid: starting up with netlink and the input layer
May 27 07:11:39 rancher acpid: 2 rules loaded
May 27 07:11:39 rancher acpid: waiting for events: event logging is off
crng init and cgroup take too much time?

crng init and cgroup take too much time?

crng is part of os-base which is build using buildroot. v1.9.x versions are based on very old buildroot 2018.02.11 and it cannot be updated because newer versions of it does not support 4.14.x kernels.
However if that it the case then problem is most probably already fixed on v2.0.0-beta4 which is based on buildroot 2020.02.8 and most probably contains crng corrections too.

Btw. I eventually figured out how to build kernel 4.14.x compatible OS base with latest Buildroot (https://github.com/burmilla/os-base/tree/kernel-4.14.x and https://github.com/burmilla/os-initrd-base/tree/kernel-4.14.x) so v1.9.2-rc3 is now based on Buildroot 2021.02.2. How it looks is that any better? (and especially not worse than earlier)?


Please tag releases

Hey, I think it'd be great if you could tag a release in git when you publish to crates.io as this easily allows me to see what code went into a release and I can also see the changes.

Thank you for the suggestion, we started adding tags with the version 0.4.0.


Unclear Formula <-> Factor

There is no rule for having defined both formula and factor on a parameter.
Is it allowed?
If yes, in what order do they have to be calculated? formular first or factor first?
because if formula = sin($) and factor is 15
then:
sin(x/15) <> sin(x)/15
as far as i know.

This is indeed not specified yet, there is not precedence defined if both properties are set. Typically, only one is provided. Is it possible for you to include the factor in the formula instead of providing an additional factor?

The only initention was to advise to inhibit the usage of formula and factor simultaniously on a parameter and make that clear in the manual; for it makes no sense.

That's what I wanted to find out with the question :)
We can update the documentation and indicate to use either the factor or the formula.
As far as I know there is no provider that currently uses both, so it shouln't be an issue.

If have added this rule to the latest documentation.


Examples are not working q.cb is not a function

Hello,
I cant try out the example.
Ive downloaded the files and copied gl-matrix.js into the build dir but it still does not work.
Console:
Uncaught TypeError: q.cb is not a function
    at Graphics.js:73
(anonymous)	@	Graphics.js:73
setTimeout (async)
(anonymous)	@	Graphics.js:67
Promise.then (async)
initialize	@	Graphics.js:59
FlareExample	@	example.js:20
onLoad	@	example.html:25
onload

We were just working on this the other day, I've merged the PR we had in place for this.
If you pull the latest master it should be working now..!