[MinGW-dvlpr] FW: [mSys - MinGW] RFC, Where to go...

[Julien L. <lec...@fr...>]

 
Hello,
 
I'll start by quoting G'n'R' : "Where do we go now ?"... After my 'mSys From
Scratch' experience I've come to notice all the following points that would
or should be addressed.
 
WIKI
* I've worked a lot on the Wiki and I think that it should be reorganized in
several different sections that are smaller in size, but address more
precisely and separatly "problems/troubleshooting", "hot fixes", etc...
Separating MinGW from mSys would also be a good thing. I'll write a RFC to
address this problem more precisely; also, Earnie, did you find someone
willing to take in charge maintaining the Wiki ? Otherwise, I'm willing to
be candidate.
 
INSTALL (mSys)
* The new MinGW install process is great (choosing which packages and
versions). I'ld like to propose that mSys also take the same direction so
that there is only one install executable that installs either mSys alone,
or the DTK and DVLPR packages (and why not also MinGW ?). The untar
processing is pretty odd though. I think it would be better to download
"cab" files (since MS windows ships with the "extract" program) Think of it
as the MS PSDK (without the downloading of xyz cab files though)
 
FLEX / BISON
* I strongly believe that adding FLEX / BISON to the mSys repository is
needed.
 
MSYS DTK / DVLPR
* The sources are available either on sourceforge or as patches to the
canonical sources. Is there any reason these aren't in the CVS repository
also ?
 
CONFIG.SUB / CONFIG.GUESS
* I understood Max's point of view on the problem of always patching these
files and I also understood Earnie's point of view of not adding MSYS as a
recognized environment. This is why I'ld like to propose to add MSYS only in
config.sub (not config.guess).
The result would be 'config.guess' wouldn't recognize MSYS (with
MSYSTEM=MSYS), but doing a "configure --build=msys" would always be
recognized.
 
AUTOMAKE
* I'ld like to port w32api / MinGW runtime to automake, currently I'va
already done w32api. I'm having a problem compiling cygwin with the new
w32api (available on http://sourceforge.net/tracker/?func=detail
<http://sourceforge.net/tracker/?func=detail&aid=1213103&group_id=2435&atid=
302435> &aid=1213103&group_id=2435&atid=302435) not because of the new
w32api but because of the other stuff cygwin builds. Help would be
appreciated to validate this.
 
GCC (on MSYS)
* There is a problem that arises when you recompile and install w32api for
MSYS (current CVS, or from my patch, see above). GCC installs some w32api
headers in his /lib/gcc-lib folder, and then the new headers and the gcc
ones fall out of sync. My current solution is to delete from the
/lib/gcc-lib/.../include all the headers that are duplicates of /include.
 
That all (for now) folks !
Your input, experiences and opions appreciated,
Julien