On Sunday, 22 August 2021 at 03:22:02 UTC, Brian Tiffin wrote:
Is this wrong thinking? I'm ~~working on~~ playing with a
first project.
Meant to be a suite of tools, each usable from the command
line, i.e. with a `main`. Then a manager program that accepts
subcommands for dispatch *and other boss type things*.
boss.d wants to import command1.d command2.d etc.
Is there a way for `command1.d` to know it's an `import` versus
a file named as part of a `gdc` compile?
I'd like to skip defining `main` during `import` (using a
different name for boss dispatch), but do define `main` when
it's a standalone compile. Or is that a bad way of thinking
about D program development interactions?
Cheers
IIUC, you want to generate multiple binaries, too ?
In which case, I think you need more of a build tool solution
than a language solution.
Recent-ish versions of DUB (>= v1.24.0) support this out of the
box.
Provided the following structure:
```
+ $(pwd)
+ - dub.json
+ - source/
+ - source/appname/
+ - source/appname/prog1.d
+ - source/appname/prog2.d
+ - source/appname/common.d
```
If your `dub.json` contains:
```
{
"name": "swissarmyknife",
"targetType": "executable",
"configurations": [
{
"name": "prog1",
"targetName": "prog1",
"mainSourceFile": "source/appname/prog1.d"
},
{
"name": "prog2",
"targetName": "prog2",
"mainSourceFile": "source/appname/prog2.d"
}
}
```
It will build `prog1` by default, and `prog2` if you use `dub
build -c prog2`.
Note that you might want to put a `library` configuration as
first entry,
so that you can also use your code base as a library if you wish
to extend your project later.
