[Opengc-devel] OpenGC build status

[Damion S. <dam...@ho...>]

Hi,

A quick note that both Windows and Linux builds are now working. There's an
issue with the geo_pos.h file defining a round(double) function works fine
under Redhat Linux and Visual Studio .NET but not on Mandrake Linux. I'm
going to assume that the majority rules, and there's something wrong with
Mandrake... more exploration is needed.

Another note for Windows users: use FLTK 1.1 and _not_ 1.1.1; there's a link
error with the latter that I haven't been able to debug. If you're
downloading a fresh copy, you may need to directly access one of the FLTK
ftp servers rather than using their link button.

A few things I jotted down when getting the Linux build to work:

1) Problem noted with round() function

2) added geo_pos.h include to latlongc.cpp

3) numerous capitalization corrections - Windows users, please be aware that
myFilename.cpp, MyFilename.cpp, and MYFILENAME.CPP are all different files
on Unix platforms and includes will not work correctly unless the
capitalization is correct.

4) I changed the case of uppercase filenames in /Math to lowercase to match
the other files and fix problems related to (3) above. Note that the
uppercase versions are no longer in the repository - if anyone has made
changes to these and hasn't updated recently, be careful when you do so that
you don't lose your work. In the future, I'd suggest that either camel
hump - myFileName.cpp - or lowercase, myfilename.cpp - style be used. All
files that are prefaced with ogc should use camel hump: i.e. ogcDataSource.h

5) I'm toying with the idea of switching all includes defined as
</Foo/File.h> to "File.h". The former is system path form, while the latter
is local form. I had to correct many case problems here as well, and the
addition of the /Foo path is not neccessary since the CMakeLists.txt file
sets up include directories for the compiler. Therefore, if any directories
change name or files are moved, it's not neccessary to modify every file
that includes the desired target. I started the <Foo/File.h> convention to
begin with, but I think I'll reverse my position and encourage the straight
"File.h" form in the future unless anyone has a strong argument to the
contrary.

I'll post updated build instructions over the next several days along with a
binary Linux release.

Cheers,
-Damion-