Update README

README.txt

@@ -1112,17 +1112,6 @@ Window Native Toolchain Issues
      is not a long as you might think because there is no dependency checking
      if you are using a native Windows toolchain.  That bring us to #3:
 
-  3. Dependencies are not made when using Windows versions of the GCC on a POSIX
-     platform (i.e., Cygwin).  This is because the dependencies are generated
-     using Windows paths which do not work with the Cygwin make.
-
-       MKDEP                = $(TOPDIR)/tools/mknulldeps.sh
-
-     If you are building natively on Windows, then no such conflict exists
-     and the best selection is:
-
-       MKDEP                = $(TOPDIR)/tools/mkdeps.exe
-
 General Pre-built Toolchain Issues
 
   To continue with the list of "Window Native Toolchain Issues" we can add

tools/README.txt

@@ -396,6 +396,8 @@ mkromfsimg.sh
 mkdeps.sh
 mkdeps.bat
 mkdeps.c
+cnvwindeps.c
+mkwindeps.sh
 mknulldeps.sh
 -------------
 
@@ -418,8 +420,15 @@ mknulldeps.sh
   script that produces dependencies well for POSIX style hosts (e..g.,
   Linux and Cygwin).  It does not work well for mixed environments with
   a Windows toolchain running in a POSIX style environment (hence, the
-  mknulldeps.sh script).  And, of course, cannot be used in a Windows
-  nativ environment.
+  mkwindeps.sh script).  And, of course, cannot be used in a Windows
+  native environment.
+
+  mkwindeps.sh is a version that creates dependencies using the Windows
+  native toolchain.  That generates Windows native paths in the dependency
+  file.  But the mkwindeps.sh uses cnvwindeps.c to convert the Windows
+  paths to POSIX paths.  This adds some time to the Windows dependency
+  generation but is generally th best option available for that mixed
+  environment of Cygwin with a native Windows GCC toolchain.
 
   [mkdeps.sh does have an option, --winpath, that purports to convert
   the dependencies generated by a Windows toolchain to POSIX format.
@@ -437,7 +446,7 @@ mknulldeps.sh
   does not work well in mixed POSIX environment with a Windows toolchain.
   In that case, there are still issues with the conversion of things like
   'c:\Program Files' to 'c:program files' by bash.  Those issues may,
-  eventually be solvable but for now continue to use mknulldeps.sh in
+  eventually be solvable but for now continue to use mkwindeps.sh in
   that mixed environment.
 
 define.sh