Progress update
David Abrahams
With some significant CMake help with Doug Gregor (thanks, Doug!), I
got sat-solver ported to MacOS, and I've pushed the changes upstream:
http://gitorious.org/opensuse/sat-solver/merge_requests/2
As you can see from that link, some tests are still failing for me,
but I'm pretty sure that those first two are exercising the important
functionality of the library and the others are merely failing
(crashing) because of some problem I'm having with libexpat, which is
used by the tests but not the sat-solver library itself. It would be
awesome if someone else with a Mac or other BSD system could test this
to see if it's something going on with my installation.
Also, the project has a few pairs of test files whose path differ only
in case, so I had to create a case-sensitive volume to be able to work
on it. On a Mac, you can do that pretty easily with Disk Utility.
Next steps:
* Resolve Expat issues
* Rename files to avoid case-sensitivity problems
* Make the tests use Git instead of RPM
* Port to Windows!
I would be very happy if someone else could work with me on any of
these steps.
Cheers,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
David Irvine
Great progress !
We are still manic and pushed for time with our own projects. If you
can post some simple instructions I can get a MAC and test this
tomorrow in the office (I hope). In a short while we may have some
spare capacity to help you more Dave. None of us are MAC developers
but I can give the test suite a try.
David Irvine
Bill Hoffman
>
> With some significant CMake help with Doug Gregor (thanks, Doug!), I
> got sat-solver ported to MacOS, and I've pushed the changes upstream:
> http://gitorious.org/opensuse/sat-solver/merge_requests/2
>
> As you can see from that link, some tests are still failing for me,
> but I'm pretty sure that those first two are exercising the important
> functionality of the library and the others are merely failing
> (crashing) because of some problem I'm having with libexpat, which is
> used by the tests but not the sat-solver library itself. It would be
> awesome if someone else with a Mac or other BSD system could test this
> to see if it's something going on with my installation.
>
> Also, the project has a few pairs of test files whose path differ only
> in case, so I had to create a case-sensitive volume to be able to work
> on it. On a Mac, you can do that pretty easily with Disk Utility.
>
> Next steps:
>
> * Resolve Expat issues
> * Rename files to avoid case-sensitivity problems
> * Make the tests use Git instead of RPM
> * Port to Windows!
I made a clone on my windows box, I might be able to work on the windows
port some. The first thing that I found was stuff like this:
set ( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror -Wall" )
set ( CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS} -g -O3" )
set ( CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS} -g3 -O0" )
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
That will only work with gcc as the compiler as they are gcc flags.
Also, lots of include <unistd.h> and some other unix type headers.
Also, some use of inline in c code. So, it is going to take some effort
for the windows port... :(
I cloned from here:
git://gitorious.org/ryppl/opensuse/ryppl-sat-solver.git
Is that a good place for me to work from?
-Bill
David Abrahams
Bill Hoffman wrote:
>
> On 11/8/2010 2:41 PM, David Abrahams wrote:
> >
> > With some significant CMake help with Doug Gregor (thanks, Doug!), I
> > got sat-solver ported to MacOS, and I've pushed the changes upstream:
> > http://gitorious.org/opensuse/sat-solver/merge_requests/2
> >
> > As you can see from that link, some tests are still failing for me,
> > but I'm pretty sure that those first two are exercising the important
> > functionality of the library and the others are merely failing
> > (crashing) because of some problem I'm having with libexpat, which is
> > used by the tests but not the sat-solver library itself. It would be
> > awesome if someone else with a Mac or other BSD system could test this
> > to see if it's something going on with my installation.
> >
> > Also, the project has a few pairs of test files whose path differ only
> > in case, so I had to create a case-sensitive volume to be able to work
> > on it. On a Mac, you can do that pretty easily with Disk Utility.
> >
> > Next steps:
> >
> > * Resolve Expat issues
> > * Rename files to avoid case-sensitivity problems
> > * Make the tests use Git instead of RPM
> > * Port to Windows!
>
> I made a clone on my windows box, I might be able to work on the
> windows port some.
That would be *wonderful*, Bill!
> The first thing that I found was stuff like this:
>
>
> set ( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror -Wall" )
> set ( CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS} -g -O3" )
> set ( CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS} -g3 -O0" )
> SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
>
> That will only work with gcc as the compiler as they are gcc flags.
Yep, lots of what they've done clearly only considers Unix.
> Also, lots of include <unistd.h> and some other unix type
> headers. Also, some use of inline in c code.
Is that extension not supported by MS?
I'd be happy if we could get to MinGW first, if that makes anything
easier for you.
> So, it is going to take some effort for the windows port... :(
Hey, you mean it is going to take some *fun*, right? ;-)
>
> I cloned from here:
> git://gitorious.org/ryppl/opensuse/ryppl-sat-solver.git
>
> Is that a good place for me to work from?
Well, I just made that repo so I could push merge requests upstream.
I actually try to work out of GitHub:
https://github.com/ryppl/sat-solver So in general you can expect the
gitorious repo to hold changes I want them to merge, but the GitHub
repo will be where my development is happening.
Mateusz Loskot
I decided to give it a try and start porting the sat-solver to Windows
and Visual C++. Here is my clone of David's repo:
https://github.com/mloskot/sat-solver/
On 12/11/10 21:47, David Abrahams wrote:
> At Tue, 09 Nov 2010 23:01:31 -0500,
> Bill Hoffman wrote:
>> The first thing that I found was stuff like this:
>>
>> set ( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror -Wall" )
>> set ( CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS} -g -O3" )
>> set ( CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS} -g3 -O0" )
>> SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
>>
>> That will only work with gcc as the compiler as they are gcc flags.
>
> Yep, lots of what they've done clearly only considers Unix.
It's done in my clone.
As well as other necessary cleanup in CMakeLists.txt
I have also disabled some purely Unix/Linux features in the script,
like use of RPM library or Check, as there is no Windows port of those.
Should be reviewed, and either left disabled or ported.
>> Also, lots of include <unistd.h> and some other unix type
>> headers. Also, some use of inline in c code.
>
> Is that extension not supported by MS?
Indeed. It's safest if Visual C++ is considered C89 and not C99.
> I'd be happy if we could get to MinGW first, if that makes anything
> easier for you.
I personally stay away of MinGW and such and prefer using
native toolset for a platform.
>> I cloned from here:
>> git://gitorious.org/ryppl/opensuse/ryppl-sat-solver.git
>>
>> Is that a good place for me to work from?
>
> Well, I just made that repo so I could push merge requests upstream.
> I actually try to work out of GitHub:
> https://github.com/ryppl/sat-solver So in general you can expect the
> gitorious repo to hold changes I want them to merge, but the GitHub
> repo will be where my development is happening.
So, once again, here is my copy:
https://github.com/mloskot/sat-solver/
I started with sat-solver\src first. I think the result is not bad as I
managed to get to the point where I have regex.h missing and pread,
fcntl and qsort_r functions (assuming C4013 warning is error of course):
ClCompile:
repodata.c
..\..\sat-solver\src\repodata.c(28): fatal error C1083: Cannot open
include file: 'regex.h': No such file or directory
repopage.c
d:\dev\ryppl\_git\sat-solver\src\repodata.h(165): warning C4018: '<' :
signed/unsigned mismatch
..\..\sat-solver\src\repopage.c(721): warning C4013: 'pread' undefined;
assuming extern returning int
..\..\sat-solver\src\repopage.c(806): warning C4013: 'fcntl' undefined;
assuming extern returning int
..\..\sat-solver\src\repopage.c(806): error C2065: 'F_SETFD' :
undeclared identifier
..\..\sat-solver\src\repopage.c(806): error C2065: 'FD_CLOEXEC' :
undeclared identifier
util.c
..\..\sat-solver\src\util.c(122): warning C4013: 'qsort_r' undefined;
assuming extern returning int
Certainly, this is only a first phase: compile-time.
Once it compiles, it does not necessarily mean it will work
run-time out of the box.
BTW, 4-5 years ago, I was porting quite a lot of Unix packages to
Windows and even Windows CE. It is annoying job, but feasible.
Sometimes it requires to introduce a thing POSIX compatibility layer.
Here is one of those I made for Windows CE:
https://wcelibcex.svn.sourceforge.net/svnroot/wcelibcex/trunk/
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
David Abrahams
Mateusz Loskot wrote:
>
> Hi,
>
> I decided to give it a try and start porting the sat-solver to Windows
> and Visual C++.
Awesome!
> Here is my clone of David's repo:
>
> https://github.com/mloskot/sat-solver/
>
> On 12/11/10 21:47, David Abrahams wrote:
> > At Tue, 09 Nov 2010 23:01:31 -0500,
> > Bill Hoffman wrote:
> >> The first thing that I found was stuff like this:
> >>
> >> set ( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror -Wall" )
> >> set ( CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS} -g -O3" )
> >> set ( CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS} -g3 -O0" )
> >> SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
> >>
> >> That will only work with gcc as the compiler as they are gcc flags.
> >
> > Yep, lots of what they've done clearly only considers Unix.
>
> It's done in my clone.
> As well as other necessary cleanup in CMakeLists.txt
> I have also disabled some purely Unix/Linux features in the script,
> like use of RPM library or Check, as there is no Windows port of those.
> Should be reviewed, and either left disabled or ported.
Well, I think we'd better port Check at least, or we won't be able to
do any testing ;-)
As for RPM, it's used in the example installer
(https://github.com/mloskot/sat-solver/blob/master/examples/solv.c).
It's was my intention to try to replace the use of RPM with something
portable before trying to port that file to Windows. If you'd like to
think about what we can use as a replacement (do it entirely with
Git?), that might be useful.
> >> Also, lots of include <unistd.h> and some other unix type
> >> headers. Also, some use of inline in c code.
> >
> > Is that extension not supported by MS?
>
> Indeed. It's safest if Visual C++ is considered C89 and not C99.
OK
> > I'd be happy if we could get to MinGW first, if that makes
> > anything easier for you.
>
> I personally stay away of MinGW and such and prefer using
> native toolset for a platform.
OK, but "native" is a slightly fungible term, here. There are a few
other vendors for Windows C compilers out there. It would be nice to
support Intel, BCC, and Clang eventually.
Very good to know about that! Thanks.
Beman Dawes
>> > anything easier for you.
>>
>> I personally stay away of MinGW and such and prefer using
>> native toolset for a platform.
MinGW can be used with either the POSIX toolset or the Windows
toolset. I've had much less trouble with recent MinGW releases than
releases from even a year ago.
The MinGW distribution from
http://www.equation.com/servlet/equation.cmd?call=fortran seems
particularly trouble-free and more up-to-date than the Cygwin
distribution.
--Beman
Mateusz Loskot
> At Sat, 13 Nov 2010 03:53:32 +0000, Mateusz Loskot wrote:
>> Here is my clone of David's repo:
>>
>> https://github.com/mloskot/sat-solver/
>>
>> On 12/11/10 21:47, David Abrahams wrote:
>>> At Tue, 09 Nov 2010 23:01:31 -0500, Bill Hoffman wrote:
>>>> The first thing that I found was stuff like this:
>>>>
>>>> set ( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror -Wall" ) set
>>>> ( CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS} -g -O3" ) set (
>>>> CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS} -g3 -O0" )
>>>> SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
>>>>
>>>> That will only work with gcc as the compiler as they are gcc
>>>> flags.
>>>
>>> Yep, lots of what they've done clearly only considers Unix.
>>
>> It's done in my clone. As well as other necessary cleanup in
>> CMakeLists.txt I have also disabled some purely Unix/Linux features
>> in the script, like use of RPM library or Check, as there is no
>> Windows port of those. Should be reviewed, and either left disabled
>> or ported.
>
> Well, I think we'd better port Check at least, or we won't be able
> to do any testing ;-)
Yes, it is necessary I think.
There seem to be related patch in the Check SVN:
http://check.svn.sourceforge.net/viewvc/check/trunk/patches/
though I haven't tried it.
Perhaps the Check trunk should get into ryppl Git?
It is possible to keep Git repo synchronised against the SVN upstream.
Here is small howto in which I explain possible workflow:
http://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow
> As for RPM, it's used in the example installer
> (https://github.com/mloskot/sat-solver/blob/master/examples/solv.c).
> It's was my intention to try to replace the use of RPM with
> something portable before trying to port that file to Windows. If
> you'd like to think about what we can use as a replacement (do it
> entirely with Git?), that might be useful.
I have no idea of a packaging system replacement that would work on
Windows as described in the header of this file.
I know some software repositories use installer based on Cygwin, for
example:
http://trac.osgeo.org/osgeo4w/wiki/SetupDevelopment
http://trac.osgeo.org/osgeo4w/wiki/PackagingInstructions
>>> I'd be happy if we could get to MinGW first, if that makes
>>> anything easier for you.
>>
>> I personally stay away of MinGW and such and prefer using native
>> toolset for a platform.
>
> OK, but "native" is a slightly fungible term, here. There are a few
> other vendors for Windows C compilers out there. It would be nice
> to support Intel, BCC, and Clang eventually.
I wasn't precise. I have nothing against variety of compilers.
IMHO, MingW (MSYS), Cygwin are like installation of virtual POSIX
operating system inside another system, namely Windows, to make it POSIX
compliant. MinGW and Cygwin encourage developers to write their software
dedicated to POSIX and claim it's a portable software
what is certainly not true.
MinGW and Cygwin do bad work against real portability of C/C++ camp.
IMHO, it is not very different to asking users to install a Unix under
VM hosted on their Windows computers to allow them to run my software.
By the way, following your comments on github, #ifndef _MSC_VER around
individual headers are sort of a prototype and I think they eventually
should be replaced with the following pattern:
#include "config.h" /* defines HAVE_'s */
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif
Mateusz Loskot
> Perhaps the Check trunk should get into ryppl Git?
> It is possible to keep Git repo synchronised against the SVN upstream.
> Here is small howto in which I explain possible workflow:
>
> http://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow
I have followed the instructions on GitHub and here is the Check SVN
trunk cloned:
https://github.com/mloskot/check
I will try to push the porting forward for as long as time permit, but I
can't promise anything.
Mateusz Loskot
> On 13/11/10 13:34, Mateusz Loskot wrote:
>> Perhaps the Check trunk should get into ryppl Git?
>> It is possible to keep Git repo synchronised against the SVN upstream.
>> Here is small howto in which I explain possible workflow:
>>
>> http://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow
>
> I have followed the instructions on GitHub and here is the Check SVN
> trunk cloned:
>
> https://github.com/mloskot/check
>
> I will try to push the porting forward for as long as time permit, but I
> can't promise anything.
I have tried to apply the Windows patch
https://github.com/mloskot/check/blob/master/patches/check_windows.patch
but I'm getting plenty of errors thrown by the patching process.
The patch is ~150 revisions behind and I think it will need to be
applied manually, file by file. I will try to do it tonight.
Vladimir Prus
> I wasn't precise. I have nothing against variety of compilers.
>
> IMHO, MingW (MSYS), Cygwin are like installation of virtual POSIX
> operating system inside another system, namely Windows, to make it POSIX
> compliant. MinGW and Cygwin encourage developers to write their software
> dedicated to POSIX and claim it's a portable software
> what is certainly not true.
> MinGW and Cygwin do bad work against real portability of C/C++ camp.
I don't think that's correct. On the "set of commands you can run", both
msys and cygwin indeed try to provide a set of commands typical POSIX
system might have.
However, on API level, mingw and cygwin g++ are radically different. While
cygwin tries to present posix API, to the point of emulating 'fork' at great
expense, mingw is a port of gcc to windows. When using mingw you'd
probably use windows.h, and windows API functions.
- Volodya
David Abrahams
Mateusz Loskot wrote:
>
> On 13/11/10 14:22, Mateusz Loskot wrote:
> > On 13/11/10 13:34, Mateusz Loskot wrote:
> >> Perhaps the Check trunk should get into ryppl Git?
> >> It is possible to keep Git repo synchronised against the SVN upstream.
> >> Here is small howto in which I explain possible workflow:
> >>
> >> http://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow
> >
> > I have followed the instructions on GitHub and here is the Check SVN
> > trunk cloned:
> >
> > https://github.com/mloskot/check
> >
> > I will try to push the porting forward for as long as time permit, but I
> > can't promise anything.
>
> I have tried to apply the Windows patch
>
> https://github.com/mloskot/check/blob/master/patches/check_windows.patch
>
> but I'm getting plenty of errors thrown by the patching process.
> The patch is ~150 revisions behind and I think it will need to be
> applied manually, file by file. I will try to do it tonight.
Maybe it would make sense to apply it to the master branch ~150
revisions back and then rebase. Don't know if that would work better,
but it might.
David Abrahams
Mateusz Loskot wrote:
>
> Perhaps the Check trunk should get into ryppl Git?
> It is possible to keep Git repo synchronised against the SVN upstream.
> Here is small howto in which I explain possible workflow:
>
> http://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow
IMO this should be done with a submodule for Check.
> > As for RPM, it's used in the example installer
> > (https://github.com/mloskot/sat-solver/blob/master/examples/solv.c).
> > It's was my intention to try to replace the use of RPM with
> > something portable before trying to port that file to Windows. If
> > you'd like to think about what we can use as a replacement (do it
> > entirely with Git?), that might be useful.
>
> I have no idea of a packaging system replacement that would work on
> Windows as described in the header of this file.
Which file? solv.c? I don't see much of a description there... but
if I look at what's being done in there, it doesn't seem like it can
really depend on very much of RPM. Oh, hey, it also looks like we
could just as easily depend on dpkg instead, if that helps.
> I know some software repositories use installer based on Cygwin, for
> example:
I don't think that's what we're after. solv.c is supposed to be
taking on that role. I think we need to figure out exactly what it's
using RPM/dpkg for.
Mateusz Loskot
I've tried this approach and, what doesn't surprise me, it eventually
results with plenty of warnings while updating.
I regret, but I have to put it away for now and get back to other calls
I've diverted from.
Brian Schrom
> The MinGW distribution from
> http://www.equation.com/servlet/equation.cmd?call=fortran seems
> particularly trouble-free and more up-to-date than the Cygwin
> distribution.
I've enjoyed the cross compile MinGW tools on Linux as well.
Admittedly, I've only used pretty small projects so far and haven't
tried things like threads.
David Abrahams
Well, thanks so much for your work so far; I know it will be a huge
help, as nobody else here has much experience, that I know of, with
thin POSIX layers. Maybe Bill H. can pick up where you left off. :-)
Mateusz Loskot
I will try to get back to it if time permits.
However, if anyone could push it forward, would be great indeed.