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

[Rajat Shinde]

+0

Looks good to me but I need some time to understand everything mentioned
here (which shouldn't be a blocker for development).

Thanks for your efforts.
Best,
Rajat

On Tue, Apr 11, 2023 at 1:04 PM Ashish Kumar <ashishkr23438 at gmail.com>
wrote:

> +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
>>
> _______________________________________________
> 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/20230418/eaaad64a/attachment.htm>