opencog-dev team mailing list archive

[Gustavo Machado Campagnani Gama <gama@xxxxxxxxxxxxx>]

On Wed, 2008-06-18 at 21:11 +1000, Trent Waddington wrote:
> On Wed, Jun 18, 2008 at 6:04 PM, Trent Waddington
> <trent.waddington@xxxxxxxxx> wrote:
> > It doesn't like me, I'm trying with "Visual Studio 8 2005" and it's
> > giving me the attached errors.
> >
> > I'm trying "nmake makefiles" now, seems to be better, but I'd love to
> > know what its problem is.
> 
> So after trying to get nmake makefiles to work, I gave up and went
> back to "Visual Studio 8 2005" and it magically started working.
> CMake is strange.
> 
> I had to modify my CMakeCache.txt and manually add all the paths to
> the includes and libs of all the third party stuff.  I see a
> dependency on OpenSSL that I hadn't seen before, is that new?

Well, since Windows doesn't have a proper system to resolve
dependencies, I'm afraid this is inevitable.

OpenSSL was added because it is a dependency of CSockets on Linux. It
might be possible to build CSockets without SSL support so that we may
ditch at least this dependency.

Eventually I plan to (try to) get rid of STLPorts too (and use MSVC's
implementation).

> Finally it generated some vcproj files.  The first problem I found is
> that we have a config.h and so does pthreads.  It is in the path
> before src/Util so it gets included first and then we don't.  So my
> solution at the moment is to move the pthreads config.h away.  An
> alternative would be to change the path ordering, but I want to see if
> this pthreads config file is really needed.. I expect it is cruft.

Windows and its case-insensitive filesystems! ARGH!! I had to rename the
"CogServer" target to "Server" for a similar reason. Anyway, the odd
thing is the version of pthreads I'm using doesn't have a "config.h".
I've used the latest version from Sourceware.org:

ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-8-0-release.exe

And, while we're on the subject of case-sensitivity, what do y'all think
about using a consistent standard to name directories and rename
"AtomSpace", "Util", "NMXml" and "CogServer" to "atomspace", "util",
"xml" and "server"?

> I had a little trial and error with the CSockets include.. it wants
> the dir with the headers, not the parent dir with Sockets/ in it, that
> seems obvious in retrospect.  Similarly for expat.. kind of strange
> that CMake doesn't check for the header before shoving it into the
> vcproj file. I had a typo in another lib dir, it didn't find that
> either. Oh well.

I wrote the FindCSockets.cmake, so it's likely that there's still some
bugs in there. It was based on the Expat Find*.cmake which "forces" you
to not prefix your include statements. Boost (and probably several other
libraries), on the other hand, doesn't do that: it requires you to add
the prefix "boost/" to your includes. I guess this is due to the nature
of the project: many of Boost's headers have very generic names so it's
important to use the prefix to avoid conflicts.

> Ok, this is really strange, during the build of one of the projects, a
> new Visual Studio window opens up.. with nothing loaded.  Happens
> every time.  Hmm, seems it's your test/tests projects.. the custom
> build rule for tests runs devenv.. what are you trying to do here?

The idea was to add a "test" target that runs the tests, but depends on
another target that *builds* the tests first. The problem is that if try
to use "ENABLE_TESTING()", "make test" works, but I can't add a
dependency to the "tests" target. The solution I came up with (and it
actually works pretty well for Unix's Make and Win32's NMake) is to
create a custom "test" target that is pretty much a copy&paste of the
(hidden) "test" target created by "ENABLE_TESTING()".

Unfortunately, as you've just noticed, it doesn't work for Visual
Studio... :-( I'll probably just add an "IF (WIN32)" test for the time
being. If you have any better ideas, I'm all ears.

Now, since you already have your environment set, could you also try the
latest update to the lp:~gama/opencog/win32 branch? It (should) remove
all warnings from the build process.

Thanks again,

--
Gustavo