+1 here. One of a few changes in.the opt file we've had for many years is "/MD" to "/MDd" in debug, so yes, it makes perfect sense. ivar
> Hi Even, > > > Since you ask, I can tell you that changing "/MD" to "/MDd" is one of just > two remaining edits that I have to make to nmake.opt before I build a new > version of GDAL. We do most of our development on Windows and port to > Linux so I think we do the opposite of how it sounds like you work. > > So we'd prefer /MDd. On Wed, Sep 27, 2017 at 6:08 PM, <[email protected]> wrote: > Send gdal-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osgeo.org/mailman/listinfo/gdal-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gdal-dev digest..." > > > Today's Topics: > > 1. /MD vs /MDd for DEBUG MSVC builds (Even Rouault) > 2. Re: /MD vs /MDd for DEBUG MSVC builds (Mateusz Loskot) > 3. Re: Determining Native Data Field Type Names for a Given > Layer or Driver (Even Rouault) > 4. Re: /MD vs /MDd for DEBUG MSVC builds (Jeff McKenna) > 5. Re: /MD vs /MDd for DEBUG MSVC builds (Carl Godkin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Sep 2017 21:38:15 +0200 > From: Even Rouault <[email protected]> > To: [email protected] > Subject: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds > Message-ID: <5929234.EW3oT5kK1v@even-i700> > Content-Type: text/plain; charset="utf-8" > > Hi, > > For those who don't understand the title, you may skip this email ;-) > > Once again someone raised an issue about the MSVC runtime we use for > DEBUG=1 builds: > https://trac.osgeo.org/gdal/ticket/7059 > > and in https://trac.osgeo.org/gdal/ticket/6384 about the same issue, > there are 4 similar > tickets raised. > > So it seems our default is a recurring problem. > > Personnaly I believe I've never used a Windows build, so I'm mostly > indifferent > > Any opinion about using the debug MSVC runtime (/MDd) for DEBUG=1 builds > instead of the > current release runtime (/MD) ? > > Even > > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.osgeo.org/pipermail/gdal-dev/ > attachments/20170927/8b7dcad4/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Wed, 27 Sep 2017 21:52:45 +0200 > From: Mateusz Loskot <[email protected]> > To: Even Rouault <[email protected]> > Cc: [email protected] > Subject: Re: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds > Message-ID: > <CABUeae8xQpZ3ORROb9Oc1E5dj9oZeAn6E70GV=4vpxLsyi8_EQ@mail. > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On 27 September 2017 at 21:38, Even Rouault <[email protected]> > wrote: > > > > Once again someone raised an issue about the MSVC runtime we use for > DEBUG=1 > > builds: https://trac.osgeo.org/gdal/ticket/7059 > > > > [...] > > Personnaly I believe I've never used a Windows build, so I'm mostly > > indifferent > > > > Any opinion about using the debug MSVC runtime (/MDd) for DEBUG=1 builds > > instead of the current release runtime (/MD) ? > > Even, > > Yesterday, I started thinking about adding an extra build configuration to > NMAKE > makefile, controlled via command line defines, to enable such proper/full > debug > build for Windows. > > IMO, debug builds w/o /MDd are somewhat unexpected or exotic. > As one of Windows users and developers, I'd vote for the default > MSVC configuration for debug builds of GDAL. > > This would also help a bit with binary packages for Visual C++, > currently, it requires nmake.opt patching. > https://github.com/Microsoft/vcpkg/pull/1879 > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > > > ------------------------------ > > Message: 3 > Date: Wed, 27 Sep 2017 22:32:23 +0200 > From: Even Rouault <[email protected]> > To: Andrew Joseph <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [gdal-dev] Determining Native Data Field Type Names for a > Given Layer or Driver > Message-ID: <1712076.mIpcWRE8p1@even-i700> > Content-Type: text/plain; charset="utf-8" > > On mercredi 27 septembre 2017 15:22:15 CEST Andrew Joseph wrote: > > Thanks, this worked out better than I could have hoped! I used: > > > > final String url = "/test_data/shapefiles/myshp.shp"; > > final Dataset shapefileDs = gdal.OpenEx(url); > > final Vector<String> options = new Vector<>(Arrays.asList( > > "-of", "PGDump", > > "-where", "0=1", > > "-lco", "FID=fid", > > "-lco","GEOMETRY_NAME=geom", > > "-lco","LAUNDER=NO")); > > > > gdal.VectorTranslate("/vsistdout", shapefileDs, new > > VectorTranslateOptions(options)); > > > > In terms of efficiency, is it better to use -limit 0 or -where FALSE? > > Ah yes, -limit 0 will work much faster. > > > > > Also, is there any means of removing the BEGIN; and COMMIT; statements? > > I don't think so. > > > > > As a side note, I noticed that the BEGIN; statement in the dump is > issued > > after the DROP TABLE -which would mean the relevant table would be > deleted > > even if the data load transaction failed -not sure if this is intended > > behavior or a bug. > > I'm not completely sure if it is intended or not. From what I see, the PG > driver does the same > thing. There are perhaps issues with dropping a table in a transaction. I > remember having > some issues recently when creating (and perhaps overwriting) > hundreds/thousands of tables > in the same ogr2ogr invokation. This exhausted some PG server limitation. > > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.osgeo.org/pipermail/gdal-dev/ > attachments/20170927/09c3bba7/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Wed, 27 Sep 2017 19:05:12 -0300 > From: Jeff McKenna <[email protected]> > To: [email protected] > Subject: Re: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 2017-09-27 4:38 PM, Even Rouault wrote: > > Hi, > > > > For those who don't understand the title, you may skip this email ;-) > > > > Once again someone raised an issue about the MSVC runtime we use for > > DEBUG=1 builds: > > > > https://trac.osgeo.org/gdal/ticket/7059 > > > > and in https://trac.osgeo.org/gdal/ticket/6384 about the same issue, > > there are 4 similar tickets raised. > > > > So it seems our default is a recurring problem. > > > > Personnaly I believe I've never used a Windows build, so I'm mostly > > indifferent > > > > Any opinion about using the debug MSVC runtime (/MDd) for DEBUG=1 builds > > instead of the current release runtime (/MD) ? > > > > Even > > > > The fix proposed in ticket 7059 makes sense, I see the problem here in > my local nmake, so +1 > > But I don't understand Mateusz's response. I think the change in ticket > 7059 should be made, and no changes to any defaults, because packagers > by default are not sharing default builds. Again, maybe I am > misunderstanding Mateusz's message. > > -jeff > > > > -- > Jeff McKenna > MapServer Consulting and Training Services > http://www.gatewaygeomatics.com/ > > > ------------------------------ > > Message: 5 > Date: Wed, 27 Sep 2017 15:08:28 -0700 > From: Carl Godkin <[email protected]> > To: Even Rouault <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds > Message-ID: > <CAE=8km=k03jw4h+O2iB1NoAREfmgJs7kAYz8zLoci- > [email protected]> > Content-Type: text/plain; charset="utf-8" > > On Wed, Sep 27, 2017 at 12:38 PM, Even Rouault <[email protected] > > > wrote: > > > Hi, > > > > > > > > For those who don't understand the title, you may skip this email ;-) > > > > > > > > Once again someone raised an issue about the MSVC runtime we use for > > DEBUG=1 builds: > > > > https://trac.osgeo.org/gdal/ticket/7059 > > > > > > > > and in https://trac.osgeo.org/gdal/ticket/6384 about the same issue, > > there are 4 similar tickets raised. > > > > > > > > So it seems our default is a recurring problem. > > > > > > > > Personnaly I believe I've never used a Windows build, so I'm mostly > > indifferent > > > > > > > > Any opinion about using the debug MSVC runtime (/MDd) for DEBUG=1 builds > > instead of the current release runtime (/MD) ? > > > > > > > > > > > Hi Even, > > Since you ask, I can tell you that changing "/MD" to "/MDd" is one of just > two remaining edits that I have to make to nmake.opt before I build a new > version of GDAL. We do most of our development on Windows and port to > Linux so I think we do the opposite of how it sounds like you work. > > So we'd prefer /MDd. > > (By the way, the other item in nmake.opt that I can't override with an > EXT_NMAKE_OPT > file is that we don't want to build with > > ODBC_SUPPORTED = 1 > > If that were changed to use the !IFNDEF ODBC_SUPPORTED then I wouldn't have > to edit nmake.opt at all which would be very handy.) > > Thanks very much, > > carl > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.osgeo.org/pipermail/gdal-dev/ > attachments/20170927/1b233e13/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > ------------------------------ > > End of gdal-dev Digest, Vol 160, Issue 61 > ***************************************** >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
