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. _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
