catkinConfig.cmake should strip out 'debug' and 'optimized' attributes from catkin_LIBRARIES

[vpradeep07]

I'm have a catkin package A which adds debug;bar.so;optimized;bar.so to the cmake variable ${A_LIBRARIES}, and thus also adds to ${catkin_LIBRARIES}:

I also have package B that has a build depends on A. When BConfig.cmake is generated, the debug and optimized attributes are stipped out of ${B_LIBRARIES}. This is done is catkin/cmake/catkin_package.cmake:249-264.

Suppose I add a catkin package C which depends on A and B, in that order. In catkinConfig.cmake, A_LIBRARIES will be added to catkin_LIBRARIES with list_append_deduplicate at line 84, and then B_LIBRARIES will be added to catkin_LIBRARIES with list_append_deduplicate. How the dedeuplicate call will strip out bar.so , leaving the words debug and optimized in catkin_LIBRARIES.

Thus, we get:
catkin_LIBRARIES=debug;optimized;bar.so

I'm assuming that the solution is for catkinConfig.cmake to do something similar to the debug/optimize stripping that's done in catkin_package.cmake.

This is seen on catkin version 0.5.77

[wjwwood]

@vpradeep07 Thanks for the detailed report, can you see if this commit resolves your problem?

e480140

I ran into a related problem recently and I think @dirk-thomas fixed the issue you describe here with that commit as well.

Related:

#558
#562

[dirk-thomas]

@vpradeep07 Can you please verify that it works for you when checking out catkin from source into your workspace?

[vpradeep07]

Hey guys, thanks for looking into this issue.
@dirk-thomas All of the tests that I've been running have been using catkin from source.
@wjwwood As requested, I switched to using catkin e480140, and this does not seem to fix the issue.

As mentioned in the original post, catkin_package.cmake,L249-269 is doing special filtering based on the presence of the debug and optimized flags. The new changes in e480140 remove duplicates libraries, but will remove all the debug flags except one, which is not the intended behavior. Instead, similar debug and optimize filtering from catkin_package.cmake should be added to catkinConfig.cmake.in, before they are added to catkin_LIBRARIES.

As an alternative, all debug and optimized filtering could be removed from everywhere in catkin, and catkin could state that it does not support these types of flags. There really isn't much gain from half supporting them as it does in it's current state.

[dirk-thomas]

Conceptionally catkin should currently do the following:

When ever you build a catkin package it generates a CMake config file as well as a pkg-config file for that package and these only contain the libraries (listed in the package or in any of the dependencies) which equates to the used CMAKE_BUILD_TYPE. The generated files should never include the debug / optimized flags since they are supposed to be filtered out in catkin_package().

On the other hand the catkin CMake config file only finds all catkin dependencies as components and concatenates their name_LIBRARIES variables (while avoiding duplication). Since those variables never contain debug / optimized flags they don't need to be handled explicitly in the catkinConfig.cmake file.

Can you please post a link to your example packages A, B and C and a short description what commands you execute and what the actual and expected result is? May be that will help to understand what exactly fails for you / where catkin does not handle those library types correctly.

[vpradeep07]

When ever you build a catkin package it generates a CMake config file as well as a pkg-config file for that package and these only contain the libraries (listed in the package or in any of the dependencies) which equates to the used CMAKE_BUILD_TYPE. The generated files should never include the debug / optimized flags since they are supposed to be filtered out in catkin_package().

I totally agree. I observe this to be true as well

On the other hand the catkin CMake config file only finds all catkin dependencies as components and concatenates their name_LIBRARIES variables (while avoiding duplication). Since those variables never contain debug / optimized flags they don't need to be handled explicitly in the catkinConfig.cmake file.

It looks like this is where the misunderstanding is. For my package foo, we are including a cmake extras file with something like the following:

cs_export( CFG_EXTRAS foo-extras.cmake  )

foo-extras.cmake is then manually appending to foo_LIBRARIES, and when doing so, also including debug/optimized flags.

@dirk-thomas From what you've mentioned in the previous post, it sounds like what we are doing is an invalid usage of catkin, since catkin expects foo_LIBRARIES to never have debug/optimized flags in it. And, moving forward, we should update foo-extras.cmake to do the debug/optimized filtering itself.

As a minor enhancement, it might be nice for catkin to throw a warning or error if it encounters debug or optimized flags in name_LIBRARIES.

Can you please post a link to your example packages A, B and C

Unfortunately, I don't have a minimal example on hand at the moment. I believe we've just addressed the crux of the issue, but if an example will still be useful, I can put one together.

Thank you for your help.

[dirk-thomas]

Yes, extending the libraries variable in your CMake extra file is not (yet) supported by catkin. I thought about how the current handling of libraries could be changed to support your use case. The following should fit the described example and be more robust in general:

First the catkinConfig.cmake should take the libraries variable of each component and merge them into the catkin_LIBRARIES variable - even when they contain build configuration keywords. This can be done by:

• process each components library variable by merging the keyword and the folllowing library name into a single list item
• then appending all items to the catkin_LIBRARIES variable using list_append_deduplicate()
• undo the merging operation on the final catkin_LIBRARIES variable

Some libraries might appear with and without a build configuration keyword (which would technically be a duplicate but is not addressed here).

Second the catkin_package() function will perform the same sequence to deduplicate passed in libraries (merge keywords, append with deduplication, undo keyword merge). It will then write the list of libaries (potentially including build configuration keywords) to the generated CMake config file of the package. When generating the .pc files it must filter out the build configuration keywords since they do not support that CMake specific concept.

@vpradeep07 I created a pull request (#572) with these changes. It would be great if you could run your previous use case with that branch (libraries_with_build_configuration_keywords) of catkin to see if it is now handled correctly (without needing to work around in your extra file but just adding libraries including build configuration keywords as you did it before) and comment with your feedback here.

[vpradeep07]

@dirk-thomas I checked out #575 - 8ec3803, and it fixes the issue in our codebase as well

Thanks for looking into this issue!

[dirk-thomas]

Great, thank you for trying and confirming it.