build issues doxygen and graphviz in sandbox

[mahaase]

what do u think about the necessary fixes to get doxygen/graphviz up in sandbox:

$ git diff
diff --git a/recipes/devel/doxygen.yaml b/recipes/devel/doxygen.yaml
index 145645b..966d7e9 100644
--- a/recipes/devel/doxygen.yaml
+++ b/recipes/devel/doxygen.yaml
@@ -10,8 +10,9 @@ checkoutSCM:
     stripComponents: 1

 buildTools: [flex, bison, dot, python3]
+buildVars: [CXX]
 buildScript: |
-    cmakeBuild "$1"
+    cmakeBuild "$1" -DPYTHON_EXECUTABLE="$(which python3)" -DCMAKE_PREFIX_PATH="$($CXX -print-sysroot)/usr"

 packageScript: |
     cmakePackageTgt
diff --git a/recipes/devel/graphviz.yaml b/recipes/devel/graphviz.yaml
index 7dcb739..af34538 100644
--- a/recipes/devel/graphviz.yaml
+++ b/recipes/devel/graphviz.yaml
@@ -23,6 +23,12 @@ checkoutSCM:
     stripComponents: 1

 buildScript: |
+    if [[ "$(which ps2pdf)" == "" ]] ; then
+        export ac_cv_prog_PS2PDF="true"
+    fi
+    if [[ "$(which groff)" == "" ]] ; then
+        export ac_cv_prog_GROFF="true"
+    fi
     autotoolsBuild $1

 packageScript: |

-DCMAKE_PREFIX_PATH="$($CXX -print-sysroot)/usr" because of find_package(Iconv REQUIRED) will not find iconv... why?
-DPYTHON_EXECUTABLE="$(which python3)" necesssary because of cmake picks python instead of python3 by find_package(PythonInterp REQUIRED), no idea why?!

the missing tools groff and ps2pdf (ghostscript) for graphviz... should we add anyone of them?

[daxcore]

What do u think about setting CMAKE_SYSROOT to $CXX -print-sysroot if not empty in cmake class? This would fix it in this case.

[daxcore]

Should we add a python executable to all python3 providing tool recipes e.g. by sym-linking to python3?

[jkloetzke]

I think the bob_compat toolchain is currently flawed. It is declared as native toolchain but comes with a sysroot. This screams for such kind of problems.

The python thing is strange. At least in the sandbox /usr/bin/python is a symlink to python3. There is not even a python2 version available.

[daxcore]

No. It will be used /usr/bin/python which is python v3. I just expected to use the python, provided by package. But there is no package that provides a tool names python. All python3 packages just provides python3 executables.

[mahaase]

I think the bob_compat toolchain is currently flawed. It is declared as native toolchain but comes with a sysroot. This screams for such kind of problems.

not just the compat-toolchain, also the sandbox is not correct IMO:

/toolchain/include/c++/9.2.0/ext/stdio_filebuf.h
/toolchain/include/c++/9.2.0/ext/stdio_sync_filebuf.h
/toolchain/include/c++/9.2.0/tr1/stdio.h
/toolchain/sysroots/aarch64-bob-linux-gnu/usr/include/bits/stdio_lim.h
/toolchain/sysroots/aarch64-bob-linux-gnu/usr/include/bits/stdio-ldbl.h
/toolchain/sysroots/aarch64-bob-linux-gnu/usr/include/bits/stdio2.h
/toolchain/sysroots/aarch64-bob-linux-gnu/usr/include/bits/stdio.h
/toolchain/sysroots/aarch64-bob-linux-gnu/usr/include/stdio.h
/toolchain/sysroots/aarch64-bob-linux-gnu/usr/include/stdio_ext.h
/toolchain/lib/gcc/aarch64-bob-linux-gnu/9.2.0/include/ssp/stdio.h

we build glibc in sandbox, and build a host-toolchain, but do not copy it into default locations (/usr).

that is also the blocker of the aarch64-sandbox MR.

[jkloetzke]

This is actually correct and done on purpose. These paths are added to $PATH by the host-toolchain. No regular package should find the compiler or use stray include files from /usr/include. It is still a native compiler, though. Just at an unusual location.

No. It will be used /usr/bin/python which is python v3. I just expected to use the python, provided by package. But there is no package that provides a tool names python. All python3 packages just provides python3 executables.

Yes. Currently python is supposed to be around in the sandbox or the host. Otherwise we would need a relocatable python such as you created in the new layer. I would rather avoid that in the basement layer...

[mahaase]

FIXED by #82