> This repo is a fork of jamesyoungman/findutils:master but that is a
> (frequently very out of date) mirror of the real findutils git
repository,
> which is on Savannah, not github (see
> https://savannah.gnu.org/git/?group=findutils for details).
>
> If you'd like to discuss next steps, the first thing to do is rebase your
> changes against the current git master branch on Savannah.
>
> I haven't looked at your changes, since right now you're about 58 changes
> behind Savannah, so there would be lots of distracting irrelevant diffs.
Thanks so much for taking the time to reply! I was aware that your
mirror is not always up to date, I mostly wanted to show some relation
to the main repository through github so I forked your repo since
you're among the maintainers. I want to keep the 'mingw-4.9.0' branch
on the findutils v4.9.0 tag, so I've created a new 'mingw' branch
which is 'mingw-4.9.0' rebased onto master:
https://github.com/cyrilarnould/findutils/tree/mingw
> I think it's unlikely that the findutils maintainers will accept "hacky"
> changes for the benefit of MinGW if it compromises the code quality for
> other systems (e.g. GNU/Linux distributions).
Totally understandable, I am willing to improve the patches. Like I
mentioned though, my capabilities are somewhat limited when it comes
to C, my background is in FPGA development. I of course also don't
want to put in more time than needed; if there were no chance
whatsoever for official MinGW support then I'll stick to maintaining
hacks :) But I appreciate you hearing me out. Let me elaborate a bit
on which commits I mean by those:
- fbd3bbd: Provides replacement functions for grp.h and pwd.h. The
declarations were snuck into config.h and the functions were defined
in idcache.c. Now ideally, the gnulib would provide replacements,
but that of course opens up a whole other can of worms. A better way
would probably be to use local windows-only grp.h and pwd.h files;
but I do not know how to neatly implement this.
- 8afccf5: Provides replacements for fork. exec.c contains a wrapper
function for spawnvp, this would probably be more at home in a
separate file as well. The other changes in that commit also seem a
bit invasive.
The remaining changes don't seem too bad IMO, they are mostly #ifdefs
to remove some functionality.
> It probably also works/worked under Cygwin.
>
> I think I get the idea of why someone would want to use the MinGW GCC to
> build programs, but what's the advantage of using a version of find built
> with MinGW instead of using WSL, for example?
My personal use case is Emacs. I've been using its MinGW build for
years now and it works great. Some quite handy functions in Emacs make
use of find or xargs in the background though, and having to install
WSL/Cygwin just to use a small utility like findutils seems like a bit
of a high requirement. I can also see a use case in continuous
integration; installing findutils through chocolatey for instance
is probably easier than setting up WSL/Cygwin.
As an alternative to my port, I did use the MSYS2 findutils
implementation which uses the msys-2.0.dll, a fork of the
cygwin.dll. This approach isn't the most convenient, to avoid
compatibility issues I need to do some trickery like creating a
symlink to findutils and its required DLLs and then adding that
symlink to Emacs' PATH.
It also means that findutils is going through an emulation layer that
in theory slows things down. Admittedly, the performance with MSYS2's
implementation is quite good already. Embarassingly, find is actually
faster than my port depending on the search, I think because of
lacking O_NOFOLLOW support. But one can dream that the port will catch
up one day. For instance, the 'mingw-4.9.0' branch has an issue if
there are too many files in a folder. This has however been addressed
in some gnulib update, the 'mingw' branch doesn't have this issue.
> I would expect there to be a great many difficulties with such a project.
> For example, Windows filenames don't conform to the expectations of
> POSIX-like systems, which is what the find implementation expects.
Some
> differences will be obvious but others not. For example AIUI in
Windows,
> C:\WINDOWS\NUL and C:\USERS\JAMES\NUL are the same file, but it would
> likely be difficult to get the expected result with -samefile.
Absolutely, but I would hope users will understand that a Windows port
comes with some restrictions (and bugs, in the beginning). In the
github repository, I keep a write up of which of the 'make check'
tests are currently failing. AFAICT though, the gnulib already goes a
long way where filenames are concerned.
