[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] Bare minimum of work to get Chicken linking under
felix . winkelmann
Re: [Chicken-hackers] Bare minimum of work to get Chicken linking under native Windows
Wed, 28 Feb 2018 00:32:34 +0100
> On Mon, 19 Feb 2018 09:57:33 -0500 Joshua Robbins <address@hidden> wrote:
> > Chicken may not build under native Windows, but it builds under MinGW
> > just fine, and the libraries produced by building chicken under MinGW
> > can be linked to in non-MinGW-built applications. I have a large C
> > application that builds under native Windows, and I'd like to use
> > Chicken in it. I can successfully take libchicken.a and convert it to
> > a .lib file, but there is still one problem with this, however, and
> > it's the header files.
> > You can link to Chicken just fine, but the header files themselves
> > depend on a sufficiently POSIX-like environment to run. For example,
> > unistd.h isn't there at all. The simplest solution I can think of is
> > to make shim header files that include declarations Chicken needs (and
> > nothing else, since MinGW has already taken care of the
> > implementations for us).
(let me throw in a few bits of information, albeit a bit late...)
There is nothing that fundamentally prevents CHICKEN being build
with MSVC (and it once did work just fine), but as Mario correctly points out,
we have no Windows maintainers, which results in MSVC-based builds lagging
behind in maintenance. Moreover, support for various versions of MSVC
(if that is what you mean by linking to a "native Windows non-mingw
application") requires someone testing and debugging the project files
for whatever versions currently in widespread use.
If you can provide shim header files (a considerable task, by my estimation,
since chicken.h is rather heavily #ifdef'd), we can easily ship them with the
reelase tarball, but they are likely to become out of date quickly.