Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide proper EuclideanClusterComparator method depreciation. New Pragma macro. New Deprecated type. #2096

Merged
merged 4 commits into from
Nov 27, 2017

Conversation

SergioRAgostinho
Copy link
Member

Here's something for us to discuss: in order allow us saving time cleaning things in the future, I created an intermediate class (which can't be directly instantiated), and implements what's gonna be the final functionality of the ECC. It will just suffer a rename later on.

I replaced the map for a set as pointed out before.

Closes #2091

@SergioRAgostinho SergioRAgostinho added changelog: behavior change Meta-information for changelog generation changelog: ABI break Meta-information for changelog generation labels Nov 21, 2017
@SergioRAgostinho SergioRAgostinho added this to the pcl-1.9.0 milestone Nov 21, 2017
@taketwo
Copy link
Member

taketwo commented Nov 23, 2017

I'm not sold by the EuclideanClusterComparator2 class, I think it introduces confusion for those who are not aware of all this deprecation business. It will show up generated documentation (but without any apparent explanation what it is). Some people may try to use it and next PCL release will break their code. To simplify cleaning this up in the future, maybe just group changes that "bring back" old interface into a single commit that can be easily reverted afterwards?

Other random comments:

  • Now that we use pragma messages to warn about deprecation, maybe we should disable -W#pragma-messages when building PCL? (But not user code using PCL, of course)
  • What does "changes: behavior" label mean?

@SergioRAgostinho
Copy link
Member Author

To simplify cleaning this up in the future, maybe just group changes that "bring back" old interface into a single commit that can be easily reverted afterwards?

👍

Now that we use pragma messages to warn about deprecation, maybe we should disable -W#pragma-messages when building PCL?

Fair enough. Although I just did it like that because I can't seem find a way to deprecate a template parameter, because the entire class is not gonna be deprecated. Normally, upon deprecation there's a transient period in which the old definition and the new one coexist and you tell people to migrate. In our case we still want to preserve the class name and that is messing up the process.

What does "changes: behavior" label mean?

Something which didn't break the ABI/API but in which the class behavior/output changed compared to before. Originally it was to signal that we are no longer using normals in the clustering process. In this particular PR it was misused, because I'm only adding the old interface.

@SergioRAgostinho SergioRAgostinho removed the changelog: behavior change Meta-information for changelog generation label Nov 23, 2017
@taketwo
Copy link
Member

taketwo commented Nov 23, 2017

Something which didn't break the ABI/API but in which the class behavior/output changed compared to before.

But even the original PR did not change behavior, because normals and angular threshold were not used at all? Or did I misunderstand something?

@SergioRAgostinho
Copy link
Member Author

But even the original PR did not change behavior, because normals and angular threshold were not used at all? Or did I misunderstand something?

That's right. The class had normals as class members but did nothing with them.

@taketwo
Copy link
Member

taketwo commented Nov 23, 2017

By the way, I think I have figured out a way to deprecate template parameter. Will post a proof-of-concept soon.

@SergioRAgostinho
Copy link
Member Author

Awesome! Should we delete the macros I added or shall we leave them?

@taketwo
Copy link
Member

taketwo commented Nov 23, 2017

Wait, maybe you won't like my solution :)

@taketwo
Copy link
Member

taketwo commented Nov 23, 2017

Here we go: http://cpp.sh/2pyit

@SergioRAgostinho
Copy link
Member Author

Oh that looks cool. I actually thought that would be considered a redefinition of A but not. That way it's still two different classes but now with the "same name" just different amount of templates.

@SergioRAgostinho
Copy link
Member Author

I had another look at this and your approach definitely improved mine but the point regarding the documentation is still present.

  • Won't this also show up on the documentation? Maybe the workaround is to actually prevent this entry to be documented
  • New deprecated namespace?

With variadic templates we would have cleaner options 😞 http://cpp.sh/9ef2s

@taketwo
Copy link
Member

taketwo commented Nov 25, 2017 via email

@SergioRAgostinho
Copy link
Member Author

I adopted the strategy you devised. I added 2 (!) inner namespaces to pcl namespace: experimental, deprecated.

  • The idea behind experimental is to define be able to define classes or implementations which might or might not make it to next version. I'm copying what I see done in the standard library for experimental features. In our case it works really well, encapsulating what's going to be new EuclideanClusterComparator class signature.
  • The deprecated namespace was created just to encapsulate that dummy struct which works as a generic type. This way we don't add useless types to the common namespace.

Copy link
Member

@taketwo taketwo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like your solution 👍

One small thing. I'd propose better deprecation warnings, see comments.


/** \brief Empty constructor for EuclideanClusterComparator. */
PCL_DEPRECATED ("EuclideanClusterComparator will no longer be templated on a PointNormal type in future minor release")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Remove PointNT from template parameters."

distance_threshold_ = distance_threshold;
depth_dependent_ = depth_dependent;
}
PCL_DEPRECATED ("EuclideanClusterComparator no longer makes use of normals.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it never used normals in the first place. I think it can be useful to let the users know this. Otherwise the line of thinking when someone sees this message is: "Oh crap, what should I do now? I still need to compare normals. Is there another class now? Which one, how to find it?"

So perhaps a better deprecation message would be something along these lines: "EuclideadClusterComparator never actually used normals and angular threshold, this function has no effect on the behavior of the comparator. Therefore it is deprecated and will be removed in future releases."

Same for other functions.

@SergioRAgostinho
Copy link
Member Author

Will do. There's one thing which worries me though. I'm not seeing deprecation warnings popping up in the build and I'm quite sure I should seem them, because there's code using the three template parameter signature.

@taketwo
Copy link
Member

taketwo commented Nov 26, 2017

because there's code using the three template parameter signature.

Oh right, speaking of which... Since we already support the future two-parameter signature, there is no need to bring back normals to the library sources.

I'm not seeing deprecation warnings popping up in the build and I'm quite sure I should seem them

Hm, indeed. I went through your changes again and they implement the proof-of-concept exactly, don't see any difference.

@SergioRAgostinho
Copy link
Member Author

I'm looking into it. I left originally the three template signature exactly to confirm the verbose, with the intention to remove after.

@SergioRAgostinho
Copy link
Member Author

They're popping on my system for gcc but not for clang. Since the apps task is clang built we get no warnings.

@taketwo
Copy link
Member

taketwo commented Nov 26, 2017

On my machine clang3.8 reports warnings for my PoC.

@SergioRAgostinho
Copy link
Member Author

clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

@SergioRAgostinho
Copy link
Member Author

It was only introduced in http://releases.llvm.org/3.9.0/tools/clang/docs/AttributeReference.html#deprecated-gnu-deprecated so everything should be ok.

I'll proceed with the removing the template parameters from our code and it should be good to go.

@SergioRAgostinho
Copy link
Member Author

SergioRAgostinho commented Nov 26, 2017

Oh... so you say it should actually work in 3.8 as well... hmm...

@taketwo
Copy link
Member

taketwo commented Nov 26, 2017

Interesting. We have the same environment

$ clang++ --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

and I do get warnings

warning: 'A' is deprecated: Second template parameter is
      deprecated, remove it [-Wdeprecated-declarations]

@taketwo
Copy link
Member

taketwo commented Nov 26, 2017

Also, on Travis we have 3.9.0 which definitely has this attribute according to the link you posted.

@SergioRAgostinho
Copy link
Member Author

SergioRAgostinho commented Nov 26, 2017

Some interesting findings:

  1. Your PoC generates warnings on it's own.
  2. If in my cmake project I add find_package(PCL 1.8.1.99 REQUIRED) it no longer prints the warnings. Just to be clear, I'm just finding the package. I'm not even linking to the pcl to the target or anything.

We're messing up some flags for sure. The compiler flags in each case
1.

/usr/bin/clang++      -o CMakeFiles/deprecation.dir/deprecation.cpp.o -c <path_to>/pcl_test_cases/deprecation/deprecation.cpp
/usr/bin/clang++   -Dqh_QHpointer -I/usr/include/vtk-5.10  -Wno-deprecated   -o CMakeFiles/deprecation.dir/deprecation.cpp.o -c <path_to>/pcl_test_cases/deprecation/deprecation.cpp

That -Wno-deprecated looks suspicious

@taketwo
Copy link
Member

taketwo commented Nov 26, 2017

I guess with clang we fall under this branch:

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated")

Not sure how it gets propagated to a project using PCL.

@SergioRAgostinho
Copy link
Member Author

SergioRAgostinho commented Nov 26, 2017 via email

@SergioRAgostinho
Copy link
Member Author

It gets added when we request the visualization component in find package.

@SergioRAgostinho
Copy link
Member Author

The issue comes from here

include("${VTK_USE_FILE}")

Which is adding this vtk use file. This is provided from the vtk package and in my system this looks like this vtk-5.10

#
# This module is provided as VTK_USE_FILE by VTKConfig.cmake.  It can
# be INCLUDEd in a project to load the needed compiler and linker
# settings to use VTK.
#

IF(NOT VTK_USE_FILE_INCLUDED)
  SET(VTK_USE_FILE_INCLUDED 1)

  # Update CMAKE_MODULE_PATH so includes work.
  SET (CMAKE_MODULE_PATH
    ${CMAKE_MODULE_PATH}
    ${VTK_CMAKE_DIR})

  # Load the compiler settings used for VTK.
  IF(VTK_BUILD_SETTINGS_FILE AND NOT SKIP_VTK_BUILD_SETTINGS_FILE)
    INCLUDE(${CMAKE_ROOT}/Modules/CMakeImportBuildSettings.cmake)
    CMAKE_IMPORT_BUILD_SETTINGS(${VTK_BUILD_SETTINGS_FILE})
  ENDIF(VTK_BUILD_SETTINGS_FILE AND NOT SKIP_VTK_BUILD_SETTINGS_FILE)

  # Add compiler flags needed to use VTK.
  SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${VTK_REQUIRED_C_FLAGS}")
  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${VTK_REQUIRED_CXX_FLAGS}")
  SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${VTK_REQUIRED_EXE_LINKER_FLAGS}")
  SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${VTK_REQUIRED_SHARED_LINKER_FLAGS}")
  SET(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} ${VTK_REQUIRED_MODULE_LINKER_FLAGS}")

  # Add include directories needed to use VTK.
  INCLUDE_DIRECTORIES(${VTK_INCLUDE_DIRS})

  # Import the VTK_LOAD_CMAKE_EXTENSIONS macro.
  INCLUDE(vtkMakeInstantiator)

ENDIF(NOT VTK_USE_FILE_INCLUDED)

The contents of VTK_REQUIRED_CXX_FLAGS include the -Wno-deprecate

-- VTK_USE_FILE: /usr/lib/vtk-5.10/UseVTK.cmake
-- VTK_REQUIRED_CXX_FLAGS:  -Wno-deprecated
-- VTK_REQUIRED_C_FLAGS: 

@SergioRAgostinho
Copy link
Member Author

SergioRAgostinho commented Nov 26, 2017

What to do in this scenario? This is an upstream compilation option of whom packaged vtk5 for apt.

I was now experimenting with not using that VTKUse file but I'm not fully sure this is the way to address this.

@taketwo
Copy link
Member

taketwo commented Nov 26, 2017

I suspected VTK and even grepped for "no-deprecated" in /usr/lib/cmake/vtk-6.2 but it came back with nothing.

@taketwo
Copy link
Member

taketwo commented Nov 26, 2017

I would conjecture that VTK 6 and above do not set this flag. As for VTK 5... well, bad luck, what can we do.

@SergioRAgostinho
Copy link
Member Author

Yet to be explained is why it pops only on clang.

@SergioRAgostinho
Copy link
Member Author

Just pushed the final things. I can't perform any more reorganizing of commits easily due to the indentation changes.

@taketwo
Copy link
Member

taketwo commented Nov 27, 2017

Thanks!

@taketwo taketwo merged commit 47629c1 into PointCloudLibrary:master Nov 27, 2017
@SergioRAgostinho SergioRAgostinho deleted the ecc-deprecated branch November 30, 2017 19:18
@SergioRAgostinho SergioRAgostinho changed the title Provide proper EuclideanClusterComparator method depreciation Provide proper EuclideanClusterComparator method depreciation. New Pragma macro. New Deprecated type. Aug 25, 2018
@SergioRAgostinho SergioRAgostinho added the changelog: deprecation Meta-information for changelog generation label Sep 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog: ABI break Meta-information for changelog generation changelog: deprecation Meta-information for changelog generation module: common module: segmentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants