> On May 26, 2018, at 5:08 AM, Lectem <lec...@gmail.com > <mailto:lec...@gmail.com>> wrote: > > > 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),
The flags are only written gcc-like for include paths, defines, library paths. Pkg-config(and cmake) converts these flags to the native versions. Outside of these flags they are tied to the compiler, which is the same for cmake as well. > and does not provide any information about things such as ABI, C-runtime > Library used (arguably could be represented as a package ?). Yes, this can be another package that can be added to the `Requires` field. > 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. These changes are all backwards-compatible(that is the current pkg-config files will continue to work). Having standard packages to represent different ABI or requirements can be supported with the current pkg-config. And, pkg-config already supports a `Provides` field(ie `Replaces` field). Allowing a file instead of -l flag is a minor change. Pkg-config file format has not been static and has changed and evolved over the years(like adding the private fields or dollar sign escaping). Paul
-- 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
