On 25/05/18 18:34, Christopher Larson wrote:
We should probably investigate if it's possible to shift those into
do_fetch eventually. Contacting upstream during do_configure is not kosher.
The reason for fetching during configure is that the CMake build system
in the git repository in question (later referred to as the "parent
project") uses the ExternalProject keyword [1], which "creates a custom
target to drive download, update/patch, configure, build, install and
test steps of an external project" [1].
The external project that the aforementioned CMake build system uses is
gtest (later referred to as the "child project"), which is many times
built as part of a parent project. Usually git submodule is used to
clone child projects, which works nicely with Bitbake with the gitsm
fetcher. In this particular case the parent project uses the
ExternalProject keyword instead, which is one of the options suggested
in gtest's documentation [2]. While the parent project is not a public
open source project, it is not in our direct control either and hence we
cannot just change it to use git submodule instead.
Another option _might_ be to run CMake in two phases: the first pass
would just run the ExternalProject keyword and the second the real
configure step. We are not aware of a way to run CMake in multiple
phases though. Also cmake.bbclass (currently) doesn't have anything
related to the do_fetch step. Thirdly, I assume that running the
ExternalProject keyword as the first pass during do_fetch would also
configure and build the child project, which would then again conflict
with Bitbake's later build steps such as do_configure and do_compile.
I think it would be a valid use case to support fetching by the
ExternalProject keyword even during do_configure because a recipe
maintainer does not necessarily have direct control over the upstream
project.
If it is possible to resolve the issue e.g. by changing cmake.bbclass to
call CMake differently or other means, any guidance is appreciated.
[1] https://cmake.org/cmake/help/latest/module/ExternalProject.html
[2]
https://github.com/google/googletest/blob/master/googletest/README.md#incorporating-into-an-existing-cmake-project
Thanks,
--
Hannu Lounento
[email protected]
On Fri, May 25, 2018 at 5:52 AM Niko Mauno <[email protected]
<mailto:[email protected]>> wrote:
Update cmake_do_configure() to export a set SSH_AUTH_SOCK variable
before calling cmake.
Otherwise, if cmake call during cmake_do_configure() resorts to
ExternalProject directive containing a GIT_REPOSITORY entry, and git
authentication scheme is based on SSH agent forwarding, it fails
followingly
| Cloning into 'foo'...
| Permission denied (publickey).
| fatal: Could not read from remote repository.
|
| Please make sure you have the correct access rights
| and the repository exists.
|
| ...
|
| CMake Error at .../tmp/foo-gitclone.cmake:66 (message):
| Failed to clone repository: 'ssh://...
Signed-off-by: Niko Mauno <[email protected]
<mailto:[email protected]>>
---
meta/classes/cmake.bbclass | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fcfd5dda4f..82d36be8ff 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -137,6 +137,11 @@ cmake_do_configure() {
oecmake_sitefile=
fi
+ # Allow cmake to perform eg. git clone in context where
authentication relies on SSH agent forwarding
+ if [ "${SSH_AUTH_SOCK}" ] ; then
+ export SSH_AUTH_SOCK=${SSH_AUTH_SOCK}
+ fi
+
cmake \
${OECMAKE_GENERATOR_ARGS} \
$oecmake_sitefile \
--
2.11.0
--
_______________________________________________
Openembedded-core mailing list
[email protected]
<mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
