[pgrouting-dev] MOTION: Remove support for compilation with MSVC

[Ashish Kumar]

+1, looks good.

Regards,
Ashish.


On Tue, 11 Apr 2023 at 21:56, Vicky Vergara <vicky at erosion.dev> wrote:

> Hello all:
> PSC: Please send your vote on this motion
> General developers: If you see fit, please let us know what you think.
>
> I am opening this motion, because of the following:
> During the last 10 years an effort has been made to standardize the code
> base of pgRouting.
> With this standardization, adding new functionality has been getting
> "easier".
> TRSP was a stopper, on simplifying the code base as it did not follow the
> standard we have been using these last years, but finally on 3.4, we
> managed to rewrite the code and fix a lot of bugs that pgr_trsp had:
> Before: https://docs.pgrouting.org/3.3/en/pgr_trsp.html
> That starting from 3.4 has become:
> https://docs.pgrouting.org/3.4/en/pgr_trsp.html
> https://docs.pgrouting.org/3.4/en/pgr_trsp_withPoints.html
> https://docs.pgrouting.org/3.4/en/pgr_trspVia.html
> https://docs.pgrouting.org/3.4/en/pgr_trspVia_withPoints.html
> (the old functionality is still available)
>
> As standardized code, I mean files/and functions (visually) look very
> similar and they work in a similar way. On Monday April 10, I made a twitch
> about the following PR
> https://github.com/pgRouting/pgrouting/pull/2504
> The twitch channel:
> https://www.twitch.tv/cvvergara
> Where I explain the commonality of the "*_input" files, and how the work
> was done to simplify the base code of pgRouting. (2 hours aprox)
> There is one problem that is out of our control with MSVC and postgres,
> where we are not alone, as plv8 also has the same problem. (detail on the
> issue).
>
> By doing the changes proposed on the PR, it will be avoided problems
> generated from the copy/paste and "forgot to adjust something",
> for example:
>
> https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L243
> Clearly the file was copied from the orders_input file, but "forgot to
> change the word "Orders" to "vehicles".
> Also, those PGR_DBG are for developing purposes, and "forgot to delete
> those PGR_DBG" statements. This is a "Development problem".
> We also might have "Maintenance problems", for example, because of the
> interaction with postgres like the data type Portal:
>
> https://github.com/pgRouting/pgrouting/blob/main/src/common/vehicles_input.c#L196
> if for some reason whatsoever, the PostgreSQL team decides to change the
> name of the data type, we have zillions of places where we need to do a
> change.
>
> By using C++ and having a template:
>
> https://github.com/pgRouting/pgrouting/pull/2504/commits/38ebae23a5d65e98590f4d3a817ebea419a6f6c5
>
> * the type that postgres has its captured automatically, for example:
> auto SPIportal = pgr_SPI_cursor_open(SPIplan);
> * The code is clean, we don't need to use PGR_DBG like before, with manual
> copy/paste and adjustment, something might be missing, and we need to
> debug, but then, when things work, we forget that we don't need to debug
> anymore.
>
> So a lot of problems for developing and maintenance are solved by using
> C++ instead of C and using templates on similar code.
>
> This is a first step, and a crucial one as there is a function static
> void process within the C files, that connect with postgres, where they
> make the calls to get the data from postgres.
> and they are all similar,  therefore they are candidates to become
> templates
>
> This experiment:
> https://github.com/pgRouting/pgrouting/pull/2473
> Although not using a template, but using a single file to process 2
> pgrouting functions, demonstrates that templating can be achieved, and the
> getters will be called from within C++ code.
>
> So the getters,/fetchers/check code on the
> https://github.com/pgRouting/pgrouting/pull/2504
> that interact with postgres, it's a "must" to be in C++, this "must" does
> not work well on MSVC.
> Which by the way, been the main developer of pgRouting, I haven't touched
> a windows machine, let alone MSVC since 1997, So from my point of view,
> developing pgRouting with MSVC is not a priority, what is the priority is
> that it still be compiled with msys2/mingw64 (whatever that is) and that
> can be package for windows. (Which Regina has confirmed can be done)
>
> Regards
> Vicky
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20230411/30a2248f/attachment.htm>