Re: modules and mains
On Sunday, 22 August 2021 at 10:24:13 UTC, Mathias LANG wrote:
On Sunday, 22 August 2021 at 03:22:02 UTC, Brian Tiffin wrote:
...
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.
Cool, thanks Mathias. I'm still using `gdc-11` on the play
machine. I tried `dub` with vibe.d and it's borked on this 32bit
laptop. Probably simple, but at this point on the learning
curve, the hassles with dmd and dub are keeping me away from
those tools. Might be soon to those steps, but not today. ;-)
Bookmarks made to revisit this thread when the time comes.
I do look forward to attaining a more complete grasp of the D
space. The hint that Ali passed on about `version` settings not
carrying through to imports helped enough that I'm pretty happy
with the plans for now. They might be wrong headed plans in the
grand scheme, but for now, things are working out. A bunch of
stand alone CLI programs, with a boss that can manage them all,
without need of shelling out a process.
Have good, make well
Re: modules and mains
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.
Re: modules and mains
On Sunday, 22 August 2021 at 04:38:58 UTC, Ali Çehreli wrote: On 8/21/21 8:46 PM, Brian Tiffin wrote: > prompt$ cat B.d > module B; > version = boss; A cannot know about 'version' condition inside B. The solution is to provide version on the command line. This is how I do it with dmd: $ dmd -version=boss [...] (So, remove 'version = boss;' line in B.d) > But I'm getting a link error from gdc > > ``` > prompt$ gdc -o B B.d > /tmp/ccWg1BrF.o: In function `_Dmain': > B.d:(.text+0x52): undefined reference to `_D1A7commandFAAyaZi' > collect2: error: ld returned 1 exit status > ``` > > Is it just wrong thinking and *try again, ya noob*? ;-) Never! :) D modules work both like C's .h files and .c files. (Well, more like C++'s .h files because templates don't need .cpp part.) We import for declarations but we must also include for linking. Again, this is how it works with dmd: $ dmd B.d A.d -version=boss Another option is to use dmd's -i switch, which automatically includes modules for linking but I don't have experience with it other than it works: $ dmd B.d -version=boss -i (-i can take a pattern as well.) Ali Got it working with `gdc`. It makes some sense to list all the modules when compiling Boss, and separately when getting the sub-commands to each define a main, so I may explore this path some more. But I have the memory of a ~~5~~8 year old, so I'll be creating a Makefile as an aid. Was wistfully thinking I might be able to avoid Makefiles with D projects. ```make # Trying gdc with multiple modules .RECIPEPREFIX = > A: A.d gdc-11 -o A A.d B: A.d B.d gdc-11 -fversion=boss B.d A.d ``` which gives ``` prompt$ make A gdc-11 -o A A.d prompt$ make B gdc-11 -fversion=boss B.d A.d ``` and ``` prompt$ ./A one ["./A", "one"] prompt$ ./B ["Boss calling A"] ``` *A gets a car, and B gets a car, everybody gets a car.* This will get more fun as the real sub-commands get built up now. The plan is a support tool for COBOL development. Pump out named source fragments and project setups, keep Time and Task logs, automate Fossil commits, and the like. Each component usable on its own, with the main boss app, hopper. A little backfill, Grace Hopper was the defacto grand-ma of COBOL, one of the first humans to realize that computers could be used to compile "programs" and not just math formulas. She was also known as the oldest serving member in the U.S. Navy at the time she retired as a Rear admiral. As Zach Weinersmith once cartooned in SMBC, "You may not know me, but you should fear me". ;-) Thanks, Ali. Have good, make well
Re: modules and mains
On 8/21/21 8:46 PM, Brian Tiffin wrote: > prompt$ cat B.d > module B; > version = boss; A cannot know about 'version' condition inside B. The solution is to provide version on the command line. This is how I do it with dmd: $ dmd -version=boss [...] (So, remove 'version = boss;' line in B.d) > But I'm getting a link error from gdc > > ``` > prompt$ gdc -o B B.d > /tmp/ccWg1BrF.o: In function `_Dmain': > B.d:(.text+0x52): undefined reference to `_D1A7commandFAAyaZi' > collect2: error: ld returned 1 exit status > ``` > > Is it just wrong thinking and *try again, ya noob*? ;-) Never! :) D modules work both like C's .h files and .c files. (Well, more like C++'s .h files because templates don't need .cpp part.) We import for declarations but we must also include for linking. Again, this is how it works with dmd: $ dmd B.d A.d -version=boss Another option is to use dmd's -i switch, which automatically includes modules for linking but I don't have experience with it other than it works: $ dmd B.d -version=boss -i (-i can take a pattern as well.) Ali
Re: modules and mains
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
Tried this:
```d
prompt$ cat A.d
module A;
version (boss) {} else {
int main(string[] args) {
return command(args);
}
}
int command(string[] args) {
import std.stdio: writeln;
writeln(args);
return 0;
}
```
with
```d
prompt$ cat B.d
module B;
version = boss;
import A;
int main(string[] args) {
A.command(["Boss calling A"]);
return 0;
}
```
But I'm getting a link error from gdc
```
prompt$ gdc -o B B.d
/tmp/ccWg1BrF.o: In function `_Dmain':
B.d:(.text+0x52): undefined reference to `_D1A7commandFAAyaZi'
collect2: error: ld returned 1 exit status
```
Is it just wrong thinking and *try again, ya noob*? ;-)
Cheers again
modules and mains
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
