<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 28, 2018 at 6:04 PM Unknown <<a href="mailto:ax487@gmx.de">ax487@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would like to thank all of you for your suggestions. I have gathered<br>
the following (correct me if I am wrong):<br>
<br>
- The LINK_FLAGS target property is used in cmake 2.x, the<br>
INTERFACE_LINK_LIBRARIES in cmake 3.x, the latter contains a ;-list<br>
of libraries.<br>
- The list may contain generator expressions, it is however<br>
possible to to use file(GENERATE ..) to obtain evaluate those.<br>
- In any case, the library list contains libraries having different <br>
formats (see [1]), full paths, (imported) targets, and plain names.<br>
- When Makefiles (or files for other build systems) are generated,<br>
the list is turned into -L/-l flags used by ld. This happens<br>
on the C++ side of things, the functionality is not exposed<br>
to cmake scripts.<br>
<br>
As for automatic generation of a pkg-config .pc file, there have<br>
been some inquiries ([2], [3], and [4]), the last one being rather<br>
recent.<br>
<br>
The answers point out that pkg-config files can be generated using<br>
configure_file(...), that cmake has its own (imported target) method<br>
for handling dependencies.<br>
<br>
I don't mean to be disrespectful or unappreciative of the work put<br>
into cmake (in fact I think it is a vast improvement over automake),<br>
but since there is no way to obtain the required information<br>
programatically, all users of my library have to either use<br>
cmake themselves, or use non-portable workarounds which are prone<br>
to break sooner than later. <br>
<br>
If I want to use an external tool (think setup.py) to build<br>
extensions (in-place or not), the same problem occurs.<br>
<br>
This is rather disappointing to be honest...<br>
<br>
ax487<br>
<br>
<br></blockquote><div><br></div><div>The answer to [2] was that the information required to automatically generate
a .pc file was not available. <br></div><div><a href="https://linux.die.net/man/1/pkg-config">https://linux.die.net/man/1/pkg-config</a><br></div><div><a href="https://people.freedesktop.org/~dbn/pkg-config-guide.html#writing">https://people.freedesktop.org/~dbn/pkg-config-guide.html#writing</a> <br></div><div>I don't see how CMake could know which packages your library conflicts with or which versions of which libraries are required.</div><div>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.<br></div><div>
</div><div><br></div><div></div><div>
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.
</div><div>For example the .pc file you want generated contains "Libs: -L${libdirbar}
-L${libdirfoo}
-lbar -lfoo".</div><div>But that isn't the proper way of a .pc file should reference separate libraries it should use the Requires field.<br></div><div><br></div><div></div><div>Also if your library is linking against an imported library `libbaz::libbaz` how is this library being provided to the people using your library?</div><div>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?</div><div><br></div><div>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.<br></div><div><a href="https://cmake.org/pipermail/cmake/2018-March/067293.html">https://cmake.org/pipermail/cmake/2018-March/067293.html</a></div><br></div><div class="gmail_quote"><br></div></div></div></div></div>