Hello Jens,

I've added Richard on Cc.

Em qui., 9 de jul. de 2020 às 01:13, Jens Rehsack <[email protected]> escreveu:
> > Am 08.07.2020 um 23:20 schrieb Otavio Salvador 
> > <[email protected]>:
> >
> > Em qua., 8 de jul. de 2020 às 16:58, Jens Rehsack <[email protected]> 
> > 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 <[email protected]>
> >
> > 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?

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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140477): 
https://lists.openembedded.org/g/openembedded-core/message/140477
Mute This Topic: https://lists.openembedded.org/mt/75384624/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to