<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>On Sat, 2018-12-29 at 16:06 -0500, frodak17 wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><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 type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;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 class="gmail_quote"><br></div></div></div></div></div></blockquote><div><br></div><div>Thank you for your reply,</div><div><br></div><div>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,</div><div>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</div><div>clever happens in the background which I am not aware of.</div><div><br></div><div>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</div><div>generate pc files either, so I don't really see any other way to get pkg-config working.</div><div><br></div><div>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.</div><div>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.</div><div>I would also go through the dependency libraries, but I doubt that any contributions of pc file generators to those projects would be accepted.</div><div><br></div><div>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.</div><div>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:</div><div><span class="pl-c1"><br></span></div><div><span class="pl-c1">set</span>(PKGCONF_LIBS_PRIV <span class="pl-s">"<span class="pl-smi">${PKGCONF_LIBS_PRIV}</span> -lbass -lbassmidi"</span>)</div><div><br></div><div>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 </div><div>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</div><div>field instead of the Requires field :)</div><div><br></div></body></html>