Phillip, (et al;)
I've updated the ptk Tool to support building from mingw (in github).
In the .buildinfo file, you can set:
compiler:mingw-x86;
in a build configuration, and it will adjust the environment correctly for
mingw.
Just like using the VS+SDK, You shouldn't have to do anything special to set it
up, it's pretty clever about finding your mingw/msys install, and running with
that. As long as you've installed mingw/msys in a fairly normal way.
You can run it from a regular cmd.exe command prompt; there is no need to be in
MSYS shell or anything.
Note: it runs the build commands thru cmd.exe (either directly, or via a
temporary script)--if you want to use an "sh" type script, put the script in a
file and make the command something like : sh.exe myscript.sh
G
-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net
[mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On
Behalf Of Garrett Serack
Sent: Thursday, May 12, 2011 8:08 AM
To: Philip Allison; [email protected]
Subject: Re: [Coapp-developers] MinGW and Gnulib
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: [email protected]
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 : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
