Apologies I'm not aware of the background for this PR (#18) - on xenial, libpoco-dev does not pull in PCRE or zlib.

As someone who builds ROS2 from source in CI on xenial and bionic, and depends on catkin_pkg/rosdep to resolve dependencies, I wonder: is there any harm in keeping those build_depends in poco_vendor, given that xenial is nominally a supported platform?

Based on the bug report ros2/demos#177

poco_vendor should be updated to add logic to check if the version detected on the system is recent enough, if not it should go through the code path that clones and builds poco from source

connects to ros2/demos#177

I have been checking how we include poco in the package.xml across the official ros2 packages.

In same of them:

• poco_vendor and rmw_implementation

 <depend>libpoco-dev</depend>
 <depend>poco_vendor</depend>

• class_loader, rosidl_typesupport_c and rosidl_typesupport_cpp

  <build_depend>libpoco-dev</build_depend>
  <exec_depend>libpoco-dev</exec_depend>

I think libpoco-dev shouldn't be a <exec_depend> or <depend> because it's just something that we use for building.

the right approach should be something like:

  <build_depend>libpoco-dev</build_depend>
  <exec_depend>poco_vendor</exec_depend>

@wjwwood and @dirk-thomas which are your thoughts?

The "fat" binary archive generated for a release is build in release mode. When a user tries to build code on top in debug mode this package doesn't pick the built version of Poco but tries to find a debug version of the library on the system which might not be available.

Follow up of ros2/examples#199. @athackst FYI.

I had some issues on mini2 yesterday where the download for https://github.com/pocoproject/poco/archive/poco-1.7.7-release.tar.gz was really really slow. It hit the 600s timeout repeatedly before giving up and failing. At the same time the download completed instantly from my computer, so I suspect this is another case of a build machine getting throttled for downloading something too much.

One option is to include the archive in this repo, however that is still downloading it from github. Another option is to set up a mirror and have this repo try to download from it if the github link fails.

Here's an example
http://ci.ros2.org/job/ci_osx/2596/consoleText

The visible error was a failure in a downstream package to find Poco during CMake configuration. I checked for poco libraries in the poco_vendor install space and found only the poco_vendor resource files. When checking poco_vendor in the build space I did see an apparently successful build of poco in the poco_external_project_install directory.

Both @wjwwood and I experienced this at least once while testing from-source builds on Windows.

I don't have reliable reproduction steps since I only saw this the one time and as far as I know so did @wjwwood

I deleted the poco_vendor directory from the install and build directories and resumed building my workspace and the subsequent poco_vendor build successfully built and installed poco.

Need to pass CFLAG -fPIC when building for QNX. this issue can be solved in two ways:

option 1:
replace:

option 2:
edit the CMakeLists.txt file and include this line before ExternalProject_Add()
if(QNX)
list(APPEND extra_cmake_args "-DCMAKE_C_FLAGS=${CMAKE_C_FLAGS} -fPIC")
endif()

Please let me know which one you prefer so I can make a PR with, Thanks.