Get building on MinGW-64

[gvansickle]

Currently there are issues with at least the argp lib.

[DavidEGrayson]

I started working on this tonight. You can follow my progress here:

https://github.com/DavidEGrayson/mingw-packages-deg/tree/master/mingw-w64-ucg

(The way I try out interesting C/C++ software is that I make an MSYS2 package for it.)

[DavidEGrayson]

I got ucg to compile, link, and run on MSYS2 as a MinGW-w64 program but it seems to be buggy: it only finds matches in the top-level directory.

[gvansickle]

Hi @DavidEGrayson ,
Thanks for your interest! Yeah, I've been picking away at this issue as well. You may want to look at what I've got so far at feature/ISSUE23-BuildOnMINGW64. The main thing I've run into is that I need to pull in a ton of gnulib just for argp and fts. And like you even once that's sorted it doesn't want to pass "make check". Frustrating. And then there are the licenses: I haven't yet got up the spirit to go through all the gnulib files that get pulled in to make sure they're compatible. I don't wish to dissuade you with my Debbie Downer talk here, I definitely want to get a statically-linked MinGW-w64 build happening, but it's definitely more work than I had first anticipated.

[DavidEGrayson]

Thanks for the reply! I might dig into this later, and I suspect I will find that there are issues with Gnulib's fts implementation on mingw-w64 that are causing these problems. I had similar problems a year ago when I tried to get recursive grep working:

• MinGW's st_ino field is always zero instead of being an inode number from the filesystem, which means that fts cannot accurately detect recursive directory loops caused by symlinks: https://lists.gnu.org/archive/html/bug-grep/2015-03/msg00013.html
• Gnulib's fdopendir has (had?) an unwanted side effect of closing the file descriptor that was passed to it: https://lists.gnu.org/archive/html/bug-gnulib/2015-03/msg00019.html

[DavidEGrayson]

Yeah, the problem I was talking about where ucg doesn't search in any directories except the top-level one was caused by st_ino always being zero. In my MSYS2 package, I now apply a patch to Gnulib's fts-cycle.c so it ignores nodes with st_ino equal to zero when checking for cycles.

By the way, maybe UniversalCodeGrep should behave like grep does and show a warning when such cycles are detected. You can see if a cycle happened by checking if the fts_info field is equal to FTS_DC.

I can now run make check and only four tests are failing:

  2: Error code with bad search path                 FAILED (sanity.at:26)
  3: Error code with bad regex                       FAILED (sanity.at:37)
 14: --[no]column tests                              FAILED (file_presentation.at:56)
 16: Color-vs-terminal tests                         FAILED (file_presentation.at:133)

I looked at your branch ( https://github.com/gvansickle/ucg/tree/feature/ISSUE23-BuildOnMINGW64 ) and I don't see any changes that might make those tests pass.

[gvansickle]

The st_ino thing is going to break ArgParse::is_same_file() too.