On 05/05/2020 12:38, Chris Johns wrote:
On 5 May 2020, at 6:25 pm, Sebastian Huber <sebastian.hu...@embedded-brains.de>
wrote:
On 05/05/2020 09:48, Chris Johns wrote:
It is currently busy building the 5/rtems-sparc build set (without GDB) in a
mingw64 shell. Is a build in the msys shell something useful/supported?
Yes, we have valid users. Plus building on Windows is valid for the same
reasons we build from source on all hosts maybe more so.
If I install msys/mingw I get an msys, mingw32 and mingw64 shell. They are all
somewhat different. Are all of them supposed to be supported?
They are different in a subtle way, they set different paths so you get a
different set of native executables and DLLs in your path. Run:
`set | grep ^PATH`
in each instance and compare. On top of that the mingw native tools are
specifically named, something I completely agree with.
MSYS2 is well thought out, the pacmac tools is great. Like cygwin a rolling
release makes baselining for deployment or a product hard.
Yes, but should RTEMS build on all three shells? Which one is recommended?
Ah ok, sorry I did not understand. We want the best executables we can get so
this is MINGW64. The 64bit build should have the bests performance. And we
want native executables as the API interface is direct. If you want MSYS then
use Cygwin. It is the fully featured parent project.
Ok, so I will focus my testing on the mingw64 shell only.
With the GDB build disabled I was able to build the tools for sparc. I
wanted to test if the tar01 test works on mingw64, however, it is
disabled by configure:
AM_CONDITIONAL(TARTESTS,test "$as_ln_s" = "ln -s" && test -n "$PAX" &&
test -n "$GZIP")
We had several discussions in this area. My point is still that the
RTEMS tests should not depend on host computer capabilities. I would
simply check in the archives which require extraordinary and super
sophisticated features like symbolic links.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
