Some libraries and executables could be placed in the wrong path during the build process #784
Comments
|
Very nice bug report @sgiraz, thanks! The old macro
We should therefore address the fix extensively. |
|
cc @marcoaccame |
|
Thanks to the suggestions provided by @traversaro and confirmations by @Nicogene the solution for the issue reported in here relies in the following 3 instructions applied on each libraries mentioned above by @pattacini: +set_target_properties(${PROJECT_NAME} PROPERTIES RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_BINDIR}")
+set_target_properties(${PROJECT_NAME} PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")
+set_target_properties(${PROJECT_NAME} PROPERTIES ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")Talking with @Nicogene, we think that unless these libraries are necessary for other repositories, we could leave the old macros. |
|
The solution proposed in #784 (comment) seems to be exactly the same as that reported in the OP with the difference that it acts at the level of the single libraries. My point was:
Can we answer these questions? |
From what I understand, the question is rather why all other libraries (e.g., |
|
Yep, investigating the reason for this difference was my original aim. Applying the patch lightheartedly will quickly fix this particular problem but will potentially hide some others. |
I had the same doubts, the libraries of the embobj part have a quite old cmake structure (~ 9/12 years) and I hope that here #652 I did not change something unintentionally. I probably forgot to test the case of using the build directory, that is probably the reason why @sgiraz spotted this problem only now.
I thought that was that the default one 🤔 If not, I don't know who is setting |
Actually no! You can try to compile https://github.com/robotology/how-to-export-cpp-library/ after commenting the three lines https://github.com/robotology/how-to-export-cpp-library/blob/afb21efb655e7b1cc11636c3d42aad9e02fb626f/CMakeLists.txt#L41 and checking where the libraries are placed. |
Bug description
SW Configuration:
yarp,icub-main,icub-firmware-sharedmentioned above are not merged yet in the official repository (you can find them in my forks).Description:
Trying to run the
yarprobotinterfacethe following error stops the execution:Thanks to @traversaro, using the Dependencies tool on
embObjMotionControld.dll, I spotted that among all its dependencies theethResourcesd.dllcannot be found (see the image below)After the building process the
ethResourcesd.dlllibrary should be inC:\dev\icub-main\build\bin\Debugfolder, but it was inC:\dev\icub-main\build\lib\Debugfolder.How to solve
In my case, the fix has been the introduction of the following variable inside the main CMakeLists.txt:
🔍 After a quick discussion with @pattacini, the problem seems to be inside the CMakeLists.txt of the
ethResourcesproject, which uses an old macro that should be updated with the new one (here is an example from iKin project).Steps to reproduce
yarpserveryarprobotinterfaceyarprobotinterface, it should be as the following:Click to expand
Expected behavior
When we run the
yarprobotinterfacethe output should be the following:Click to expand
Example repository
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: