On Sat, 2018-12-29 at 16:06 -0500, frodak17 wrote:
> On Fri, Dec 28, 2018 at 6:04 PM Unknown <ax...@gmx.de> wrote:
> > I would like to thank all of you for your suggestions. I have
> > gathered
> >
> > the following (correct me if I am wrong):
> >
> >
> >
> > - The LINK_FLAGS target property is used in cmake 2.x, the
> >
> > INTERFACE_LINK_LIBRARIES in cmake 3.x, the latter contains a ;-
> > list
> >
> > of libraries.
> >
> > - The list may contain generator expressions, it is however
> >
> > possible to to use file(GENERATE ..) to obtain evaluate those.
> >
> > - In any case, the library list contains libraries having
> > different
> >
> > formats (see [1]), full paths, (imported) targets, and plain
> > names.
> >
> > - When Makefiles (or files for other build systems) are generated,
> >
> > the list is turned into -L/-l flags used by ld. This happens
> >
> > on the C++ side of things, the functionality is not exposed
> >
> > to cmake scripts.
> >
> >
> >
> > As for automatic generation of a pkg-config .pc file, there have
> >
> > been some inquiries ([2], [3], and [4]), the last one being rather
> >
> > recent.
> >
> >
> >
> > The answers point out that pkg-config files can be generated using
> >
> > configure_file(...), that cmake has its own (imported target)
> > method
> >
> > for handling dependencies.
> >
> >
> >
> > I don't mean to be disrespectful or unappreciative of the work put
> >
> > into cmake (in fact I think it is a vast improvement over
> > automake),
> >
> > but since there is no way to obtain the required information
> >
> > programatically, all users of my library have to either use
> >
> > cmake themselves, or use non-portable workarounds which are prone
> >
> > to break sooner than later.
> >
> >
> >
> > If I want to use an external tool (think setup.py) to build
> >
> > extensions (in-place or not), the same problem occurs.
> >
> >
> >
> > This is rather disappointing to be honest...
> >
> >
> >
> > ax487
> >
> >
> >
> >
>
> The answer to [2] was that the information required to automatically
> generate
> a .pc file was not available.
> https://linux.die.net/man/1/pkg-config
> https://people.freedesktop.org/~dbn/pkg-config-guide.html#writing
> I don't see how CMake could know which packages your library
> conflicts with or which versions of which libraries are required.For
> example a library target can link against an imported target but it
> won't know that only imported target version 1.0.0 is compatible as
> opposed to versions >= 1.5.
>
>
>
>
> It seems that you are trying to provide more than how to link
> against
> your library but also against everything your library wants to be
> linked
> against.
>
> For example the .pc file you want generated contains "Libs:
> -L${libdirbar}
> -L${libdirfoo}
>
> -lbar -lfoo".But that isn't the proper way of a .pc file should
> reference separate libraries it should use the Requires field.
>
> Also if your library is linking against an imported library
> `libbaz::libbaz` how is this library being provided to the people
> using your library?Are you trying to generate a .pc file for the
> imported library because it didn't provide one and incorporate the
> flags into library you are creating?
> I think that no one has volunteered to write a CMake package to
> create .pc files is because generating a .pc file is pretty simple.
> It's just a template and a configure_file() command.
> https://cmake.org/pipermail/cmake/2018-March/067293.html
>
>
Thank you for your reply,
As for the answer provided in [2]: I don't expect conflict or version
detection to be conducted automatically. Clearly, you have to require
the correct packages in the correct versions,
and you have to pass that information along to a generated pc file,
that much is clear. But I think that the same holds true for imported
targets, unless something really
clever happens in the background which I am not aware of.
You are quite right in assuming that I want to (mis-)use the Libs /
Libs.private field. I would of course prefer the Requires field, but
unfortunately a lot of my dependencies don't
generate pc files either, so I don't really see any other way to get
pkg-config working.
A dependency of the form libbaz::libbaz would be provided as an
imported target. That is, the authors of libbaz are using cmake as
well, and they are installing a target.
I am assuming that the users of my library have the dependency libbaz
installed as well. I simply want to pass that information along in a
format understood by pkg-config.
I would also go through the dependency libraries, but I doubt that any
contributions of pc file generators to those projects would be
accepted.
Regarding the fact that no one has written a generator for .pc files:
It is obviously possible to use configure_file templates. In fact it is
quite easy. But it hinges on the libraries as well.
The post you mention references a project which generates linker flags
by hand. You see that the CMakeLists.txt contains a lot of lines like
this one:
set(PKGCONF_LIBS_PRIV "${PKGCONF_LIBS_PRIV} -lbass -lbassmidi")
This works as long as all dependencies are in a precisely known format,
i.e. a list of -l flags. In fact, I think the approach would still work
if the authors were to use the built-in pkg-config
find scripts for their dependencies. But this approach will break down
immediately once they add an imported target as a dependency. Note that
the authors also use the Libs.private
field instead of the Requires field :)
--
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
