[ECOS] eCos on Windows without Cygwin

[Andrew Lunn]

> As far as I know, MinGW binaries of GCC toolchains + eCos tools is the
> most tantalizing prospect.

I've little interesting in using eCos on M$ platforms, so i don't
follow the discussion in too much depth, so take all my comments with
a pinch of salt.

As far as i understand, the main problem is configtool and to a lesser
extent ecosconfig. The toolchains themselves seem to work O.K. At
least i don't remember seeing people posting problems with
arm-elf-gcc, etc, it is mostly missing directory problems with
configtool.

As far as i'm aware, most, if not all maintainers use Linux by
preference. So there is little interest in cygwin, unless it is
commercially motivated, i.e. a customer wants a support contract for
hosting eCos on a M$ box.
 
> Since a eCos needs are so simple & unchanging, I believe a MinGW based
> package could live relatively unchanged for years.

If you only consider ecosconfig, i suspect this is true. If you want
to also include the GUI configtool, then the needs are much bigger.

My understanding is that MinGW is using the Win32 API. ecosconfig
using the POSIX API is to some extent maintained since that is what we
use in Linux. I occasionally compile it to make sure it does still
compile... There was an MSVC port at one time, but this has not been
maintained for a long time. So i don't know how much effort there will
be in getting ecosconfig to build and run using the Win32 API.

> Does anyone know of any organized efforts to address these problems?

There is some disorganized efforts to address these problems. If you
look back in the archives you will find patches which help. These are
mostly for the GUI configtool, allowing it to compile with a modern
version of xWidgets, automake support, a first stab at allowing
multiple repositories etc. However if you go the MingW direction with
just ecosconfig, i suspect there will be even less effort spent on
maintaining configtool.

Having said this, i don't think the major problems are technical. I
think it is more motivational. What is really needed is somebody who
takes responsibility for the M$ version of the tools, spends the time
to organize effort to get them working, takes care of all the patches,
regularly produces binaries, pushes to make a new release of the tools
for download on ecos.sourceware.org etc...

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss