New Build System Status

Joel Sherrill joel at rtems.org
Tue Nov 26 00:55:54 UTC 2019


On Mon, Nov 25, 2019, 6:30 PM Chris Johns <chrisj at rtems.org> wrote:

> On 26/11/19 10:46 am, Joel Sherrill wrote:
> > On Mon, Nov 25, 2019 at 5:28 PM Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >     On 26/11/19 9:57 am, Joel Sherrill wrote:
> >     > On Mon, Nov 25, 2019 at 3:19 PM Chris Johns <chrisj at rtems.org
> >     <mailto:chrisj at rtems.org>
> >     > <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
> >     >
> >     >     On 26/11/19 8:05 am, Joel Sherrill wrote:
> >     >     > On Mon, Nov 25, 2019 at 2:12 AM Sebastian Huber
> >     >     > <sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>>>>
> >     >     > wrote:
> >     >     >
> >     >     >     On 25/11/2019 08:55, Chris Johns wrote:
> >     >     >     >
> >     >     >     > On 25/11/19 5:28 pm, Sebastian Huber wrote:
> >     >     >     >>
> >     >     >     >> On 24/11/2019 23:25, Chris Johns wrote:
> >     >     >     >>>>> Should there be a note or something about waf
> needing
> >     python and we
> >     >     >     recommend
> >     >     >     >>>>> python3? Plus waf needs a `python` installed and
> not just
> >     >     `python2` or
> >     >     >     >>>>> `python3`?
> >     >     >     >>>> I think this belongs to the Host Computer section.
> The quick
> >     >     start uses the
> >     >     >     >>>> RSB, so if you managed to build the tools, you must
> have a
> >     >     working Python.
> >     >     >     >>>> The RSB uses Python and the RTEMS Tools use waf.
> >     >     >     >>> The RSB can use python2 or python3 without a python.
> What
> >     about a note
> >     >     >     to say
> >     >     >     >>> ... "Waf uses python and you need to make this
> command available
> >     >     on your
> >     >     >     system".
> >     >     >     >> Now I am a bit confused. I thought every UNIX-like
> system
> >     provides a
> >     >     >     >>
> >     >     >     >> #!/usr/bin/env python
> >     >     >     >>
> >     >     >     >> which maps to Python 2 or 3?
> >     >     >     >>
> >     >     >     > Apparently on some distros the python executable is not
> >     automatically
> >     >     >     installed
> >     >     >     > with a suitable python2 or python3. I am not aware of
> the
> >     specifics of
> >     >     >     this but
> >     >     >     > it was raised as an issue that I fixed in the RSB:
> >     >     >     >
> >     >     >     > https://devel.rtems.org/ticket/3537
> >     >     >
> >     >     >     I have never seen a system in which
> >     >     >
> >     >     >     #!/usr/bin/env python2
> >     >     >
> >     >     >     or
> >     >     >
> >     >     >     #!/usr/bin/env python3
> >     >     >
> >     >     >     works, but not
> >     >     >
> >     >     >     #!/usr/bin/env python
> >     >
> >     >     I agree however this is the post from Joel about a class he
> held ...
> >     >
> >     >
> https://lists.rtems.org/pipermail/devel/2018-October/023150.html
> >     >
> >     >     and I posted the change here ...
> >     >
> >     >
> https://lists.rtems.org/pipermail/devel/2018-October/023296.html
> >     >
> >     >     >     How many Python scripts would stop to work in this case?
> >     However, the
> >     >     >     availability of a python command is not mandatory
> according to:
> >     >     >
> >     >     >     https://www.python.org/dev/peps/pep-0394/
> >     >
> >     >     I am aware of this and I support it however Linux distros
> seems to
> >     feel there
> >     >     are cases for exceptions, we have this one and there is also
> pax.
> >     >
> >     >     The pax and this python case are similar, do we say "We are
> correct,
> >     fix your
> >     >     host or raise a bug on your distro" or do we attempt to smooth
> over
> >     the cracks
> >     >     and attempt to just work?
> >     >
> >     >     In the case of ubuntu, maybe someone with some experience with
> it can
> >     see what
> >     >     is needed and update the documentation?
> >     >
> >     >     >     I think we should note in the "Host Computer" section
> that a
> >     "python"
> >     >     >     command is mandatory for RTEMS and remove the RSB extra
> stuff.
> >     >
> >     >     The argument was presented to me that the RSB should just work
> even in
> >     this case
> >     >     and so that is what I did. I am fine to remove that support,
> it is an
> >     >     average hack.
> >     >
> >     >     > Chris can answer to that.
> >     >
> >     >     Done.
> >     >
> >     >     > But on Centos 7, we have:
> >     >     >
> >     >     > $ type python
> >     >     > python is /usr/bin/python
> >     >     > $ python --version
> >     >     > Python 2.7.5
> >     >     > $ type python2
> >     >     > python2 is /usr/bin/python2
> >     >     > $ type python3
> >     >     > bash: type: python3: not found
> >     >     > $ env python
> >     >     > Python 2.7.5 (default, Aug  7 2019, 00:51:29)
> >     >     > [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2
> >     >     > Type "help", "copyright", "credits" or "license" for more
> information.
> >     >     >>>>
> >     >     >
> >     >     > and if I activate the SCL for Python 3:
> >     >     >
> >     >     > $ scl enable rh-python36 bash
>
> >
> >     >
> >     >     >
>
> >
> >     >     > [joel at localhost rtems-work]$ type python
>
> >
> >     >
> >     >     >
>
> >
> >     >     > python is /opt/rh/rh-python36/root/usr/bin/python
>
> >
> >     >
> >     >     >
>
> >
> >     >     > [joel at localhost rtems-work]$ python --version
>
> >
> >     >
> >     >     >
>
> >
> >     >     > Python 3.6.3
> >     >
> >     >     And on ubuntu? The original post was about that distro.
> >     >
> >     >
> >     >  Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-66-generic
> x86_64)
> >
> >     >
> >     > ....
> >     > $ type python
> >     > python is /usr/bin/python
> >     > $ python --version
> >     > Python 2.7.15+
> >     > $ env python
> >     > Python 2.7.15+ (default, Oct  7 2019, 17:39:04)
> >     > [GCC 7.4.0] on linux2
> >     > Type "help", "copyright", "credits" or "license" for more
> information.
> >     >>>>
> >     > $ python2
> >     > Python 2.7.15+ (default, Oct  7 2019, 17:39:04)
> >     > [GCC 7.4.0] on linux2
> >     > Type "help", "copyright", "credits" or "license" for more
> information.
> >     >>>>
> >     > $ python3
> >     > Python 3.6.8 (default, Oct  7 2019, 12:59:55)
> >     > [GCC 8.3.0] on linux
> >     > Type "help", "copyright", "credits" or "license" for more
> information.
> >     >>>>
> >
> >     I am sorry but I am not sure how this helps the discussion? Your
> original post
> >     last year raised the issue of no python being installed on ubuntu
> and that lead
> >     to the change in the RSB.
> >
> > I wish I had included the Ubuntu version in the original post. msys2 and
> cygwin
> > always seem to reflect the day you install them to me. The best I could
> do is
> > report on the msys2 on my laptop and the Ubuntu we use for testing
> appear to be OK.
> >
> > I have no way to reproduce what happened in the class I sent an email
> about.
> > I assure you that it happened though.
>
> I am sure it did happen. I reported at the time the python symlink is part
> of
> the python-minimal package. I have no idea how this sits in that distro's
> packaging structure and how it can happen.
>
> What does you version show for ...
>
>  apt-file search /usr/bin/python | grep "/usr/bin/python$"
>
> ... ?
>
> > On the master, I suppose assuming "python" exists is OK as an experiment
> as long
> > as it is assumed it may be Python2 or Python3. We should be prepared for
> someone
> > to have the situation where it doesn't work out though and need to
> revisit this.
>
> Are you saying it is OK to remove the support I added from the RSB and
> rtems-tools?
>

I am saying I have no system to prove it right now. I think it is still
needed but can't reproduce it.

I don't like removing it quietly without a replacement to detect and report
something to a user that X occurred, please report so we know what hosts
this happens on.


> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191125/c3cb1651/attachment-0001.html>


More information about the devel mailing list