compile x64 .dll and .so without dependencies
It there any recipe to compile x64 .dll without dependencies? I mean it shoud be used without installing things like msvcr120.dll. Dependencies on system dll (advapi32.dll, kerner32.dll) is ok. I don't experiment on linux yet. But interest too.
Re: Use dub to create source lib and executables
On Saturday, 4 March 2023 at 21:31:09 UTC, Richard (Rikki) Andrew Cattermole wrote: Yes dub was setup to cover the most common cases, but ignores when you have multiple outputs. Not ideal. There is a PR to add build steps currently, which will help improve things, so there is work to make dub better at these less common use cases. The simplest solution is to do one package per binary, then use a shell script to trigger them in succession, not great but a workable solution. It's interesting to hear that multiple outputs are rare for other developers. So I was hoping to do away with shell scripts (or make) since dub is common on all systems, but alas it's not worth the effort, so I won't continue to try and make `"targetType":"none"` work. By the way, do you know if there will be a dub "build-all" type command in the future?
Re: Use dub to create source lib and executables
Yes dub was setup to cover the most common cases, but ignores when you have multiple outputs. Not ideal. There is a PR to add build steps currently, which will help improve things, so there is work to make dub better at these less common use cases. The simplest solution is to do one package per binary, then use a shell script to trigger them in succession, not great but a workable solution.
Re: Use dub to create source lib and executables
On Saturday, 4 March 2023 at 20:23:29 UTC, Steven Schveighoffer wrote: On 3/4/23 1:33 PM, Chris Piker wrote: If you mean that you have multiple subprojects inside your main dub project, my advice is to follow what other such projects do. I always look at vibe for my example. I have been trying to do that for hours, and all I get is cryptic error messages from dub. I've tried all in one top level dub.json, I've tried three dub.json files, one at the top level and one for each of lib and utilities. The fact that dub considers the output of a project to only be a single lib, exc, etc. is quite restrictive and it means we have to have a target of "none" and then subprojects, which is cumbersome at best. Maybe it's just the frustration talking, but it seems wrong that a build rule that is so trivial to construct using 1980s makefiles is so hard today. If I wasn't trying to blend in I would have just given up a long time ago. But thanks for mentioning vibe.d as an example I'll take a look.
Re: DUB test and strings that look like D code
The analysis is pretty brain dead. https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L611
DUB test and strings that look like D code
Is it just me, or does this happen for someone else, too?
Init a fresh DUB project and create a file (e.g. `lib.d`) with
the following content:
```d
unittest {
string x = "module oh.dear.dub.what.are.you.doing;";
}
```
Then run `dub test`:
```
.dub/code/foo-test-library-unittest-linux.posix-x86_64-ldc_v1.31.0-E3344CC6C11D674C408FBF98D8EEFA551F60B915102F9E22FF0F316715677AD5/dub_test_root.d(3,15):
Error: unable to read module `doing`
.dub/code/foo-test-library-unittest-linux.posix-x86_64-ldc_v1.31.0-E3344CC6C11D674C408FBF98D8EEFA551F60B915102F9E22FF0F316715677AD5/dub_test_root.d(3,15):
Expected 'oh/dear/dub/what/are/you/doing.d' or
'oh/dear/dub/what/are/you/doing/package.d' in one of the following import paths:
import path[0] = source/
import path[1] =
.dub/code/foo-test-library-unittest-linux.posix-x86_64-ldc_v1.31.0-E3344CC6C11D674C408FBF98D8EEFA551F60B915102F9E22FF0F316715677AD5
import path[2] = /opt/ldc/bin/../import
```
The DUB-generated test program:
```d
module dub_test_root;
import std.typetuple;
static import oh.dear.dub.what.are.you.doing;
// […]
```
Re: Use dub to create source lib and executables
On 3/4/23 1:33 PM, Chris Piker wrote: Hi D I normally work in a *nix environment, typically on server-side code. For many projects I have gnu makefiles that build a small lib along with command line utilities. Up to now I've been creating a dub.json file for just the sourceLibrary, and then putting embedded dub comments at the top of each of the utility programs. The utilities are built via `dub build --single` and a thin makefile triggers all the dub commands. This method is inefficient, and it won't work in a typical Windows dev environment, so today I'm trying to remove gnu make from the picture. Going back to basics, does anyone know of a clear example of how to convert this simplified makefile into 1-N dub files?: ```makefile # Build library + utility programs. # Lib sources are in "libsrc", 1-file programs in "utils" # Implicit rule to make a utility program outdir/%:utils/%.d outdir/mylib.a dmd -I libsrc -od=outdir -of=$@ $^ # Top level build rule for everything build:outdir/mylib.a outdir/prog1 outdir/prog2 | outdir # Explicit rule to make output directory if not present outdir: @if [ ! -e outdir ]; then mkdir outdir; fi # Explicit build rule for the library outdir/mylib.a:libsrc/mod1.d libsrc/mod2.d dmd -lib -od=outdir -of=$@ $^ ``` This is a paired down example since `make test` and `make install` aren't present, but I hope the main ideas are apparent. I've been at it now for about four hours, with lots of web-searches (btw, thanks to schveiguy for getting me this far) but I haven't figured out what hierarchy of dub constructs I need to create to order to get the effect of the small make file above. Thanks for considering the question, If you mean that you have multiple subprojects inside your main dub project, my advice is to follow what other such projects do. I always look at vibe for my example. dub isn't great when it comes to the "one true way" to specify this. You can actually create a dub subproject inside your dub file, or create dub files inside all your other subproject folders, and tag them as subprojects of the main project. I've tried both ways, and I find the latter to be easier to deal with. This is what vibe does. -Steve
Re: Using Windbg to debug D applications and unittests
On Monday, 27 February 2023 at 12:09:50 UTC, Basile B. wrote: At least this is what is done for the Dexed GDB widget, so that gdb breaks automatically when an Error or an Exception is new'd (https://gitlab.com/basile.b/dexed/-/blob/master/src/u_gdb.pas#L2072). Glad you mentioned Dexed. I Had been meaning to try it out but forgot about it. I just downloaded the deb and will give it a go. Thanks!
Use dub to create source lib and executables
Hi D I normally work in a *nix environment, typically on server-side code. For many projects I have gnu makefiles that build a small lib along with command line utilities. Up to now I've been creating a dub.json file for just the sourceLibrary, and then putting embedded dub comments at the top of each of the utility programs. The utilities are built via `dub build --single` and a thin makefile triggers all the dub commands. This method is inefficient, and it won't work in a typical Windows dev environment, so today I'm trying to remove gnu make from the picture. Going back to basics, does anyone know of a clear example of how to convert this simplified makefile into 1-N dub files?: ```makefile # Build library + utility programs. # Lib sources are in "libsrc", 1-file programs in "utils" # Implicit rule to make a utility program outdir/%:utils/%.d outdir/mylib.a dmd -I libsrc -od=outdir -of=$@ $^ # Top level build rule for everything build:outdir/mylib.a outdir/prog1 outdir/prog2 | outdir # Explicit rule to make output directory if not present outdir: @if [ ! -e outdir ]; then mkdir outdir; fi # Explicit build rule for the library outdir/mylib.a:libsrc/mod1.d libsrc/mod2.d dmd -lib -od=outdir -of=$@ $^ ``` This is a paired down example since `make test` and `make install` aren't present, but I hope the main ideas are apparent. I've been at it now for about four hours, with lots of web-searches (btw, thanks to schveiguy for getting me this far) but I haven't figured out what hierarchy of dub constructs I need to create to order to get the effect of the small make file above. Thanks for considering the question,
Re: Desiring bool any_key_pressed()
On Friday, 3 March 2023 at 03:38:56 UTC, Daren Scot Wilson wrote: Here is a very simple version of the program I'm working on. Is there a way to write is_any_key_pressed() that doesn't block, doesn't require the Enter key, and doesn't require dragging in any complex libraries or dealing with low-level stuff like ioctl()? You have to do something since the normal behavior is the operating system holds on to the input until the user presses enter. You must tell it not to do that somehow. My terminal.d lib at least stands alone (for now, the next version will probably require two files instead of just one) and has things for this: http://arsd-official.dpldocs.info/arsd.terminal.html#single-key It is `input.kbhit()` just to test without getting the thing. Though... testing for input like this is a kinda iffy thing to do too, you might be able to adjust the program to be more event driven. Anyway, it is the "RealTimeConsoleInput" object in the library that tells the OS to stop buffering and send things directly. Its code isn't too complex - calls to tcgetattr and tcsetattr and similar for Windows - but still.
