I am considering porting Pyrseas from Python to D.

Pyrseas consists mainly of two executables, dbtoyaml and yamltodb. The former outputs YAML representations of Postgres database catalogs and the latter reads the YAML files as well as the catalogs of another (or the same) database and outputs SQL to sync the definitions. Both programs use a common subpackage named dbobject.

If I were porting this to C++, I'd use CMake, which would build dbobject as a library and both executables with a single cmake --build (or ninja or make) command. In attempting to use dub on a similarly structured project, I've found that I'd probably have to list each executable as a separate "configuration". Furthermore, in order to build both executables, I have to either invoke dub twice, i.e., dub build -c dbtoyaml; dub build -c yamltodb. If I don't specify a configuration, only the first one listed in dub.json is built and if I specify two or more, only the last one in the command line is built. I know that I can create a Makefile with both programs listed in an all target, but that sort of defeats the purpose of using dub as a "build" tool. I have also found a cmake-d project on GitHub but it hasn't been touched for 18 months. Am I missing something on how to deal with multi-executable projects in dub (and I can think of many such projects)?

I also tried to use dfmt and found it limited in comparison to clang-format. I do realize that dfmt is a community-supported tool.

I find that D has much to offer in terms of language facilities and simplicity. About the only bump in the learning curve is the distinction between structs and classes. However, from a practical adoption perspective, it seems that in attempting to provide all the "batteries" it circumscribes itself to what is or can become available in its own community. If I understand correctly, GDC and LDC came into being because some people in the GCC and LLVM communities became interested in D. Has someone approached Kitware or the CMake community to determine the feasibility of supporting D? A similar question arises for clang-format, which (to my surprise) supports C#, Java and more?

On Monday, 13 March 2023 at 10:52:11 UTC, Joe wrote:

Dub isn't very good at doing more than relatively basic things natively (which covers enough D projects for it to not matter in the general case). I personally like to use Meson with D. e.g. It very easily allows multiple executables.

Technically you can use the build command values in dub.json/sdl to make it spit out an extra build; but it's obviously a bit of a hack. You could also have a small script/makefile to call the right dub build twice.

The issue with using Meson is that it makes using dub packages harder. Meson technically supports bringing in dub packages, but I've not managed to make it work right.

For better or for worse we're stuck with dub as the standard package manager + build tool one-in-all for most of our open source libraries.

D's auxiliary tooling has been woeful in comparison to other languages for the last 8 years I've been using it. It's down to a few factors such as manpower; lack of use/inability to use the D compiler's frontend for tooling, etc.

On the other hand the reason it feels bad to me is also because I mostly use C#; Typescript, and Go outside of using D - all of which have great (bar NPM) tooling and editor support so D may not actually be that bad overall. Glass Half Full or Half Empty kinda perspective.

It's constantly getting better, but is always "behind" the more popular languages. If you were to write up your struggles with dfmt and friends, then I'm sure it'll be taken as welcome feedback.

Have you met our lord and savior: D's metaprogramming? :D (Shamless plug)

But yeah generally you might find D is a bit less "cohesive" and may feel kind of "splattered" in terms of... well, everything about it. It's a volunteer project with a dire lack of volunteers.

Hope this helps, and hopefully I've kept misinformation to a minimum as I am very prone to working off of false memory.

On Monday, 13 March 2023 at 12:56:57 UTC, Bradley Chatha wrote:

Yeah, it seems like it's only for libraries (and a few single-exe utilities). Looking at code.dlang.org, under "Stand-alone applications/Server software", the top rated item is "handy-httpd" which according to its dub.json builds a library! And the second place "voxelman" is builds three libraries and one executable, which appears to be a "launcher" to access the libraries as plugins.

On Monday, 13 March 2023 at 13:20:21 UTC, Joe wrote:

The package registry is full of libraries, yes. That's what it's primarily for. There aren't a lot of executables uploaded there because they're usually better distributed in other ways. But plenty of people are using dub to build them.

One way to handle multiple executables is to write a simple script that makes multiple calls to dub with the configurations you need.

And I haven't looked into it yet, but it may be possible to use preBuildCommands to do the same thing. E.g., add a default with a preBuildCommands entry calling dub on multiple configurations.

On Monday, 13 March 2023 at 13:32:04 UTC, Mike Parker wrote:

That's essentially the same as using a Makefile (or CMake with custom commands) to build your project.

What I had in mind when I mentioned "multi-executable projects" was something like Postgres or say, a tenth of that, e.g., a server executable, two or more client and utility executables and one or more libraries, all of it spread over a few directories, possibly to a depth of say, two from the root. Can dub handle something like that, e.g., can it handle nested dub.json's, or wouldn't it make much more sense to build such a thing with make, cmake, meson?

On Monday, 13 March 2023 at 13:58:29 UTC, Adam D Ruppe wrote:

For the record, I wasn't trying to attack dub (or dfmt). I was more interested in determining whether DLang (the Foundation and/or the community) would consider working with the CMake and clang-format communities to get them to support D in their products, or whether they prefer to stick with what they have in terms of tooling. I think I heard someone at DConf 22 ask about getting Intellij support for D and Walter said that JetBrains would ask for funding to do that. I don't think CMake support/development is in the same boat, is it?