mac osx Syndicate content

» C++11 platform support?

Sun, 11/25/2012 - 17:53

Hello all!

I’m investigating the feasibility of allowing a subset of C++11 in the KDevelop code base, starting after the branch of 4.5 in a few weeks. I do not want to blindly start going that route just to realize afterwards that I’ve alienated a large portion of our user base. Thus I’d very much welcome if you could read through this blog post and give some feedback which we can build our decision on top.

Here’s the email I sent to the KDevelop development mailing list:

Is anyone opposed to open KDevelop 4.6 for C++11? I.e. that means we continue to work as-is and provide a kick-ass KDevelop 4.5. Once we branch 4.5, we enable C++11 mode globally and start using it in master.

Reasons:
  • KDevelop is a free time project and it should be fun to work on it. C++11 is quite a lot of fun, if not only because it’s new. This is actually the main reason for me to go down the C++11 route. This would also allow us to learn C+11 which is a benefit for those of us who do professional work-work programming.

  • Tons of potential performance benefits thanks to constexpr, noexcept, r- value references etc. pp.

  • Much easier to read code thanks to auto, lambdas, alias templates, defaulted functions, etc. pp. This also leads to better maintainability.

  • Improved compiler analysis thanks to e.g. static assert, override, final, nullptr, explicit conversion operators, deleted functions, etc. pp.

Compilers:

See also: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

Personally I’d say we should just require these compiler versions and above:

clang 3.1 - required for constexpr, lambda, initializer lists, …

GCC 4.7 - 4.6 might even be enough, but 4.7 has some more stuff like delegating constructors, override, final and non-static data member initialization.

msvc ctp november 2012 (http://blogs.msdn.com/b/vcblog/archive/2012/11/02/visual-c-c-11-and-the-…)

Potential Issues:
  • FreeBSD situation? http://wiki.freebsd.org/NewC%2B%2BStack <— I’m not sure how far they are. But quite frankly, I’d say they can stick to KDevelop 4.5 until they have a modern compiler like clang 3.1.

  • Debian? Wheezy should come with GCC 4.7 if I’m not mistaken: http://packages.debian.org/wheezy/gcc Imo it’s fine if we only support that version of Debian. All other distros probably already have GCC 4.7 available, or will have it in their next distro release in time for KDevelop 4.6

  • Windows? If anything breaks on MSVC it’s imo not an issue as KDevelop is defacto dead on Windows (noone is working on it there). Also considering that the windows team is actually working on proper C++11 support (see link above) its only a matter of time until it has everything we need.

  • Backporting: Now this is imo a potential issue, but considering that we don’t do such a good job in that regard anyways, it’s not that big a deal… And most of the fixes we do backport are oneliners which could be done in the 4.5 branches and forward ported to 4.6.

More Issues

So far a few more concerns where raised:

  • Mac OSX: only “recent” Mac OSX come with a clang that is new enough. Question is: Which version is that exactly? Do people use KDevelop on an older Mac OS? My personal impression was that most Mac users upgrade asap to the newest OS version, thus this should not be an issue?

  • Windows: While the team around Herb Sutter is doing a tremendous job in advancing the compiler to provide kick-ass standard support, apparently the Windows users are reluctant to upgrade… But the obvious question is: Should we be held back by an imaginary Windows user base? KDevelop does compile on Windows, and mostly works but afaik there are still some very sore spots, esp. in the CMake project management and the lack of a MSVC debugger integration. Anyhow, would allowing C++11 in the KDevelop code base make it considerably harder for potential contributors? Considering that even now we do not get any contributions from Windows users, I doubt it can get any worse… But I do see that it’s a hen/egg problem.

  • BSD: FreeBSD is in the process of using Clang. But is that process already finished? If not, is there any ETA? Will there be Clang 3.1? What about other BSDs and Unixoids?

What about unsupported platforms?

Personally, I think KDevelop is currently in a pretty good shape. If some platforms would have to stick to KDevelop 4.5, I don’t see such a big issue in that. We could also think about making it our first “LTS” release and backport essential bug fixes for a longer period.

Why not the Qt way?

Qt 5 makes use of C++11 features where possible in a backwards compatible way. It is of course the correct choice for a library that wants to support multiple platforms. But imo, KDevelop does not have such strict requirements. Rather, it should offer maintainable code that is fun to work on. Thus I am stricly against introducing Q_DECL_CONSTEXPR in our code, instead of using constexpr directly. And of course, in Qt you cannot use auto, nor lambdas, nor many other things as you always have to provide a C++03 fallback.

Lets try it out, no?

As Aleix pointed out, I’ll probably just start a new branch and introduce some C++11 features there. Then we can see whether the gain in code readability or performance is worth the introduction of the mandatory C++11 requirement.

» Massif Visualizer 0.2 released

Sun, 11/07/2010 - 00:16

Hey all!

I’m happy to release Massif Visualizer v0.2. This is mainly a “fix the build-system” release, no new features have been added.

You can download it here: http://kde-apps.org/content/show.php?content=122409

Mac Support

Thanks to the reports by Chris Jones it’s now possible to build and use Massif Visualizer on Max OS X, see e.g.:

http://www.hep.phy.cam.ac.uk/~jonesc/massif-visualizer-OSX-1.png
http://www.hep.phy.cam.ac.uk/~jonesc/massif-visualizer-OSX-2.png

He has also submitted the portsfile for inclusion in Macports: https://trac.macports.org/ticket/27168

KGraphViewer now optional

I’ve made the KGraphViewer dependency optional, if anyone does not want it (even though this removes like 50% of the tools features).

KDE Infrastructure

I’ve also prepared the steps for moving Massif-Visualizer into KDE Extragear and asked kde-devel for review. I already use the KDE infrastructure now:

Website:
https://projects.kde.org/projects/playground/sdk/massif-visualizer
Git:
git clone git://git.kde.org/massif-visualizer
Bug tracker:
https://bugs.kde.org/enter_bug.cgi?product=massif-visualizer&format=guided
Mailing List:
https://mail.kde.org/mailman/listinfo/massif-visualizer
massif-visualizer@kde.org

This also means that I’ll shortly get translations by the awesome KDE-i18n-Team, so stay tuned for a 0.3 including translations!

Open Suse Buildservice

I’ve also spent quite some time today battling with OBS and can provide at least packages for Fedora, Mandriva and Open Suse now. I’m still waiting for help on the remaining issues and once they are resolved I’ll add the remaining packages.

Changelog
  1. ChangeLog for massif-visualizer v0.2
  2. ====================================
  3.  
  4. * Milian Wolff: set version to 0.2
  5. * Milian Wolff: fix conditional
  6. * Milian Wolff: make kgraphviewer dependency optional
  7. * Milian Wolff: fix FindKGraphViewer.cmake
  8. * Milian Wolff: fix .po name
  9. * Milian Wolff: remove some esoteric cli option for XGETTEXT that does not make
  10. any sense according to Albert
  11. * Milian Wolff: fix: install libs to make sure they can get loaded on OSX e.g.
  12. * Milian Wolff: fix compile warning about init order, improve style by having
  13. just one init per line
  14. * Milian Wolff: add export macros everywhere, make visualizer helper use the
  15. Massif namespace as well
  16. * Milian Wolff: add Messages.sh