Re: Code organization, dub, etc.
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
Re: Code organization, dub, etc.
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?
Re: Code organization, dub, etc.
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?
Re: Code organization, dub, etc.
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.
Re: Code organization, dub, etc.
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.
Re: Code organization, dub, etc.
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.
Re: Code organization, dub, etc.
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 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. 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.
