<div dir="ltr">Hi David,<br><div class="gmail_extra"><br><div class="gmail_quote">On 23 April 2016 at 09:56, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Shaheed !!!<br>
Long time no see ;)<br></blockquote><div><br></div><div>Indeed, I think it is about 10 years since I last did anything here!<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">
On Wednesday 20 April 2016 19:48:30 Shaheed Haque wrote:<br>
> The whole point of what I am doing is to automate as much as possible<br>
> of steps 1-4, and this question centres on step 4. How can I automate<br>
> identifying the correct KF5 library .so file? For example, on my<br>
> Ubuntu Wily system, I can start with the header files in<br>
> "/usr/include/KF5/KItemModels/*.h" and then I need to link against<br>
> "libKF5ItemModels.so".<br>
<br>
</span>Well, we tried to keep things rather consistent, so maybe just a few rules are necessary.<br>
<br>
Just keep in mind that a single framework can install multiple libs (e.g. kio installs 5 of them).<br></blockquote><div><br></div><div>Ack.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(and that there are two kinds of forwarding headers (namespaced and non-namespaced),<br>
but if you only parse the real lowercase headers and not the forwarding headers then<br>
this doesn't matter)<br></blockquote><div><br></div><div>Ack this too. The way I deal with this is as follows. I parse *all* real and forwarding headers (except the KDELIBS4 support) to generate the "individual" SIP files. I detect the forwarding headers by looking for headers that have no "real" content and exactly one direct #include. So, at this phase, there is a pretty good 1:1 mapping between the .h organisation and the .SIP organisation.<br><br></div><div>Then, for each set of "individual" .SIP files in a directory (lowercase or forwarding), I generate a "module SIP". This %Includes the "individual" SIP files into a %Module, which translates the directory-based namespace on the .h side into a Python package (and mirrors what PyQt does). All that is automatic, driven purely off the directory hierarchy.<br><br></div><div>I then have a hand-selected list of only the new-style SIP files to generate actual bindings for. The reduces the circa 2000 "individual" SIP files to circa 120 .so files which are the new, namespaced, bindings. These are to be used in the form "from PyKF5 import KDBusAddons". That seems a natural and idiomatic model.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But with that in mind, it should be straightforward.<br>
E.g. include/KF5/KIOWidgets/* maps to libKF5KIOWidgets.so<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>OK. The question is really whether this naming is portable or not, across distros and platforms. The factors weighing in my mind are:<br><br></div><div>1. I don't want to hardcode the names of paths and technology choices (.so versus .dll) into the rules database; if it is in a file, it has to be done in a platform independent manner. (Or worse, I need a file per platform).<br><br></div><div>2. The tooling needs to support projects other than KF5, but I want KF5 to be easy to do as a starting point :-).<br></div><div><br>I think the net result is that the set of files/globs/regexps/rules/whatever has to be specified on the command line, and thus has to be compact. Taking this into account for the ~120 .so files involved in KF5 (which is likely the worst case), I am presently considering two options:<br><br></div><div>- Either ask the user to specify the file prefixes using a set of globs (e.g. ""/usr/local/lib/libKF5*,/usr/lib/libKF5*" for KF5, "/usr/liblibgrantelee*" for something else). I'm hoping that CMake could help, but in the worst case, it is trivial to specify this amount of data by hand on a platform basis if needed.<br></div><div><br></div><div>- Or hand code for the 120 cases, the set of files needed. This is a pain, but it could be done using just the base name (i.e. without the lib prefix and so suffix) as most tool chains seem to be able to handle converting "foo" into "libfoo.so" or "foo.dll", but it is not clear how that could work if some other platform decided to call the libraries "/usr/lib/KF5/libkdbusaddons.so".<br><br></div><div>Now, from some experiments, it seems that - as you would expect - the globs approach introduces no overhead in the generated output (though the linking might take a bit longer), so for now, that is the approach I am contemplating.<br></div><div><br></div><div>I hope that all sounds plausible. Have I missed anything?<br></div><div><br></div><div>Thanks, Shaheed<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" rel="noreferrer" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
</font></span></blockquote></div><br></div></div>