<div dir="ltr">Hi,<div><br></div><div>have to chime in here</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 12, 2016 at 12:44 PM, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday April 12 2016 11:41:01 Kevin Funk wrote:</span><span class=""><br>
>build<br>
>- We'd gain a lot by finally providing a DMG users can install via one click.<br>
><br>
>Guess where my focus lies.<br>
<br>
</span>Yeah, and now consider this (drifting away from the underlying topic again!). How many people do you think will consider using KDevelop if it's not for some kind of better convenience developing KDE and/or Qt applications ... knowing that pure Qt development is already handled quite well by Qt Creator (which also provides the only alternative LLDB GUI)?<br></blockquote><div><br></div><div>I've been using KDevelop for plain Qt development in the past and I'd possibly go back to it (from QtCreator) if it was easier to install across the platforms I work on. I just can't afford to use two different IDE's depending on the platform. Back then KDevelop still have features that QtC did not and still does not, along with the fact that I like the way the UI works better. So yes, I expect people to choose something other than QtC even for pure Qt-based development, just as people right now are using other IDE's to do pure Qt-based development (this ranges from vim with loads of plugins to people using Eclipse or Jetbrains based IDE's to people using only VS or XCode).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd expect that a big part of the KDevelop audience would be people who are looking for an IDE that's better suited for building and adapting cross-platform software than Xcode is, and who use that software in their actual work. I.e. the kind of user I used to be, who came (back) to the Mac because it offered the best compromise between a Unix workstation and a desktop PC (Apple used to have a very strong presence in academia and HPC before they started targeting "hobos"). Users for whom it's most important that their tools "just work", and if possible the same way across all the different platforms they're likely to use.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
It's one thing to provide a standalone app bundle on a DMG for a text editor like Kate, a photo editor like Krita or even a multi-purpose viewer like Okular.<br>
An IDE is a bit different, isn't it? Are you planning to provide the whole KF5 SDK on that DMG, possibly even inside the KDevelop app bundle, XCode style?<br></blockquote><div><br></div><div>I hope thats the goal of Kevin's efforts/plans, anything else makes no sense to me since it couples the tool you work with to what you're working on. So if you break something in the shared dependencies you also break the tool that allows you to fix things again. Thats a bad idea.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If not I wouldn't be surprised if people who want/need to use KF5 frameworks turn first to one of the big three "distributions" to get up and running -- they'd more than likely do so anyway for the dependencies. Would you yourself not use as much as possible from that same source?<br>
(FYI: for all I know Qt's official distribution packages are still built using MacPorts as a source of dependencies)<br></blockquote><div><br></div><div>Yes, they have some things on their build machines from macports to generate packages. But the resuling packages do not require anybody to install that stuff. They package it (if it is a runtime dependency at all), besides the fact that this will possibly duplicate some stuff.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> convincing anyone. I may pursue it myself and if that leads to something<br>
>> potentially useful I'll contribute.<br>
><br>
>Thanks, that's a good start.<br>
<br>
</span>It *would* help if I had some pointers for identifying the libclang functions that I'd have to load dynamically</blockquote><div><br></div><div>Did you consider the option of doing this in a proxy library? That is a small library that the plugin would link against (instead of libclang) and exports the same ABI as libclang. The actual function implementations then doing the dynamic resolving and calling of libclang symbols. The boilerplate code for this function can likely be generated with a bit of scripting from the output of otool/nm of the kdevelop plugin (as that'll list all the symbols being used already, just need to filter out which one of those are defined in libclang and which ones are defined elsewhere). That limits the number of changes to the original codebase, reducing the risk of breakages, possibly needing just an initialization call to the proxy library to tell it where libclang is to be found.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know that what I'm proposing here isn't necessary for Linux packaging systems that can create multiple packages off a single build. But I guess that even on Linux not all distribution systems have that feature. Any distribution system that doesn't and that provides more than 1 clang version is going to benefit from an easy way to build and package only kdev-clang against each of those versions.<br></blockquote><div><br></div><div>I don't think the last part is true. Distributions will only build kdev-clang once against some libclang version, which will likely be whatever the default clang version is in the distribution at that point. Now there are two ways this can work: a) different versions of libclang are not co-installable, they conflict with one another, because they install the same /usr/lib/libclang.so or b) different versions are co-installable because they install differently named libraries /usr/lib/<a href="http://libclang-3.x.so">libclang-3.x.so</a>.</div><div><br></div><div>In case a), a user can simply install the newest version of libclang and still use kdevelop because of the binary compatibility that libclang provides, hence it does not matter wether kdevelop was built against 3.5 or 3.6. As long as the to-be-installed 3.8 version of libclang is compatible it'll provide the same shared library filename that kdevelop needs. This is also why the versions of libclang would conflict with one another.</div><div><br></div><div>The other case means a user can install any number of libclang versions at the same time and he's going to get two installed - one for kdevelop and one for whatever he needs for his work if the versions are different. Thats fine too, happens all the time on linux actually. The downside of this being that he won't benefit from any bugfixes/features in newer clang versions while using KDevelop.</div><div><br></div><div>It seems at least in Debian b) is the case, the libclang packages are carrying the version in the package name and install <a href="http://libclang-3.x.so">libclang-3.x.so</a>. Using dlopen would actually not provide any benefit in this case - it actually makes things harder since now C++ code is needed to redo the stuff the dynamic linker usually does: finding the <a href="http://libclang-3.x.so">libclang-3.x.so</a> to dlopen. The obvious easy solution to that is to setup a define during compile time with the name of the libclang library to be used, but then the package again will depend on a specific libclang version as other libclang versions install differently-named library files. So you'd end up with an 'search through all library directories for something starting with libclang and ending in so.1' and having to make sure to replicate the dynamic linker lookup logics correctly.</div><div><br></div><div>I don't know enough about library loading and dylibs vs. frameworks to really know how this would work on OSX or wether you'd end up with pretty much the same issues. However for linux, I think dlopen is not helping in any way, maybe I'm overlooking something - do you happen to know why audacity uses dlopen for ffmpeg? It seems at least on linux it does not do so, based on my limited abilities to look at the package: It has a few dependencies called libsomething-ffmpeg and it seems to fully link against those and not dlopen any of them (at least on Debian).</div><div><br></div><div>Andreas</div></div></div></div>