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

On Sunday, 22 August 2021 at 03:22:02 UTC, Brian Tiffin wrote:

Tried this:

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

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

On Sunday, 22 August 2021 at 04:38:58 UTC, Ali Çehreli wrote:

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

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 58 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.

# 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

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.

On Sunday, 22 August 2021 at 10:24:13 UTC, Mathias LANG wrote:

+ $(pwd)
+ - dub.json
+ - source/
+ - source/appname/
+ - source/appname/prog1.d
+ - source/appname/prog2.d
+ - source/appname/common.d

{
  "name": "swissarmyknife",
  "targetType": "executable",

  "configurations": [
    {
      "name": "prog1",
      "targetName": "prog1",
      "mainSourceFile": "source/appname/prog1.d"
    },
    {
      "name": "prog2",
      "targetName": "prog2",
      "mainSourceFile": "source/appname/prog2.d"
    }
}

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