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
