It turned out, that the required changes to add support for C files in Dub are really small. So I added a PR (https://github.com/dlang/dub/pull/2521). There is also some other PR (https://github.com/dlang/dub/pull/2270) releated to C file support in Dub.

With my PR (2521) applied I can now compile my ImportC test projects (https://gitlab.vahanus.net:dlang/examples/importc-tests.git) without any additional hacks. Just a current copy of DUB with the patch and a current beta build of DMD is needed.

$ ../../dub/bin/dub build -v --compiler=dmd-beta -f
Using dub registry url 'https://code.dlang.org/'
Note: Failed to determine version of package importc-app at .. Assuming ~master.
Generating using build
Configuring dependent importc-app, deps:
    Starting Performing "debug" build using dmd-beta for x86_64.
    Building importc-app ~master: building configuration [application]
dmd-beta -c -of.dub/build/application-debug-linux.posix-x86_64-dmd_v2.101.0-beta.1-38-gfabd06214e-B8D88D35889281A0F16BEA64448915871A8820982AFB76E0D5F2AD9849AF80E5/importc-app.o -debug -g -w -version=Have_importc_app -Isource/ source/app.d source/some_d_file.d source/zstd_binding.c -vcolumns
     Linking importc-app
dmd-beta -of.dub/build/application-debug-linux.posix-x86_64-dmd_v2.101.0-beta.1-38-gfabd06214e-B8D88D35889281A0F16BEA64448915871A8820982AFB76E0D5F2AD9849AF80E5/importc-app .dub/build/application-debug-linux.posix-x86_64-dmd_v2.101.0-beta.1-38-gfabd06214e-B8D88D35889281A0F16BEA64448915871A8820982AFB76E0D5F2AD9849AF80E5/importc-app.o -L--no-as-needed -L-lzstd -g
Copying target from /home2/cschlote/build/dlang/importc-tests/dubbed/.dub/build/application-debug-linux.posix-x86_64-dmd_v2.101.0-beta.1-38-gfabd06214e-B8D88D35889281A0F16BEA64448915871A8820982AFB76E0D5F2AD9849AF80E5/importc-app to /home2/cschlote/build/dlang/importc-tests/dubbed

However, the maintainers of Dub seem to have different ideas resulting into much more work to be done. Their ideas are surely good and reasonable, but it sounds like a lot of changes needed to be applied before we see support for direct and easy C file support in Dub.

In the meantime (weeks, months, years?) you are forced to either pass an explicite list of C sourcefiles in dub.json (see previous forum posts), or use some preBuild/Generate commands to compile your C source file(s) to object file(s) and add these object files to other explicite list as linker input. Both ways are ugly and cumbersome.

What we need in dub instead is that C files are just picked up like any other D file as a valid source for the compiler. And without any explicite lists of source files in dub.json.

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/C++. If you want to include a C header, just wrap it into a C file, which is then picked up by Dub and passed to the D compiler. See the mentioned example project for wrapping the ZSTD C header. This is easy and straight forward.

I'm pretty sure that any additional code to support the simple usecases for C header files will also be easy to implement.

So if 80% or more of the general usecases with C source/header files in Dub can be implemented with simple and small changes like with the PR mentioned above, we should do it now.

A better and more general implementation covering 100%+ of all thinkable usecases and edge conditions can be done later after having a working solution now, instead of discussing a proper solutions for several months.

IMHO straight-forward and easy support for using C files in Dub projects is a must for the up-coming next DMD release with its much improved ImportC feature.

It will also help a lot when we want to promote D as a suitable language alternative for C/C++ programmers. As long as D needs hand-crafted binding files or other hacky workarounds instead of just ìmport your.c.file; and a C source wrapper it will be hard to convince them.

So I strongly recommend to add easy to use support for C files in Dub projects ASAP.

On Sunday, 30 October 2022 at 12:46:10 UTC, Carsten Schlote wrote:

Agreed, but don't forget about the .i extension.

Imo we could add a switch which enables something like your PR (include .c and .i) until we know what the default should be.

On Sunday, 30 October 2022 at 13:38:23 UTC, Imperatorn wrote:

I will merge the two PRs into a new patchset, and also add appropriate code
to search für {c|i|h} files at the right places. The patchset should be as minimal as possible, so that the planned better solution is not blocked/messed up.

Maybe a switch/flag should be added to the dub.json/sdl files to turn on the new behaviour? This allows to enable the new search logic for C files without breaking something old. It would make it more clear, that also a new 2.101+ D compiler is needed.

On Sunday, 30 October 2022 at 14:42:55 UTC, Carsten Schlote wrote:

Yeah maybe something like that. Because I agree we need to update it since we now have ImportC.

On Friday, 28 October 2022 at 19:08:47 UTC, Steven Schveighoffer wrote:

  "sourceFiles" : ["source/zstdc_binding.c"]

What if the dub.json target is a staticLibrary?

Right now I have this error:

gdc: fatal error: cannot specify ‘-o’ with ‘-c’, ‘-S’ or ‘-E’ with multiple files

Since both (a single) .d file and the single line .c (include ".h") file is on the command line:

e.g.

gdc -dip25 -Wno-error=builtin-declaration-mismatch -fall-instantiations -c -o /.dub/cache/liblfdsd/0.3.4/build/library-unittest-swOTDhNpx8l9YtK1BPSAow/liblfdsd.a -fdebug -g -Werror -Wall -Wno-deprecated /.dub/packages/liblfdsd/0.3.4/liblfdsd/source/liblfdsd.d /.dub/packages/liblfdsd/0.3.4/liblfdsd/source/liblfdsd_ImportC.c -Xlinker -Xlinker -llfdsd -Xlinker -llfdsdc -Xlinker -llfds711

Thanks.