Hey Phillip, First, thanks for the really good feedback. This will help a lot--this is the kind of stuff we need to know.
>> Unless I've misunderstood the details, I don't think tracing the build >> would help out here: it would tell us exactly which parts of Gnulib and >> MinGW-RT get used in the build, but it wouldn't magically fix the problem >> that the Windows SDK doesn't provide equivalents for all the headers and >> library functions the code needs. Well, tracing a build with mingw DOES give us some of what we need--Its possible take the output from a mingw build and create Visual Studio project files from that data--it may require us to 'port' some of the dependent libraries, but that's kind of a goal here too. I'm disturbed by that "#include_next " directive. That's the hackiest damn thing I've ever heard of... I suspect we're gonna have to come up with some sort of fix for that. I propose a hybrid of your options #2 and #3: If I add support for mingw to ptk (so that there is a compiler toolset choice for that), we can trace builds with mingw. If we shallow-fork and build a few of the underlying libraries, we should be able to create projects for MSVC without excessive trouble. The only real issue we're going to face is compiler incompatabilities, and for that we're going to have to actually modify code to fix those oddities that aren't supported by MSVC. Proposed Tasks: ------------------------- [Phillip] - document on a page in the wiki ( http://wiki.coapp.org ) the exact tools/steps to install for mingw -- so that there is no question of how it's installed. [Garrett] - add mingw toolchain support into pTk so that we can trace builds from mingw. (This should only take me a couple of hours once I've got mingw up) [Phillip] - build & trace a few of the libraries with the updated pTk, and report the results :D We won't be able to find issues with the voodoo "#include_next" directive without getting to the compiling on VC stage. Wait. We could update the CoApp scan tool to pick those out--that's kindof the thing that it was built for. Perhaps Trevor could come out of hiding and add that for us (or anyone really... it's good code). Then we could at least do something with that information. Anyone else? G -----Original Message----- From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On Behalf Of Philip Allison Sent: Thursday, May 12, 2011 5:12 AM To: coapp-developers@lists.launchpad.net Subject: [Coapp-developers] MinGW and Gnulib Hullo all, Buoyed by early success (read: dumb luck) at getting bzip to build, I thought I'd have a go at gzip. Long story short, I haven't succeeded, but it's raised some interesting questions. GNU gzip - http://www.gnu.org/software/gzip/ - seems to be actively maintained, unlike the stuff at gzip.org, but it depends on Gnulib, which in turn seems to depend on the MinGW runtime. Gnulib is a bunch of reusable code, which provides implementations of various functionality "missing" from various environments. Unfortunately it isn't a shared library, it really is just a bunch of reusable code: in terms of version control, people either check in a snapshot of the parts they need, or import it using a git submodule (as is the case with gzip), or whatever equivalent their VCS of choice provides. The bigger problem is that it provides a *lot* of autoconf macros for configuring itself to suit the host platform, coupled with making various base assumptions about the host platform's functionality, and I'm not quite sure how we're going to replicate those. Using MinGW and MSYS, it's actually possible to run all the way through gzip's configure script with CC=cl and LD=link, with a bit of environment mangling, but the end result doesn't build. The problem essentially stems from the fact that Gnulib assumes a GNU toolchain and a certain underlying amount of "POSIXness" in the host platform. For example, its replacement for dirent.h - which isn't a static bit of source, but generated locally by autoconf - ended up containing the line '#include_next <dirent.h>', which poses two problems: first of all, the #include_next directive is non-standard and not supported by MSVC; secondly, even if it was supported, the Windows SDK doesn't provide a native dirent.h to begin with. The Gnulib version isn't self-contained, it uses lots of macro trickery to selectively override or augment an existing header. There are also various header files which, once generated, end up containing '#include ""' - I'm not 100% sure what's going on, but I think it's a symptom of a similar problem, where an assumption has been made about the existence of a platform-native header file but the configure script hasn't found one. If I was going to build with the toolchain provided by MinGW itself, this wouldn't be such a problem, because the MinGW runtime library (MinGW-RT) itself meets some of these requirements, but the end goal is to build with MSVC. Unless I've misunderstood the details, I don't think tracing the build would help out here: it would tell us exactly which parts of Gnulib and MinGW-RT get used in the build, but it wouldn't magically fix the problem that the Windows SDK doesn't provide equivalents for all the headers and library functions the code needs. I see several options at this point, but I'm not sure which is best: 1. Port gzip away from Gnulib and MinGW-RT entirely. We would end up with something self-contained and buildable, but the changes would be fairly extensive, and we'd need to repeat the process every time we come across a package with one or both of these dependencies. 2. Support MinGW as an alternative toolchain within CoApp. It's pretty easy to set up these days, and can create executables which run outside the MinGW shell, providing the software doesn't try to do anything too odd at runtime. IMHO a non-starter due to the sheer amount of baggage and maintenance problems this would introduce. 3. Port MinGW-RT to MSVC and package it for CoApp. We may still need MinGW itself to get an initial build of a given package going, but once that's been done & traced, at least we'll have a reasonable assurance that when we swap out the toolchain, we aren't also swapping out great chunks of API which the code relies on. 4. Something else I haven't thought of. I may, of course, be approaching this entirely the wrong way - I do think it will be an ongoing issue, though, because for many developers, MinGW is the toolset of choice when trying to build portable software on Windows. Thoughts? Regards, Phil _______________________________________________ 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 _______________________________________________ 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
