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

[Ko Nagase]

Hi Vicky, list,

I am one of the developers who introduced MSVC build support in the
following PR,
https://github.com/pgRouting/pgrouting/pull/590

but, +1 to remove MSVC support (at least, until some solutions will be found).

P.S.
Thanks for maintaining the MSVC build via CI (past AppVeyor to GitHub Actions)
for a long time (almost 7 years) !

Regards,
Nagase

2023年4月12日(水) 1:26 Vicky Vergara <vicky at erosion.dev>:

>
> 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