Hi, I often found pkg-config files to be even wrong. Many library authors do not seem to know the rules for transitive linking. Often, the differences between static and dynamic linking is not or wrongly expressed in .pc files. Cross compiling with pkg-config is also not being the most fun unless the library author thought about it or you fix the files yourself.
You don't have to care so much about ABI, different compilers and such. On most systems, these need different directories and thus separate .pc files. CMake also fails late at linking even pointing it to Qt 64bit libraries for a 32bit compiler even though they use config modules! At some point, it's the responsibility of the developer to organize his environment correctly. Regards, HS Am 26. Mai 2018 12:08:01 MESZ schrieb Lectem <lec...@gmail.com>: > >Hi, >I’ll start by saying that I love the fact we’re now talking about a >common representation of packages ! > >➢ The reason I say this is that extending pkg-config seems like it >would help adoption rather then creating a completely new format. There >is already a good portion of open source projects that already support >pkg-config, so tweaking them to support more complicated scenarios >seems easier than converting everything to a new format. > >I’m not very familiar with pkg-config (working more in the Windows >world) so excuse me if I’m wrong. > >From what I remember it is very basic and relies on compiler flags >being the same everywhere (ie gcc-like flags), and does not provide any >information about things such as ABI, C-runtime Library used (arguably >could be represented as a package ?). As far as I know, it assumes that >the libraries are always compiled with the same compiler on the same >system, hence has no knowledge of compatibility between compiler >versions. >As you mentionned, it currently relies on -l for both libraries and >linker flags, which would need to be changed. > >➢ so tweaking them to support more complicated scenarios seems easier >than converting everything to a new format. > >Wouldn’t that create more confusion ? I fear it’d end up as a python2 >python3 issue, where both versions look alike but are incompatible. > > >Have a nice Week-end, >Lectem
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
