[gdal-dev] Questions about building 1.11.0beta1 on Windows

[Even Rouault]

Le mardi 15 avril 2014 17:11:02, Carl Godkin a écrit :
> Hi,
> 
> I tried out 1.11.0beta1 yesterday and today and everything I have tried
> seems fine to me on Win64.
> 
> I have two small questions:
> 
> 1. I really like the change in the Windows build procedure that introduces
> the "nmake.local" include in which I can put many of my growing collection
> of local edits.  I say "many" instead of "all" because I don't see how to
> effectively "comment out" a makefile variable using the nmake.local method.
> 
> For instance, I want to build without ODBC support.  The nmake.opt file
> contains the instruction
> 
> # Comment out the following to disable ODBC support.
> ODBC_SUPPORTED = 1
> 
> Can anyone think of a way to undo the ODBC_SUPPORTED definition
> (on by default) from nmake.local?  The variable is later checked in three
> places with "!IFDEF ODBC_SUPPORTED" so changing its value won't work, not
> to mention that the nmake.local inclusion comes before ODBC_SUPPORTED
> definition.

It would probably be a matter of changing that to something like

!IFNDEF ODBC_SUPPORTED
ODBC_SUPPORTED = 1
!ELSE
!IF "$(ODBC_SUPPORTED)" != "1"
ODBC_SUPPORTED  =
!ENDIF
!ENDIF

That way if nothing is specified in nmake.local, it would default to 
ODBC_SUPPORTED=1 as currently. And if you define it to 0 in nmake.local, it 
would be disabled.

Completely untested...

> 
> 2. When building on Win64, I always notice lots of warnings (C4244 and
> C4267) that arise because of implicit conversions from (say) size_t to int.
>  I was wondering why many open source projects (including GDAL) don't seem
> to fix these - is it because the necessary casts make the code less
> readable in someone's opinion?  Or is it just because no one has gotten
> around to it?  If it's the latter, I would be willing to submit a ticket
> with some patches.  It seems a pity to build with /W4 but put up with so
> many warnings.

Yes, I guess correcting warnings is not very fun. You can try to fix them and 
submit a patch, but be careful that automatic casting is not always the most 
appropriate fix for a warning. Sometimes it is just a sign that the target type 
should be fixed. It would be good if you can also separate a patch to GDAL own 
code, from patches to imported external libraries in the GDAL source tree 
(libtiff, libgeotiff, libpng, libjpeg, giflib, degrib, etc..). For the later 
ones, the fixes should be submitted first to the upstream projects.

Even


-- 
Geospatial professional services
http://even.rouault.free.fr/services.html