Removing catkin as a required dependency

[pletnes]

We're currently using serial as a C++ library in a project that doesn't use python or catkin. We've been able to build the library by removing some of the catkin related stuff in CMakeLists.txt. Would you consider a pull request where catkin is an option? e.g.

option(SERIAL_USE_CATKIN "Enable CATKIN packaging and so on" ON)

This would let us track your source more easily and hopefully make the library easier to build (apt-get instal catkin drags in 37 extra packages for me).

[wjwwood]

There's history on this topic: #123 #133

Short answer is yes, but only when I get time to review, iterate, and release. In the mean time there is lots you can do using branches or custom cmake code to build this project.

[Contez]

For what is worth I'd voting for making catkin optional too (as it seems, as pointed out previously, reasonably easy).
We adopted serial in place of another serial library (libserial) for a multiplatform data collection project we developed at my company, however the platform we compile it on are multiple, from fully fledged linux machines on x86 to very limited embedded devices with ARM and custom slimmed down Linux images.
Even crosscompiling with python sometimes becomes quite needlessy complex.

Let us know if we can be of help.

Regards, Riccardo

[rxdu]

I also vote for making catkin/python optional. I believe quite some people find this project when they're looking for a "C++ serial library", not a serial library that can be easily integrated with ROS or catkin build system. This project can be very useful even outside the robotics community for people who don't use ROS/catkin at all. If it involves too much work to make this dependency optional, I would rather see a project that has no catkin support at all, only C++ and CMake. In my opinion, the support/dependency on catkin makes your project less appealing than it should be.

Anyway, thank you for making such a useful library.

[riban-bw]

catkin is not directly available to Cygwin hence adds significant overhead to projects that need to be built under Cygwin. I recommend removing catkin as a build dependency. It is currently a factor for whether i adopt this serial library or another (hopefully easier to build) library. Cheers.

[DeveloperPaul123]

Has there been any progress on making catkin optional? The use of catkin/python is a barrier to using this library for us, but it seems to be more self contained than something like boost asio.

[lp35]

Same here, please set catkin as optionnal dep!

Cheers

[xloem]

It would be great if people would share any work they have done in getting this to build without catkin.
I'm thinking there are incremental changes that wjwwood would accept, that would reduce the dependence on catkin slowly.
It would also be great if there were information on where to find, build, and install catkin. I see there is a catkin as part of ROS, which is a huge multipackage system ...

[mfrigerio17]

Why going to great lengths to write a nice, cross platform serial library, and then impose a dependency on catkin?? Why??
Installing ROS dependencies in the makefile?!?!?

There's history on this topic: #123 #133

... as expected, no?

Please, please, remove all the unnecessary stuff and let many more people use your nice library without having to mod it themselves.
Support/Integration into a specific framework (e.g. ROS/Catkin) must be optional and implemented with composition, not by injecting hard dependencies inside the library

Sorry for the rumbling, I have seen this anti-pattern too many times

[xloem]

Please, if you have done any work to migrate off catkin, share it here so others can use the work as a base. There are existing PRs for this and wjwwood has stated what is needed next, if anybody is available to further look into it.

[xloem]

Whoops! Hey, wjwwood stated in 2018 that they plan to move off catkin. The linked issues are pull requests (there have been 3, and one is open) for building the project without catkin. It sounds like there might be only some small changes needed to the approach for it work. From #133 :

As I mentioned in the other two pull requests about this issue, my plan is to use CMake only (much as this pr does) going forward, but I want to leave the current version with catkin. I do not, however, want to just take this pr as-is, because I want to keep the package.xml and use exported targets.

However, I will try to use the commits from this pr if I can to give you some attribution for working on this.