[pdal] Entwine fails to build after recent PDAL LAS refactoring

[Jim Klassen]

A compatibility layer would be nice where practical, maybe marked with the [[deprecated]] attribute.  I'm not sure that all the refactoring that has been done is amenable to that.  I also don't want PDAL to be held back or code quality to suffer from not refactoring when appropriate.

A minimal solution might be to call the next PDAL release version 3.0 to call attention to the API incompatibility.  That way projects can either specify they need 2.3 or test for 2.3 vs 3.0 and behave accordingly.  And then packagers will also get a heads up that something changed where they need to pay extra attention.

That's my 2 cents.

On 1/26/22 07:28, Andrew Bell wrote:
> There may still be changes before release. I've tried to maintain API in the past and it may be worth sticking a layer on top of what''s in master to support users who have already made PDAL part of their code. Unfortunately, our API became everything, because there was no line drawn between private code and public code from the library's outset. I've tried to correct some of that, but haven't been terribly successful.
>
> On Fri, Jan 21, 2022 at 10:12 AM Howard Butler <howard at hobu.co> wrote:
>
>     Indeed, the LAS code was refactored to bring together COPC/EPT and LAS/LAZ common components. The LAS code was pseudo-private to PDAL, and so we reserved the right to change it as needed given PDAL's more public interfaces.
>
>     We hope and expect that these changes weren't too disruptive, but we would much rather add missing things that are needed instead of supporting the previous behaviors and classes. Please reach out if there is something that cannot be done with the new pseudo-internal API that was available before.
>
>
>
>     > On Jan 21, 2022, at 3:34 AM, Jean-Roc Morreale (ml) <jrmorreale_ml at enoreth.net> wrote:
>     >
>     > Hi,
>     >
>     > For CloudCompare, the PDAL plugin is being rewritten :
>     > https://github.com/CloudCompare/CloudCompare/pull/1561
>     >
>     > as the plugin does not compile against current PDAL :
>     > https://github.com/CloudCompare/CloudCompare/issues/1573
>     >
>     > Le jeudi 20 janvier 2022 à 14:22 -0600, Jim Klassen a écrit :
>     >> The recent changes to the LAS code broke the entwine build in
>     >> entwine/util/pipeline.cpp.  It looks like things like `scaleX()` need
>     >> to be updated to `scale.x`.  I also suspect these changes probably
>     >> also impact the CloudCompare PDAL plugin.
>     >>
>     >> However, I'm not sure where the fix should be:
>     >>
>     >> Is this a bug in entwine (and likely CloudCompare) for using a pdal
>     >> API that is intended to be private (and they should be using entirely
>     >> other means for accessing this information)?
>     >>
>     >> Is this an issue where entwine needs to be updated to match the
>     >> current pdal API?
>     >>
>     >> Is this an issue in pdal for changing the existing API?
>     >>
>     >> Some/all/none of the above?
>     >> _______________________________________________
>     >> pdal mailing list
>     >> pdal at lists.osgeo.org
>     >> https://lists.osgeo.org/mailman/listinfo/pdal
>     >
>     > _______________________________________________
>     > pdal mailing list
>     > pdal at lists.osgeo.org
>     > https://lists.osgeo.org/mailman/listinfo/pdal
>
>     _______________________________________________
>     pdal mailing list
>     pdal at lists.osgeo.org
>     https://lists.osgeo.org/mailman/listinfo/pdal
>
>
>
> -- 
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20220126/b7f87842/attachment.html>