<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 4:26 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/10/19 1:15 am, Andrew Butterfield wrote:<br>
> Dear RTEMS Users,<br>
> <br>
>  Sebastian Huber asked me to check the availability of Doorstop (<a href="https://pypi.org/project/doorstop/" rel="noreferrer" target="_blank">https://pypi.org/project/doorstop/</a>) for macOS, and to report my experience on this mailing list.<br>
> <br>
>  It is planned to use this for RTEMS requirements in the RTEMS qualification project.<br>
> <br>
> It turned out to install really easily on my machine, in few 10s of seconds<br>
> <br>
<br>
<sigh><br>
<br>
> The following is a record of my system setup w.r.t. python,<br>
> and the installation process.<br>
> <br>
> <br>
> Hardware/OS: MacBook Pro, 2.8Ghz i7, 16GB ram, 500GB flash, macOS 10.14.6<br>
> <br>
> python state:<br>
> <br>
> ~> which python<br>
> /usr/local/bin/python<br>
  ^^^^^^^^^^^^^^<br>
Hmmm ...<br>
> ~> python --version<br>
> Python 2.7.16<br>
> <br>
> ~> which python3<br>
> /usr/local/bin/python3<br>
> ~> python3 --version<br>
> Python 3.7.4<br>
> <br>
> ~> which pip<br>
> /usr/local/bin/pip<br>
> ~> pip --version<br>
> pip 19.0.3 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)<br>
> <br>
> ~> which pip3<br>
> /usr/local/bin/pip3<br>
> ~> pip3 --version<br>
> pip 19.1.1 from /usr/local/lib/python3.7/site-packages/pip (python 3.7)<br>
><br>
> Both pythons are 'brew' versions. Chris Johns said we should only use<br>
> the native installed versions.<br>
<br>
I am actually saying this is currently all we need to build our tool set. I<br>
cannot afford to have homebrew or macport packages installed because what I<br>
might have installed at any point in time may effect the building of the tools<br>
and I would never know and if I step on a bug where is the problem.<br>
<br>
I do not have the time or resources to maintain our tool sets when building with<br>
homebrew and macports packages installed. If an issue is found is the problem in<br>
the tools or an installed package. I would need to determine which part and look<br>
for a solution. I do not want to become a Mac package maintainer or a MacOS<br>
expert in a wide number of open source packages.<br>
<br>
I have found the Xcode command line tools from Apple to be stable over a number<br>
of years and I have found Apple and GCC to be responsive to any issues I raise.<br>
I have raised a number of bugs with both parties and in each case I seem to be<br>
one of first to uncover them.<br>
<br>
> However other tools I may choose to used<br>
> often need to be installed using 'brew' and you would be amazed how many<br>
> of those have python as a (brew) dependency.<br>
<br>
This is one alternative and one that brings other often more complicated issues.<br>
<br>
How do we managing building all the tools for all architectures making sure they<br>
build and work with any mix of installed packages at whatever versions they<br>
have? Our mailing list has a number of posts about the RSB not building tools on<br>
MacOS and my first question is always "are any packages installed from homebrew<br>
or macports?" and it normally ends up being related.<br>
<br>
I have no idea how you would control and specify a set of suitable packages for<br>
homebrew or macports. I do know if you use a specific version of Xcode on a<br>
specific version of MacOS you will end up with the same tool set I have built<br>
and tested. I think this is important and important for our users.<br></blockquote><div><br></div><div>I'm a CentOS user and there is a parallel type of situation. I avoid using odd repositories</div><div>and have resisted using the official "software collections" which include a newer Python.</div><div>CentOS 7 ships by default with Python 2.7.5 and I will stay with that.</div><div><br></div><div>Disclaimer: For Sphinx support, I use the Python 3 software collection. Sphinx's need for</div><div>a newer Python is what drove me off CentOS 6.</div><div><br></div><div>Sticking with base installs and official sources of packages keeps us as maintainers </div><div>inline with what "real" users have. Large organization uses in the US are CentOS/RHEL</div><div>users with strict security controls. Those are our corporate and scientific users. I try hard</div><div>to suffer as much as they do. They can't just switch to Mint, FreeBSD, or install something</div><div>from an odd repo.</div><div><br></div><div>RTEMS isn't a hobby (or toy) project and most of its users are stuck in serious industrial</div><div>settings. As core developers, we have to respect that and suffer along.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
</blockquote></div></div>