www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - modules and mains

reply Brian Tiffin <btiffin gnu.org> writes:
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
Aug 21 2021
next sibling parent reply Brian Tiffin <btiffin gnu.org> writes:
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
Aug 21 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Aug 21 2021
parent Brian Tiffin <btiffin gnu.org> writes:
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

.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
Aug 21 2021
prev sibling parent reply Mathias LANG <geod24 gmail.com> writes:
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.
Aug 22 2021
parent Brian Tiffin <btiffin gnu.org> writes:
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
Aug 22 2021