coapp-developers team mailing list archive

[Vincent Povirk <madewokherd@xxxxxxxxx>]

So, yesterday I was working on updating our grep (we have some windows
port of grep 2.0, which predates version control, and the latest is
2.9), and it was an exceedingly weird process.

This is partly because I chose, for some crazy reason, to do it in
visual studio, which I'm sure the grep developers aren't targeting.

So my process went something like this:
 * Use mingw to generate a config.h file.
 * Go through config.h by hand and modify things based on how MSVC
appears to work.
 * Create a new MSVC project and add the source file with the main function.
 * When a header doesn't exist, modify the appropriate .in.h file
(conveniently included in the grep source tarball, in most cases) by
hand to create a replacement.
 * When an external symbol doesn't exist, find the C file that defines
it, and add that to the project.
 * Tweak the source for the few problems that I didn't figure out how
to solve that way: missing "offsetof" macro, strcasecmp function, some
stat-related macros, and a local variable declaration in the middle of
a block.

Surprisingly, this eventually resulted in a (mostly) working build.

It seems the majority of the sources I was importing were from the
gnulib project: https://www.gnu.org/s/gnulib/

Effectively, gnulib is providing drop-in replacements for the unixisms
and gnu-isms that grep is using. My guess is that, even after running
it though whatever trace magics coapp implements, most projects that
only build with a configure script will have similar problems that
gnulib might solve. I think it will prove to be a valuable tool when
we're trying to make MSVC builds of more things.

The libgnurx library is a similar idea, but afaict gnulib does a much
better job of it and has the advantage of being maintained.

It seems like there was supposed to be a way to automatically
generated the header replacements, but I wasn't able to find it.

I also wasn't able to do anything about headers that MSVC has but that
lack features (such as sys/stat.h). The gnulib headers use an
"include_next" directive that MSVC doesn't have.

Also, gnulib isn't a shared library; it's meant to be imported into
other projects' source code. It doesn't have releases. This makes
using (and updating) it a bit weird.

So I'm wondering if we can reduce the potential duplication (and
resulting code rot when I fail to pull in an updated opendir.c) with
other forks by forking gnulib and referencing its code from other
projects. The fork could include header files for use with msvc
(including, say, a gl-config.h that would define the symbols it needs
from configure and other misc. things, and could be included from the
project's config.h).

I also wonder if there isn't something else we can do to avoid
manually creating config.h files.