Summary: | [PATCH] Libs.private in pkgconfig files | ||
---|---|---|---|
Product: | poppler | Reporter: | Sandro Mani <manisandro> |
Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
Status: | RESOLVED MOVED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Proposed patch
Proposed patch |
Description
Sandro Mani
2014-04-25 22:00:00 UTC
hardcoding stuff like iconv in there seems a bit weird can we use some kind of alias like you do in the other files? Created attachment 98391 [details]
Proposed patch
Looks like @LIBICONV@ does the job.
Any chance you can fix this on cmake? Increasing the delta between the two build systems for something as static linking of poppler is something i'm not very keen on doing. Hmm, seems the only way to do it with cmake is to hard code the -l<lib> in the pc file... I.e. Libs.private: @GLIB2_LIBRARIES@ @CAIRO_LIBRARIES@ @FREETYPE_LIBRARIES@ results in Libs.private: gio-2.0;gobject-2.0;glib-2.0 /usr/lib64/libcairo.so /usr/lib64/libfreetype.so which is obviously not what we want. Do you perhaps know some cmake black magic to get only the actual -l<lib> instead of the output above? No idea sorry :/ So the only other nice option I saw was to read what was passed to target_link_libraries, do some regex magic and use that in the pc files. However, looks like there is no way to read the target_link_libraries a posteriori.... So I suppose what one could do is introduce a variable containing what is passed to target_link_libraries and then filter that to use in the pc files. Along the lines of i.e.: set(POPPLER_GLIB_LIBRARIES ${GLIB2_LIBRARIES} ${CAIRO_LIBRARIES} ${FREETYPE_LIBRARIES} -lpthread) target_link_libraries(poppler-glib poppler ${POPPLER_GLIB_LIBRARIES}) string(REGEX REPLACE <stuff> <stuff> POPPLER_GLIB_LIBRARIES_CLEANED ${POPPLER_GLIB_LIBRARIES}) # In the .pc Libs.private=@POPPLER_GLIB_LIBRARIES_CLEANED@ Perhaps adding a comment above the target_link_libraries notifying the developer to add varabiles to POPPLER_XXX_LIBRARIES variable instead of directly to the target_link_libraries. Sounds like a plan? That setting all the libs to a variable is something we already kind of do, so i'm in favor of it, on the other hand that regexp stuff may be not even be doable. Give it a "quick" try. If you don't succeed come back and i'll think if we care about this at all or not, honestly static linking poppler is not something that i think makes sense at all. So I think something like "[\w/]+lib(\w+)\.so[.\w]*" -> "\1" "[\s;]+" -> " -l" could work. But yeah, the issue is not one which personally affects me, I only gave it a shot because of rhbz #1089380. So as far as I'm concerned we can very well just happily stop here and move on ;) -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/133. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.