Let's talk build systems and tooling for C++


  • area_deu

    I need to start a new C++ project. Unfortunately, C or C++ are the only logical language choices since we will sadly need to do a lot of low level fuckery of the "how do we optimize this memory layout for perfect cache layout" and and the whole bag of stuff alike that normally comes with a sophisticated hard real time simulation. Our team definiatly has the expertise for this, but all of us have worked on other projects

    Rust is out of the window for multiple reasons, including that we will need to do so much stuff that would get us in trouble with the borrow checker that we would probably waste more time satisfying it than just using rigorous tooling support in C++ and spent the time gained on even more code reviews by the whole team. That and two very key people in the team hate Rust so much you would think it had killed their parents, but I would be in the position to force them and they have already approached me and said they were willing to overcome their personal reservations if it were for the best of the project.

    Most other languages go out the window simply because they are not low level and "systems" enaugh.

    I hate C++. But it is the only choice left to us. The only upside is that I am in charge of setting up our development environment we will all use. The only problem is that no matter how I look at it, all tooling fucking sucks.

    Which is, in your opinion, the least worst build system for use with C++?

    What other tools can you suggest that would help me not die of hatred for how bad everything about c++ development is? I know sure as hell to use valgrind, if past experience has taught me anything, but the whole build toolchain has allways been in the "not my fucking problem" domain.

    Which cross platform IDE's do not suck?(My experience and cursory reading tells me the answer is probably "none")

    Which awesome plugins for sublime or atom or whatever would you suggest to make my days on this earth less like hell and to inform my personal editor choice?


  • Discourse touched me in a no-no place

    @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    Which is, in your opinion, the least worst build system for use with C++?

    What platform are you running your tools on? Is it the same as the platform that you're using to run the code you're developing? If they're different, you're greatly constrained.



  • I personally use CMake for everything - it takes some getting used to, but all the documentation you need is there. There is also the Meson build system, which I haven't used, but it's supposed to be a competitor to CMake.

    Example CMake project: https://gist.github.com/LB--/ce3c51ad24b14f4bdff860f155d2dd14

    I haven't used it myself, but I've heard KDevelop is good, and it has Windows support too:

    As for a compiler, I'd recommend clang and gcc on *nix and MSVC and Nuwen MinGW on Windows. Just tell your build system what to use and let it figure it out.


  • Grade A Premium Asshole

    @Quwertzuiopp what platforms do you need to support?


  • area_deu

    @dkf The Code will have to run on both Windows and Linux and will also have to be buildable from and for both, so potential build tools need to support both. Development can happen on both Linux or Windows, we will have both on our machines anyways for local testing, so if you can suggest me tooling that will make my life easier but only runs on one OS because there is no port, that is fine.

    The important thing is just that the build system and any kind of buid time tooling have to support windows and linux because we need to be able to build and do the real load testing on the dedicated machines and those are both linux and windows machines because we need to support both.


  • Discourse touched me in a no-no place

    @Quwertzuiopp Well, that can be anything from very easy to very difficult, depending on what libraries you're using and how much platform-specific code you've got to weave in there.

    A make-based build is basic and usually verbose, but relatively easy for people to comprehend. Cmake hides more of the details, which is fine when things are working and horrible when things aren't. You probably don't want to use any IDEs to directly do the builds; they're nice enough, but more awkward to automate than something that starts out from the perspective of automation. IDEs also tend to infect your code with their own quirks, which can matter a lot as you're intending to work cross-platform; if you'd been single platform, the'd have been far more recommendable.

    You probably ought to look into doing automated builds, either nightly or on commit (depending on how long they take). Like that, if someone fails to commit a key file, it becomes clear that they fouled up sooner rather than later.


  • area_deu

    @dkf said in Let's talk build systems and tooling for C++:

    You probably don't want to use any IDEs to directly do the builds; they're nice enough, but more awkward to automate than something that starts out from the perspective of automation. IDEs also tend to infect your code with their own quirks, which can matter a lot as you're intending to work cross-platform; if you'd been single platform, the'd have been far more recommendable.

    Yeah, I figured that much. I just tried to be open because if someone comes and tells me he found the holy grail of software and points me to this new little known cross platform ide that is perfect in every way I am not the one who is going to stop him from enlightening me.

    Libraries are luckily not going to be much of a problem because there are only two well tested and very minimal ones with zero fear of versioning fuckery. Most of what we need we are going to need to roll our selfes this time around, its a very different experience being on a project where you actually have to legit invent the wheel instead of stopping everyone around you from reinventing it.

    I know that it's a little limiting that I can't tell more, but thanks for the pointers so far

    @LB_ said in Let's talk build systems and tooling for C++:

    I personally use CMake for everything - it takes some getting used to, but all the documentation you need is there. There is also the Meson build system, which I haven't used, but it's supposed to be a competitor to CMake.

    Meson does indeed look very nice and does not instantly give my inner usability tester a heart attack like most other build systems. Considering the build itself is probably not going to be complex and instead have all the complexity inside the project itself, having something this simple would be lovely; the question just remains how well it lets you automate, but if it is consistent with what I have seen it should be at least a breeze in relation to others.

    Aside from running on Linux and Windows, the easy setup is also a big plus.



  • @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    Which is, in your opinion, the least worst build system for use with C++?

    Our C++ code here is heavily based on Qt, so we use their build system (qmake). It's... definitely not the best system, but probably not the worst either... It's actually only a wrapper for Makefiles, or generating VS files, so sometimes things leak a bit between the two layers (but in my experience, it's quite rare unless doing really weird things). For a standard use, it works reasonably well.

    As far as I can tell, using it does not mean that your code has to use Qt in any way, which is probably good for what you want.

    Which cross platform IDE's do not suck?(My experience and cursory reading tells me the answer is probably "none")

    Same as above, we use QtCreator. Again, it's... not the best IDE, but not the worst either! On Linux, it integrates quite well with gdb, and it also tries to integrate with valgrind, with less success (the memory checker part is tolerable, the performance one is unusable -- I only know of kcachegrind on Linux that does a reasonable job of showing valgrind results). It has a vim-like editor if you want, which kind-of-works as long as you don't want to do more than using a few regexps and cut-and-pasting code (assuming you like vim, of course...).

    It's probably not the tool you want to use in the end, but someone had to mention it!


  • Discourse touched me in a no-no place

    @remi said in Let's talk build systems and tooling for C++:

    the performance one is unusable

    It takes skill to use the performance analysers anyway.



  • You could use automake. Runs on pretty much every platform.

    As an added bonus, you wouldn't ever have to touch C++, as you'll still be trying to work out how to get the build system to actually build something in 3 years time.


  • Discourse touched me in a no-no place

    @tufty said in Let's talk build systems and tooling for C++:

    You could use automake. Runs on pretty much every platform.

    But then you'd have automake on you. And libtool. And GNU shit.

    As an added bonus, you wouldn't ever have to touch C++, as you'll still be trying to work out how to get the build system to actually build something in 3 years time.

    😆



  • @dkf said in Let's talk build systems and tooling for C++:

    It takes skill to use the performance analysers anyway.

    True. But using one with a flat listing without the ability to navigate properly between calls and to break down costs requires more than just skill...



  • @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    Which is, in your opinion, the least worst build system for use with C++?

    CMake worked fine so far for me. Making it cross-compile to Android took some persuasion and MacOS project requires a bunch of extra attributes to appease XCode, but compiling on Windows with any toolchain (Microsoft or MinGW), compiling on Linux with any toolchain (Gcc or CLang) and cross-compiling from Linux to Windows (with MinGW Gcc) were all simple and worked.

    It does take a bit of learning since it has its own scripting language, but I think it is worth it.

    @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    I know sure as hell to use valgrind

    I've recently noticed there is also a Windows tool, Dr. Memory, basically equivalent to Valgrind's memcheck skin.

    @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    Which cross platform IDE's do not suck?

    Huge advantage of CMake is that you can easily use different on each platform. You might give Qt Creator a look, but I didn't use it enough to give you decent review—I generally use ViM with YouCompleteMe on Linux and mix it with Visual Studio on Windows. And while ViM does not come with decent debug support, the YCMD completion engine is excellent.

    @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    Which awesome plugins for sublime or atom or whatever would you suggest to make my days on this earth less like hell and to inform my personal editor choice?

    The YCMD completion engine lists, besides the above-mentioned ViM, plugins for Emacs, Atom, Sublime, Kakoune and VSCode. And the completion quality is better than many IDEs, especially for C++ where it uses CLang front-end.



  • @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    cross platform IDE's [sic]

    JetBrains has "A cross-platform IDE for C and C++" called CLion:

    I haven't had the chance to check it out, but JetBrains has a reputation for making intelligent tools (cue complaints about Resharper).

    Predictably: they support GCC/Clang, CMake, GDB. No MSVC.


  • Grade A Premium Asshole

    Give ELLCC a look.

    www.ellcc.org


  • Discourse touched me in a no-no place

    @DCoder said in Let's talk build systems and tooling for C++:

    JetBrains

    Something about their IDEs doesn't work with the way I think. No idea exactly what.


  • Winner of the 2016 Presidential Election

    @DCoder said in Let's talk build systems and tooling for C++:

    JetBrains has "A cross-platform IDE for C and C++" called CLion:

    […]

    I haven't had the chance to check it out, but JetBrains has a reputation for making intelligent tools (cue complaints about Resharper).

    The type checker still has a few bugs, so you'll occasionally see red squiggly lines although there's no error. Other than that, it's pretty good. Far better than any other C++ IDE I've tried.


  • BINNED

    On the front of QtCreator I'll just add that it does seem to do CMake quite well too, but I haven't used it myself (like in @remi's case, we use Qt as a framework as well and qmake Just Worksâ„¢ when it comes to that).

    Out of all IDEs on Linux I used I actually like it the most (NB: didn't use any commercial ones), even though it has some usability holes ("Find usages", for example, is just a glorified search and can sometimes fuck it up), but I'm happy with it overall. This might be a bit biased due to nice help/reference system when it comes to Qt part which I just love. I don't know how easy it would be to add help files for your own libraries and such. It will basically take Doxygen-generated files and provide contextual help using that, so if your set of libraries has that it might be useful.


  • area_pol

    @Quwertzuiopp said in Let's talk build systems and tooling for C++:

    build system for use with C++?

    CMake is does cross-platform compilation well.

    @remi said in Let's talk build systems and tooling for C++:

    Qt, so we use their build system (qmake)

    CMake can also build QT projects.



  • @Adynathos said in Let's talk build systems and tooling for C++:

    CMake can also build QT projects.

    Do you mean that you can compile Qt code with CMake (in which case it's no different to Makefiles or command line, Qt is just one more lib to link with...), or that CMake can use Qt .pro files directly (which would be more interesting!)?



  • @Onyx said in Let's talk build systems and tooling for C++:

    it has some usability holes ("Find usages", for example, is just a glorified search and can sometimes fuck it up)

    I have the complete opposite experience on that. For me Find usages in QtCreator works (almost) perfectly and in a fraction of a second. Compare to VS2015, where the same function churns for at least 10-20 s (same code base, same computer) and returns tons of false positives (comments, same function but in a different class etc.), to the point of making it useless.

    (but this is not a thread about the failings of VS... otherwise I would have a few more to add!)


  • BINNED

    @remi it's not horrible, that's for sure, but it doesn't take build settings into account (had it find stuff in files that were excluded from build by a preprocessor command) and I think I had it fail at considering namespaces at one point.

    I mean, nothing horrible, but if you have a tricky project loaded into it it does fail at times. I'll admit these are probably edge cases though.



  • @Onyx ah, yes. If QtCreator gets the #define right, I think that Find correctly uses it, but there are some cases where that fails, yes. I haven't had issues with namespaces, but I don't do complicated things with them (and still that's enough to totally mess up VS... but I already said that this is not about bashing VS ;-) ).

    I agree that it's not foolproof, but it works reasonably well for a reasonably straightforward project. Which is, in my experience, a fair assessment of QtCreator in its entirety.


  • area_pol

    @remi I think it can perform all the Qt preprocessing and be used instead of .pro files.


  • BINNED

    @Adynathos said in Let's talk build systems and tooling for C++:

    @remi I think it can perform all the Qt preprocessing and be used instead of .pro files.

    This seems the way it works, yes. CMakeLists.txt file from Otter browser project:

    Notice stuff like qt5_add_resources. Also, an older version of it that I have on disk (or that was modified by the build process? Not sure, I didn't use CMake much) also has qt5_use_modules. So yeah, it seems to be able to replace the .pro files completely.

    Also:

    0_1478353484338_upload-8fd6200a-8021-485e-8cb9-680ed241becd

    So, yeah, fully supported I'd say.



  • @Quwertzuiopp scons seemed sensible at university.



  • @Quwertzuiopp I wish Jonathan Blow would just publish already his low level programming language.

    It seems to be coming along nicely.

    Demo: Quick Lambdas, Looping Polymorph Solver – 54:07
    — Jonathan Blow



  • @cartman82 Er, I think @Quwertzuiopp is locked-in to using C++ at this point - unless I misunderstood the first post.



  • @lucas1 said in Let's talk build systems and tooling for C++:

    @Quwertzuiopp scons seemed sensible at university.

    I last tried scons a few aeons ago. It is pretty reliable, but it does not integrate too well with IDEs. Or rather, IDEs don't integrate well with use of different build system, but in corporate environment, everybody usually wants to use the IDEs, which makes CMake with its ability to generate projects using the corresponding default build system indispensable despite all its idiosyncrasies due to having to be dumbed down to the IDEs level.



  • @Adynathos said in Let's talk build systems and tooling for C++:

    CMake can also build QT projects.

    And QT Creator also integrates CMake quite nicely.


Log in to reply