[gdal-dev] gdal-dev Digest, Vol 160, Issue 61
Ilya Varaev
ivar at avenza.com
Wed Sep 27 15:38:02 PDT 2017
+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, <gdal-dev-request at lists.osgeo.org> wrote:
> Send gdal-dev mailing list submissions to
> gdal-dev at lists.osgeo.org
>
> 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
> gdal-dev-request at lists.osgeo.org
>
> You can reach the person managing the list at
> gdal-dev-owner at lists.osgeo.org
>
> 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 <even.rouault at spatialys.com>
> To: gdal-dev at lists.osgeo.org
> Subject: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds
> Message-ID: <5929234.EW3oT5kK1v at 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 <mateusz at loskot.net>
> To: Even Rouault <even.rouault at spatialys.com>
> Cc: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds
> Message-ID:
> <CABUeae8xQpZ3ORROb9Oc1E5dj9oZeAn6E70GV=4vpxLsyi8_EQ at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On 27 September 2017 at 21:38, Even Rouault <even.rouault at spatialys.com>
> 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 <even.rouault at spatialys.com>
> To: Andrew Joseph <ap.joseph1337 at gmail.com>
> Cc: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] Determining Native Data Field Type Names for a
> Given Layer or Driver
> Message-ID: <1712076.mIpcWRE8p1 at 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 <jmckenna at gatewaygeomatics.com>
> To: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds
> Message-ID:
> <c090f7be-4069-bdbe-9920-beb5eaace6c9 at gatewaygeomatics.com>
> 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 <cgodkin at gmail.com>
> To: Even Rouault <even.rouault at spatialys.com>
> Cc: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds
> Message-ID:
> <CAE=8km=k03jw4h+O2iB1NoAREfmgJs7kAYz8zLoci-
> i7L_NN9A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Sep 27, 2017 at 12:38 PM, Even Rouault <even.rouault at spatialys.com
> >
> 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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> ------------------------------
>
> End of gdal-dev Digest, Vol 160, Issue 61
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170927/a7983cda/attachment.html>
More information about the gdal-dev
mailing list