On Fri, 18 Sep 2015 18:28:09 +0200
hasufell <hasuf...@gentoo.org> wrote:
> On 09/17/2015 06:36 PM, Alexis Ballier wrote:
> >
> > # @ECLASS-VARIABLE: PYTHON_COMPAT
> > # @DESCRIPTION:
> > # Tells the eclass the package has python code and forwards it to
> > python-r1.eclass. PYTHON_ECLASS=""
> > CATKIN_PYTHON_USEDEP=""
> > if [ -n "${PYTHON_COMPAT}" ] ; then
> > PYTHON_ECLASS="python-r1 python-utils-r1"
> > fi
>
> see python-r1.eclass:
> """
> # Please note that python-r1 will always inherit python-utils-r1 as
> # well. Thus, all the functions defined there can be used
> # in the packages using python-r1, and there is no need ever to
> inherit # both.
> """
I don't think that hurts and usually prefer explicit inherit rather
than relying on transitive ones, but i have no strong opinion and this
can be removed
> > # @FUNCTION: ros-catkin_src_install_with_python
> > # @DESCRIPTION:
> > # Decorator around cmake-utils_src_install to ensure python scripts
> > are properly handled w.r.t. python-exec2.
> > ros-catkin_src_install_with_python() { python_export
> > PYTHON_SCRIPTDIR cmake-utils_src_install
> > if [ ! -f "${T}/.catkin_python_symlinks_generated" -a -d
> > "${D}/${PYTHON_SCRIPTDIR}" ]; then dodir /usr/bin
> > for i in "${D}/${PYTHON_SCRIPTDIR}"/* ; do
> > dosym ../lib/python-exec/python-exec2
> > "/usr/bin/${i##*/}" || die done
> > touch "${T}/.catkin_python_symlinks_generated"
> > fi
> > }
>
> Maybe I don't understand the purpose, but this looks like a hack
> that is trying to circumvent the python eclasses.
>
> You probably should have a look at:
> """
> # @FUNCTION: python_replicate_script
> # @USAGE: <path>...
> # @DESCRIPTION:
> # Copy the given script to variants for all enabled Python
> # implementations, then replace it with a symlink to the wrapper.
> #
> # All specified files must start with a 'python' shebang. A file not
> # having a matching shebang will be refused.
> """
I don't think that'll work, above code is what I came up after
talking with mgorny about how to do it.
the cmake build system will already populate PYTHON_SCRIPTDIR and
those might differ between python versions; only thing left to do is
symlinking into /usr/bin; a bit like _distutils-r1_wrap_scripts, but
for which the leading _ suggests its not public
python_replicate_script seems useful only for files ending in /usr/bin
> >
> > # @FUNCTION: ros-catkin_src_compile
> > # @DESCRIPTION:
> > # Builds a catkin-based package.
> > ros-catkin_src_compile() {
> > if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
> > python_foreach_impl cmake-utils_src_compile
> > else
> > cmake-utils_src_compile
> > fi
> > }
> >
>
> >
> > # @FUNCTION: ros-catkin_src_test
> > # @DESCRIPTION:
> > # Run the tests of a catkin-based package.
> > ros-catkin_src_test() {
> > if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
> > python_foreach_impl ros-catkin_src_test_internal
> > else
> > ros-catkin_src_test_internal
> > fi
> > }
> >
>
> >
> > # @FUNCTION: ros-catkin_src_install
> > # @DESCRIPTION:
> > # Installs a catkin-based package.
> > ros-catkin_src_install() {
> > if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
> > python_foreach_impl
> > ros-catkin_src_install_with_python else
> > cmake-utils_src_install
> > fi
> > }
> >
>
> I think these functions should pass arguments through to
> cmake-utils_src_* functions, so an ebuild might be able to do stuff
> like ros-catkin_src_compile -j1
> or other things if that is really needed.
>
yep, fixed locally, thx
you should consider fixing distutils-r1 too because that's what I was
inspired by iirc :p
Alexis.
