Support for C++ Files

[nicolasjinchereau]

Feature Request: Support for building/linking C++ files.

Currently I am forced to write/maintain custom build scripts for build, run, and clean.

My current script, which is limited to having all sources in the same path:

Working Path: ${SolutionDir} LDC_PATH="/Applications/ldc2-0.14.0-osx-x86_64" D_LIBS="$LDC_PATH/lib/libdruntime-ldc.a $LDCPATH/lib/libphobos2-ldc.a" mkdir -p obj/d mkdir -p obj/cpp mkdir -p bin cd ./obj/cpp clang++ ./../../.cpp -c cd ./../d $LDCPATH/bin/ldc2 ../../.d -c cd ./../.. clang++ $DLIBS ./obj/cpp/.o ./obj/d/_.o -o ./bin/$1

The Compiler Toolchains property page seems to have most of what's needed. I can set a default D compiler, default linker, and default libs. I cannot however set a default C++ compiler for D projects.

[aBothe]

I'm sorry but support for any other language won't be established - at least by me. I definitely don't want to mess around with any C(++) toolchains and such alike..there are hundreds of other tools available that care about this. All you might do is to put in a pre-build-command for your (non-dub -- this command won't get saved if it's a dub project) project, so e.g. make becomes executed, and after that, mono-d's normal build routines.

[nicolasjinchereau]

I was under the impression this would be easy.. I didn't mean to fully support C++ toolchains with intellisense and everything. I just want xamarin to pass all files with .cpp extension to a specified tool before building. Xamarin doesn't seem to have a way to get a list of project files into my build script. For example, ${InputFiles} does not work. Could you at least add a way to send all files with some extension to a certain tool or command line?

[nicolasjinchereau]

I guess what I'm asking for is something like Xcode's Build Rules: http://www.cocoanetics.com/files/Bildschirmfoto-2012-02-03-um-7.02.06-PM.png

Now that I think about it though, this kind of request may be better directed at xamarin studio

[etcimon]

Dub has support for these macros and scripts, you can add shell command callbacks during compilation of a D project directly. It also observes environment variables.

[aBothe]

Because cxx-things basically require extensive build command setup, I strictly recommend to stick to cmake and/or make. I don't want to enable further border-case features that will then remain unknown to the other 99% of all users despite it's been mentioned and explained in the manuals.

[nicolasjinchereau]

@aBothe: Ok, thanks anyways. Appreciate the quick response ;) @etcimon: I didn't know Dub could actually do all that. I'll definitely check it out!

[nicolasjinchereau]

@aBothe: Hey, one more question. You said "support for any other language won't be established - at least by me". Does that mean you may be interested if I do a pull request for this functionality?

[aBothe]

Yep, that's the thing - I do appreciate contributions very well :) Regarding the feature you may want to write, there once was a support for makefile-generation in Mono-D, but I removed it because of a single API conflict and..no one noticed the removal after all. I can look it up in the commit log if you want. I can also support you in finding the (e.g. API) things you need for programming - please contact me via irc on freenode at #d.mono-d

[nicolasjinchereau]

Well, If I did this, I would be borrowing a lot from the CBinding that is already included in MD, which I assume is compatible with both windows and mac.

[nicolasjinchereau]

About the makefiles, my point is to try and avoid constantly updating makefiles when I add/remove files from my project.

[aBothe]

Then I'd rather recommend to contribute to said CBinding, not Mono-D. Or make your own CBinding and, once it works, get a pull-request ready for the MonoDevelop guys to merge it. Providing infrastructure for building C++ sounds very messy and complex, so it'll be as large and extensive as Mono-D's 'native' (non-dub) D project building framework - and thus probably best-suited to be placed in an extra language binding like CBinding.

[aBothe]

Sure, sounds reasonable. But just think about configuring C++ compiler/linker commands via some GUI interface - that's a huge task which I don't want to accomplish :)

[nicolasjinchereau]

Ok, well, I'll start looking deeper into this issue and see what I come up with. Thanks :)

[etcimon]

If you contribute this, I think it would be preferable to add it in dub, and then add better corresponding dub support in mono-D, that way the whole community can benefit from this development.

This being said, I believe CMake is the way to go for C++ compilation. So, the possibility of using CMake configuration files in dub would be best, along with the ability to recognize those in Mono-D.

[nicolasjinchereau]

that way the whole community can benefit from this development

I don't understand.. if I added it to Mono-D, who would I be excluding?

I believe CMake is the way to go

The whole point of doing this is to get away from manually managing makefiles and build scripts, and make it easier to integrate C++ code into a Mono-D project. Why would I want to use CMake?

I think it would be preferable to add it in dub

I don't see how dub is relevant. Literally, I would like to be able to drag a bunch of C++ files into a Mono-D project, push build, and have them compile along with my D code, and then link into the resulting binary. Where does dub factor in?

[etcimon]

I don't understand.. if I added it to Mono-D, who would I be excluding?

The official package manager is Dub, and it's also used for compilation throughout because it's standard. The community still uses vim, sublime text, notepad++, emacs, etc. (a lot).

The whole point of doing this is to get away from manually managing makefiles and build scripts, and make it easier to integrate C++ code into a Mono-D project. Why would I want to use CMake?

You may want dub to be able to generate C++ files in that case. But it would be much more complicated than simply recognizing CMake configurations, since this is already the standard way of generating makefiles for C++. It's almost a standard for compilation in C++

Literally, I would like to be able to drag a bunch of C++ files into a Mono-D project, push build, and have them compile along with my D code

There's an incredible amount of compilation options to consider for C++. You'd have to re-invent CMake inside the IDE. Even CLion (the JetBrains C++ IDE) didn't do this and went for CMake integration directly...

Dub is already integrated to MonoD, maybe you should just add a "cSourceFiles": "./path/to/file.cpp" option in dub and make MonoD add it to the workspace from there?

You can also make MonoD write that line automatically with a dub configuration file editor built on top of a json parser, so that the configuration is updated when receiving a drop event...

[vinesworth]

I would like to be able to drag a bunch of C++ files into a Mono-D project, push build, and have them compile along with my D code, and then link into the resulting binary.

Were it that simple to compile C++ as it is to compile D, the latter would hardly emerge at all... Build systems were not invented to complicate one's life, but to make it easier, and even CMake is still complex. I'd personnaly prefer having C++ superseded by D, eliminating all the build-system-mess, than to integrate anything at all with it.

[aBothe]

So, to give an operative resolution advice™, I'd

• set up a cmake script that probably automatically gathers all your cpp-files and makes a neat makefile out of them once for a while,
• then insert a pre-build command into your D project that just invokes 'make' in your project folder -
• or, if you chose to have a dub project, perhaps set up some extra parameters for dub so it invokes make before building everything - perhaps @etcimon or @vinesworth might know some adequate dub.json tweaks :)

[etcimon]

I know there's a build mess in C++ and I'd also rather see it superseded with D, that's actually why I've been moving Botan to D. I think @aBothe solution is the ideal

[nicolasjinchereau]

-There's an incredible amount of compilation options to consider for C++ -You'd have to re-invent CMake inside the IDE -Build systems were not invented to complicate one's life

I still don't understand how you guys can look at my proposal and have such complicated things in mind, so let me clarify my exact use case:

If I had a C++ library that didn't have a D binding available for it, I may only want to expose a handful of things from its API. I could easily compile that C++ library with whatever facility it already had in place(CMake, MSVC project, etc..), and then link that static library to my D project. Then, I could create a simple wrapper *.cpp file and add it to my Mono-D project. With this approach, I wouldn't have to worry about how the C++ library was compiled, nor would I have to modify it by adding any kind of interoperability layer. And if that C++ wrapper resided inside my Mono-D project, I wouldn't have to worry about juggling another static library around or messing with build commands just to access a handfull of things I need from C++. The obvious case, would be not having to port the entire Cocoa API to D just to call retrieve [[NSScreen mainScreen] frame].

[aBothe]

I still don't understand how you guys can look at my proposal and have such complicated things in mind

Because then, somebody else might start to ask whether this or that further feature could be supported, and voilà, another wheel was reinvented - or that little feature will be discarded then again because it's way too incomplete for more complex set-ups :/

[nicolasjinchereau]

complex set-ups

Could you elaborate on what it is that is so complicated? What factors are involved in compiling C++ that are not present in D?

[aBothe]

Mostly dependencies, imho. Incremental compilation, compiler-specific extra features that absolutely must be used by certain users.

[nicolasjinchereau]

Mostly dependencies

Can these not be taken care of by linking static libraries or including the relevant header search paths? Or am I missing something?

compiler-specific extra features that absolutely must be used by certain users.

Could these not be handled by providing a textbox for additional compiler flags?

[aBothe]

Don't know a special case yet, perhaps it's indeed an insufficient argument - or perhaps one will see how complicated it might get later on. Anyway, if you like to do this, please feel free to contribute things - or perhaps fork Mono-D and build something in to it that is fitting your exact needs, nothing more, nothing less. I'll try to help you then :)

[nicolasjinchereau]

Awesome, thanks!

Don't know a special case, perhaps it's indeed an insufficient argument

I hope so =)

[etcimon]

I could easily compile that C++ library with whatever facility it already had in place(CMake, MSVC project, etc..), and then link that static library to my D project. Then, I could create a simple wrapper *.cpp file and add it to my Mono-D project.

Looks like a nice plan. I abandoned C++ wrappers altogether because I've seen it as being more work than copying the cpp code and making everything fit as D modules properly. Most API rely on the C++/boost standard library, which I could hardly even fathom the idea of an abstraction that doesn't escape GC. This would be all just way too much work and probably the biggest debugging nightmare in the making. Of course, if you manage to succeed it would possibly teach me a few things