www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Code organization, dub, etc.

reply Joe <jma fc.com> writes:
I am considering porting 
[Pyrseas](/https://github.com/perseas/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
Mar 13 2023
parent reply Bradley Chatha <sealabjaster gmail.com> writes:
On Monday, 13 March 2023 at 10:52:11 UTC, Joe wrote:

 months.  Am I missing something on how to deal with 
 multi-executable projects in dub (and I can think of many such 
 projects)?


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](https://github.com/BradleyChatha/libbc/blob/master/meson.build#L84)
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.


 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.


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 

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.


 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.


Have you met our lord and savior: D's metaprogramming? :D 
([Shamless plug](https://www.youtube.com/watch?v=0lo-FOeWecA))

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.
Mar 13 2023
parent reply Joe <jma fc.com> writes:
On Monday, 13 March 2023 at 12:56:57 UTC, Bradley Chatha wrote:

 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.


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.
Mar 13 2023
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 13 March 2023 at 13:20:21 UTC, Joe 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.


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.
Mar 13 2023
parent Joe <jma fc.com> writes:
On Monday, 13 March 2023 at 13:32:04 UTC, Mike Parker 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.


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?
Mar 13 2023
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 13 March 2023 at 13:20:21 UTC, Joe 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!


I'm not particularly interested in defending dub - i consider it 
a useless piece of crap that I only suffer through cuz some users 
demanded it - but you can use the subpackage thing to build 
multiple executables. My thing here does it:


https://code.dlang.org/packages/adr-terminalemulator

relevant config code  here:
https://github.com/adamdruppe/terminal-emulator/blob/master/dub.json#L31

So the mactabs exe and the attach exe and so on are all a bit 
different programs you can run from the code.
Mar 13 2023
parent reply Joe <jma fc.com> writes:
On Monday, 13 March 2023 at 13:58:29 UTC, Adam D Ruppe wrote:

 I'm not particularly interested in defending dub - i consider 
 it a useless piece of crap that I only suffer through cuz some 
 users demanded it


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?
Mar 13 2023
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 3/13/23 07:30, Joe wrote:


 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


That would be great. I hope it will eventually happen.

I've used CMake on existing projects only as a tool that is better than 
some others. Witnessing CMake being replaced by even better tools like 
Bazel, should CMake be a target or should Bazel, etc. take precedence?

Ali
Apr 07 2023