> Am 09.07.2020 um 13:52 schrieb Otavio Salvador : > > Hello Jens, > > I've added Richard on Cc. /o\ > Em qui., 9 de jul. de 2020 às 01:13, Jens Rehsack escreveu: >>> Am 08.07.2020 um 23:20 schrieb Otavio Salvador : >>> >>> Em qua., 8 de jul. de 2020 às 16:58, Jens Rehsack escreveu: >>>> >>>> Instead of recognizing only environment-setup scripts in >>>> ${STAGING_DIR_TARGET} or ${STAGING_DIR_NATIVE}, respectively - lurk also into >>>> ${SDKPATH}/buildtools/sysroots/${SDK_SYS} where nativesdk-openssl installs >>>> setup files. >>>> >>>> Remove overwriting of OPENSSL_CONF from buildtools-tarball.bb to clarify >>>> whether nativesdk-openssl installs wrong content or buildtools-tarball: >>>> (nativesdk-openssl) tmp/sysroots/x86_64/usr/lib/ssl-1.1/openssl.cnf >>>> (buildtools-tarball) buildtools/sysroots/x86_64-pokysdk-linux/etc/ssl/openssl.cnf >>>> >>>> Signed-off-by: Jens Rehsack >>> >>> I did not understand the openssl related change. Is it possible to >>> rework the commit log so it is more detailed? >> >> For sure, but maybe I'm completely wrong. Let me try explaining it first... >> >> If - and only if - one creates an SDK which included openssl (and not libressl, mbedssl, ...), >> nativesdk-openssl packages an ${SDKPATHNATIVE}/environment-setup.d/openssl.sh >> >> OTOH - meta/recipes-core/meta/buildtools-tarball.bb creates a script which is sourced >> at the very end of SDK environment setup and writes what's included in >> {SDKPATHNATIVE}/environment-setup.d/openssl.sh on it's own - with maybe slightly >> different location - what guides me to add: >> ... to clarify whether nativesdk-openssl installs wrong content or buildtools-tarball: >> (nativesdk-openssl) tmp/sysroots/x86_64/usr/lib/ssl-1.1/openssl.cnf >> (buildtools-tarball) buildtools/sysroots/x86_64-pokysdk-linux/etc/ssl/openssl.cnf >> >> Maybe they way how nativesdk-cmake is doing it is the right way. Then, maybe >> nativesdk-openssl should be reworked. This is for clarification. >> >> Does it explain something better? > > Yes and generating it directly might indeed be not the best option. > Ideally, it'd generate a new source script which would run later and > do any need adjustment. Do you agree? I have at least no idea. I just wondered and thought asking this way is an option. > Either way, this commit seems to be mixing two changes and I'd prefer > if you split it. This allow for nicer review as well as better commit > messages of individual changes. Of course I can (and will) split both changes and discuss them separately. But I rated it highly possible that I get the feedback: both are wrong. It's intended and should be X and Y and please send an update for nativesdk-openssl :) Cheers -- Jens Rehsack - rehsack@gmail.com