[Gdal-dev] A build solution for VC7

Frank Warmerdam warmerdam at pobox.com
Wed Mar 10 09:36:24 EST 2004


Ben Discoe wrote:
> Easy way?  Well, the right way would be to fix 'em.  I tried swabbing out
> bunches of them this evening.  It's a big task.  Worth it, in my opinion.
> Code that compiles cleanly w/o hundreds of warnings is code you can feel
> good about.  But that's up to the GDAL team to decide.

Folks,

I'm not too sure what size_t warnings are being referred to.   Could someone
quote an example?

> Sure, we could disable warning C4267, but there's not much point in a
> cosmetic solution.

I disagree Ben.  There is a very good reason for a "cosmetic" solution that
disables a common warning.  It ensures that any other warnings will stick out.

The point of cleaning up non-dangerous warnings isn't to make us feel good
about the code.  It isn't because the thing in question is dangerous in itself.
It is because if we have lots of "junk" warnings we won't notice the ones we
should be keeping an eye out for, and then they won't help us.

When I build with NMAKE on VC7 I normally disable warnings 4706, 4127 and 4100.
With those supressions in place, I thought I was getting a fairly clean build.

I am interested in having clean builds though there are a few caveats.
  o There is some stuff in libtiff that I have reviewed but am hesitant to
    fiddle with even though it gives warnings on most compilers.
  o VC7 has raised the bar substantially in "pickyness" compared to VC6.  Given
    that I rarely work in this environment, there is a limit to how much work I
    will do to get clean builds in it.  My standard build environment is Linux
    GCC with -Wall (all warnings).

I am coming around to feel that it might be wise to include the Visual Studio
projects in future releases since there is obviously quite a bit of interest.
Is there a way of including the list of object files for a visual studio project
from an extra file?   It would be much easier to maintain the visual studio
projects if they could use the same list of source files as the NMAKE based
build and the Unix builds.  For instance, if I could have a "file.lst" in
each directory that assigns the list of .obj files for that directory to an
OBJ macro.  This could be used in the NMAKE files, and I could also use them
on unix since GNUmakefiles can easily transform the file list (converting .obj
to .o for instance).  If I could use the same file lists for a project file, it
would be (potentially) worth the effort to maintain it.

Of course, I just know people will start using the project files and then
start asking me all sorts of annoying questions I can't answer.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent




More information about the Gdal-dev mailing list