Ask Your Question
1

Exporting multiple libraries from the same package

asked 2012-11-21 05:17:01 -0600

I have a package (simple_message) that builds a library, that is then used by other packages. I would now like to build two versions of that library (one with some additional functionality). I am able to build the two versions using some compiler switches and defining them in the CMakeLists. To allow other packages to use the library I haved added the following to the manifest file:

<export> <cpp cflags="-I${prefix}/include -DROS=1" lflags="-Wl,-rpath,${prefix}/lib -L${prefix}/lib -lsimple_message"/> </export>

My problem is how do I add the second library. I could add it to the manifest as part of the export tags, but how will other packages specify which version of the library they want to use?

edit retag flag offensive close merge delete

Comments

How do you know which library instance you want to use?

joq gravatar imagejoq ( 2012-11-24 02:21:09 -0600 )edit

Why don't you create a Stack and put each library on a different package inside the same stack?

Martin Peris gravatar imageMartin Peris ( 2012-11-25 14:36:28 -0600 )edit

Martin, the different packages would need to build against a common source. The differences between the packages would be in a low level, common source file. Right now, I use compiler flags to alter the source file.

sedwards gravatar imagesedwards ( 2012-11-25 14:47:36 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted
2

answered 2012-11-25 13:42:22 -0600

updated 2012-11-26 04:26:53 -0600

Although the discussion of my original question has changed my approach, here is the answer to my question. Full disclaimer, I'm not an expert at CMake or even c/l flags, so there may be an even better answer.

The export line in the manifest should be changed to the following:

<export> <cpp cflags="-I${prefix}/include -DROS=1" lflags="-Wl,-rpath,${prefix}/lib -L${prefix}/lib" /> </export>

Any package that requires the library now must explicitly state which library it wants to use in CMakeLists.txt, ex:

rosbuild_add_executable(my_exe src/my_exe.cpp)

target_link_libraries(my_exe my_lib) OR target_link_libraries(my_exe my_lib_alternate)

This goes against the recommended approach here.

edit flag offensive delete link more

Comments

I think your solution here is not bad. It doesn't seem too dirty and is probably more robust than compiling and linking the source files in other packages as mentioned in your other question.

Lorenz gravatar imageLorenz ( 2012-11-25 20:55:15 -0600 )edit

I agree. There would be the option to make meta-packages that depend on yours and only export the -lmylib/-lmylib2 flags (empty otherwise). Then you could depend on those package names and users don't need to know the library names. The overhead is the meta/dummy package which isn't that nice.

dornhege gravatar imagedornhege ( 2012-11-25 22:24:58 -0600 )edit

I can't spot any difference in the target_link_libraries() alternatives. Is there supposed to be one?

joq gravatar imagejoq ( 2012-11-26 04:18:28 -0600 )edit

Jack(see dit). Lorenz, while this approach works, I have 3 potential compiler swtiches (one for byte order, size of ints, and size of floats) which could result in 8 versions of the library. I'm trying to address platform independence on the client side because the servers side isn't capable.

sedwards gravatar imagesedwards ( 2012-11-26 04:31:34 -0600 )edit
1

answered 2012-11-21 06:31:34 -0600

dornhege gravatar image

I think there is no mechanism for that. You will have to split that into two packages.

edit flag offensive delete link more

Comments

I don't think that is an option. I want to compile two libraries, one with byte swapping and one whitout. The functionality is the same, except at the lowest communications level. Everything is built from the same src/header, just with different compiler options.

sedwards gravatar imagesedwards ( 2012-11-21 10:43:45 -0600 )edit

As @dornhege correctly pointed out, there is no (clean non-hacky) way in ROS to achieve what you want. I would consider using two different versions of the same library in one environment problematic anyway.

Lorenz gravatar imageLorenz ( 2012-11-21 22:13:40 -0600 )edit

Wouldn't (or even shouldn't) something like different behaviour be handled at the API level by passing correct parameters? If only possible at the library level, I think it's still better to have two packages as this forces users to specify something different in the manifest.

dornhege gravatar imagedornhege ( 2012-11-21 22:30:43 -0600 )edit

I would normally agree that something like this should be handled at the API level, but my particular application is byte swapping to deal with different endianess. There is precedent for this being handled at the compiler level (see htons, http://linux.die.net/man/3/htons)

sedwards gravatar imagesedwards ( 2012-11-25 13:29:05 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2012-11-21 05:17:01 -0600

Seen: 423 times

Last updated: Nov 26 '12