I have a library that I have developed and this library has some dependencies on other libraries. To be able to use this library in other projects, I need to provide a config.cmake. My question is, what do I need to put in my config.camke. Normally this config.cmake files have an INCLUDE_DIRS, LIBRARIES and EXECUTABLE variables as well as FOUND (and each one is properly set with the library, executables, and paths). However, I see that if I only give this when I try to compile the project depending on my library I get linking errors saying that the executable is missing the library that my library depends on. Is there a way that I can avoid this by doing a better config.cmake?
Thank you very much.
Related
I have two separate git repositories that I am not sure how to best bring together using cmake. I would like a solution that is cross platform.
I have a C++ library project which produces a static library (and C++ headers). This project has its own cmake which will produce a static library. I haven't yet written an install step in the cmake.
I have a UI (Qt) project which visualizes the product of this library. This also is based on cmake and should be using the library; in fact, it does not make sense without the library.
What is the best practice for a situation such as this? I could imagine a few things:
The library is a git submodule of the UI project and the cmake of the UI uses add_subdirectory()
The UI build expects the user to have built and installed (to the system) the static library & headers
The UI build has a hard coded path (or ENV var) to the cmake of the library (or something like LibraryConfig.cmake, but I'm not familiar enough with this yet)
My end goal is that the user should be able to pull, build, and use the library in their own projects, but if in the future they feel necessary, they can grab the visualization tool additionally and use it with the library. Also, people who are not comfortable with using the library themselves might just want to clone the visualization tool repo and build & use it.
It's said that library authors should ship their library with a config-file instead of a plain find-module.
Basically config-file are to be installed with the associated library on the system and can be used transparently by the user, whereas find-module is written by the user by his own when he finds out that the library hasn't any config-file.
But, what if I'm sure that my library will never be installed?
I'm doing embedded system development and it doesn't make much sense to install my static libraries on the system.
Different modules are organized as static libraries and handled by each project with git submodules.
Is there any way I can use config-files even in this scenario? Or, as library author, I should write a example of vanilla Find-module and say to client code "Take and copy this to your CMAKE_MODULE_PATH"?
Or maybe just tell the client code cmake to call add_subdirectory?
I am trying to figure out if there is a way to ignore a static library at compile time if the project already exists with similar library?
I am creating a framework in which I require to have the static library to utilize the scanning mechanism. However, the project I am trying to utilize this project also have such library, hence I am curious if there is any mechanism to ignore such library at compile time? Doesn't matter either from the framework or project.
Thanks.
I once had a similar case, where a library I wrote required some common open source components, which were used by many developers.
The best solution we found was to not link those components into our library, provide a list of these components, and to require the user of our library to include those components.
I have compiled shared libraries dynamically linked against libstdc++.so using GLIBCXX_3.4.11. I want to send my code to someone whose stdc++ library is only of version 3.4.10. Rather than ask him to update his library version (this is a software customer, so I can't assume they'll be willing or able to change system files) I would like to ship the appropriate version of libstdc++.so, placed in a lib folder with the directory location of my code. How do I get my own code to use the appropriate (later) version? I find that /etc/ld.so.conf includes the directory /lib64, where an offending older version of libstdc++.so resides. Setting LD_LIBRARY_PATH does not override this. This seems to deviate from the advertised behavior. Any idea why this is happening? How do I complete my rather simple task?
Thanks.
I understand that this question is old, but I found it while trying to sort out my own linking trouble which was similar. You will have to build your program against a version of libstdc++ which is compatible with your colleague's version of the library. The easiest solution, of course, is to link against his version of the library so he doesn't need to make special tweaks on his side to link your library.
To do this, you will want to install a version of GCC which can build binary compatible libraries so you can actually link against his version of libstdc++. GLIBCXX_3.4.11 is from gcc-4.4 and later, so you will need gcc-4.3. Build your program using this and you should be in good shape.
You can consult the following page for a list of library ABI compatabilities:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
You could also build an rpm/deb which requires the version of libstdc++ you already have and if it's not available, refuse to install. This gives you a bit of an interface which gives him a promise that if his system is setup with the correct dependencies, he can use your library. In that sense, it's like a loose SLA for your library in what you do and don't support.
Hope that helps!
How can I know, whether an external library can be compiled to work on a different platform? the library for instance is tesseract-ocr
And if it possible, how do I do this?? (Basically I would like to create a Qt application that uses this library)
To find out, try building the library yourself. At the moment your question is quite broad. Post new questions when you have something more specific to ask.
If building the library fails, it is most probably due to some unsupported dependencies that you need to port first yourself.
Porting to Maemo is probably straightforward as it is a Debian-based environment and supports all the build tools such as autotools.
Symbian doesn't have autotools. Perhaps the fastest way to get started there is to first configure and build the library on e.g. cygwin and then generate the required bld.inf and .mmp files to build it on Symbian.
You can link your Qt application to regular C/C++ libraries. Just include the necessary header files in your code and link to the library using LIBS += -lfoo in your .pro file.