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

[Cayetano Benavent]

+1 as I don't see the interest to keep compatibility with MSVC in 2023.
Thanks Vicky.

El mar, 18 abr 2023, 19:01, Rajat Shinde <rajatshinde2303 at gmail.com>
escribió:

> +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
>>
> _______________________________________________
> 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/4f55ec49/attachment.htm>