Add support for ImportC

[ryuukk]

Fixes #2269

[rikkimax]

I'm not convinced that we should be fixing this.

A good example of why is that you have missed header files.

Instead, we should be discussing how to separate dubs build manager from its package manager and build a proper build manager for it that isn't D specific.

In the meantime, dflags should work.

[cschlote]

No, just dflags do not work. You must either pass an explicite list of C sourcefiles in dub.json (see forum posts), or use some 'preBuild' command to compile your C code to object files and add them to some other explicite list for the linker.

What I need in dub is that C files are just picked up like any other D file as a valid source for the compiler. The C header files are intentionally left out here, because it is bad style to have real functions in a C header. Yes, I know, people are doing such things. It is one of the bad habbits of C. If you want to include a C header, just wrap it into a C file, which is then compiled by the D compiler. See the mentioned example project for wrapp ZSTD header.

I strongly recommend to add working support for ImportC ASAP.

The cleanups you mentioned can be done later after some working solution is provided now. We are talking about really small changes here. Also the other PR is pretty small. There is no danger to mess up sources with some complicated intermediate solution here.

But with the next DMD release we should be able to use ImportC directly and eaily instead of explicite sourceFile lists, cumbersome workarounds and preBuild/Generate hacks.

Straight and easy support for using C files in DUB is a must with the next DMD release. I will help a lot when we want to promote D as a suitable language alternative for C/C++ programmers.

[ryuukk]

@cschlote i agree with you we should speed up to get ready for the next DMD release

[bachmeil]

Compilation of C files is not "preBuild". ImportC means there is no longer a distinction between C files with supporting functions and D files with supporting functions. For example:

foo.d

import bar;
import std.stdio;

void main() {
  writeln(mul(3.7, 1.2));
}

bar.c

double mul(double x, double a) {
  return a*x;
}

This is compiled with dmd foo.d bar.c. I could then change the extension on bar.c and compile with dmd foo.d bar.d. Since we don't compile bar.d with a preBuild command, there's no reason to do so with bar.c. ImportC exists and it should be recognized by Dub. That means there is no distinction between source files whether they have a .c or .d extension.

[cschlote]

I know, that you can pass the C files directly to the D compiler. But this is not the usecase here. I'm talking about using C files in DUB projects. And Dub is NOT picking up any C source file in e.g. the default 'source' directory (or anywhere else) of a Dub project. And so it is not passed to the D compiler resulting into the problem of missing symbols.

An important point is to also support the C header files. As well as preprecessed intermediate files.

I will create usecases for these scenarios and provide a new PR asap. Obviously there is some need for it.

[bachmeil]

But this is not the usecase here.

Perhaps not what you are after, but this commit changes if (file.endsWith(".d")) { to if (file.endsWith(".d") || file.endsWith(".c")) {, and it was closed without merging.