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

[Vicky Vergara]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20230411/2866e2cf/attachment.htm>