← All tasks
cppprojectM-visualizer/projectm #702Not a task: not reproduced

Generated .pc file for static build not usable

envgap__projectM-visualizer__projectm-702

01 / FAILURE SIGNATURE

As reported upstream

No identifying execution failure has been captured.
Not a benchmark task.
  • In a clean container the reported failure did not reproduce, or the known fix did not make the project run.

02 / ENVIRONMENT RECIPE

Base commit
1e0f8c6b10fd176a918d9d01644c7713d0a0e1b6
Manifest
CMakeLists.txt
Reproduce
Awaiting issue-specific recipe
Run under trace
Awaiting a meaningful runtime command

03 / ORIGINAL ISSUE TEXT

projectM-visualizer/projectm #702 · read the original issue
**Describe the bugs:**



- **Static library name and `Libs:` section for static build**



  When building shared, the library file is called `libprojectM-4.so`, while building static, the library file is called `libprojectM.a`, instead of `libprojectM-4.a`. This seems to be caused by [this line](https://github.com/projectM-visualizer/projectm/blob/2d370d323559ed79d139aa9f57053142d077de8d/src/libprojectM/CMakeLists.txt#L158). Maybe this is intended, I'm not sure.



  However, that same CMake code also causes the `Libs:` section of the generated .pc files to contain the literal unexpanded CMake generator expression when building statically:

  ```

  -l:$\<IF:$\<PLATFORM_ID:Windows\>,libprojectM,projectM\> -lOpenGL

  ```

  ... while it should contain `-l:projectM -lOpenGL` or similar. This does not happen when building shared and obviously breaks the .pc file. Removing the `set_target_properties` call fixes the problem, but I'm not sure that's desirable as it seems to be introduced recently.



  The playlist library .pc file also suffers from this problem, caused by [similar code](https://github.com/projectM-visualizer/projectm/blob/2d370d323559ed79d139aa9f57053142d077de8d/src/playlist/CMakeLists.txt#L78).



- **`Cflags:` section in .pc file when building static**



  Since bff9e52c6992b82fbd31bf83409af2360f8b5225, the `PROJECTM_STATIC_DEFINE` define was moved from a `target_compile_definitions` call to multiple `set_source_files_properties` calls. This has the side effect that `-DPROJECTM_STATIC_DEFINE` no longer ends up in the `Cflags:` section of the main projectM .pc file when building static.



  Conversely, the .pc file for the playlist library does contain `-DPROJECTM_STATIC_DEFINE`, precisely because it uses `target_compile_definitions` [here](https://github.com/projectM-visualizer/projectm/blob/2d370d323559ed79d139aa9f57053142d077de8d/src/playlist/CMakeLists.txt#L72).



  Side note: To me, it looks like the playlist library already links against the main projectM library ([here](https://github.com/projectM-visualizer/projectm/blob/2d370d323559ed79d139aa9f57053142d077de8d/src/playlist/CMakeLists.txt#L56)), so [this line](https://github.com/projectM-visualizer/projectm/blob/2d370d323559ed79d139aa9f57053142d077de8d/src/playlist/CMakeLists.txt#L72) looks unneeded: If the main library correctly specifies the static define as part of it's public interface (which it currently doesn't as explained above) _and_ the playlist library publicly links to the main projectM library (which AFAICT it does), surely the playlist library will inherit and use that flag itself without having to specify it twice.



Finally, maybe a nitpick, but it looks like no .pc files are getting installed when no `CMAKE_BUILD_TYPE` is specified. Maybe it would be a good idea to default to either one of the four configurations (Debug, RelWithDebInfo, etc) when none is specified?



**Desktop:**

 - OS: linux

 - Version: 2d370d323559ed79d139aa9f57053142d077de8d
Continue on GitHub ↗

04 / LABELS

Labels from the report text only; not yet run

No supported category has been assigned.

Label rules and the text that matched
[]