www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Importing modules under DUB on Windows

reply DLearner <bmqazwsx123 gmail.com> writes:
Hi

Never used DUB before.
Wanted to use a function stored in a module outside the main 
source.

Main source has `import <modulename>;`

Put a line into the JSON: `"importPaths": "C:\\Users\\..."` 
pointing to the directory holding the module.

`dub run` failed with `Expected JSON array, got string`.

Please, any ideas?

Best regards
Oct 26 2022
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Oct 26, 2022 at 04:20:01PM +0000, DLearner via Digitalmars-d-learn
wrote:

 Hi
 
 Never used DUB before.
 Wanted to use a function stored in a module outside the main source.
 
 Main source has `import <modulename>;`
 
 Put a line into the JSON: `"importPaths": "C:\\Users\\..."` pointing
 to the directory holding the module.
 
 `dub run` failed with `Expected JSON array, got string`.


Maybe try instead:

	"importPaths": [ "C:\\Users\\..." ]

since the error message indicates that it expects an array, not a
string.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.
Oct 26 2022
parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh wrote:

 On Wed, Oct 26, 2022 at 04:20:01PM +0000, DLearner via 
 Digitalmars-d-learn wrote:

 Hi
 
 Never used DUB before.
 Wanted to use a function stored in a module outside the main 
 source.
 
 Main source has `import <modulename>;`
 
 Put a line into the JSON: `"importPaths": "C:\\Users\\..."` 
 pointing to the directory holding the module.
 
 `dub run` failed with `Expected JSON array, got string`.


 Maybe try instead:

 	"importPaths": [ "C:\\Users\\..." ]

 since the error message indicates that it expects an array, not 
 a string.


 T


Thanks for this.
Following your suggestion, seems that DUB found the module (as it 
got through to the linking step without complaint), but then the 
linker failed to resolve the function name.

However, when I moved the module to the project `'source'` 
directory (and took out the `importPaths` JSON entry), everything 
worked.

But I don't really want to do this - the module is my collection 
of utilities, used in a variety of projects, so doesn't really 
belong within one specific project.

Best regards
Oct 26 2022
parent reply Hipreme <msnmancini hotmail.com> writes:
On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote:

 On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh wrote:

 On Wed, Oct 26, 2022 at 04:20:01PM +0000, DLearner via 
 Digitalmars-d-learn wrote:

 Hi
 
 Never used DUB before.
 Wanted to use a function stored in a module outside the main 
 source.
 
 Main source has `import <modulename>;`
 
 Put a line into the JSON: `"importPaths": "C:\\Users\\..."` 
 pointing to the directory holding the module.
 
 `dub run` failed with `Expected JSON array, got string`.


 Maybe try instead:

 	"importPaths": [ "C:\\Users\\..." ]

 since the error message indicates that it expects an array, 
 not a string.


 T


 Thanks for this.
 Following your suggestion, seems that DUB found the module (as 
 it got through to the linking step without complaint), but then 
 the linker failed to resolve the function name.

 However, when I moved the module to the project `'source'` 
 directory (and took out the `importPaths` JSON entry), 
 everything worked.

 But I don't really want to do this - the module is my 
 collection of utilities, used in a variety of projects, so 
 doesn't really belong within one specific project.

 Best regards


The linker failed to resolve because it didn't include the 
symbols you imported.
Think of import a way to the compiler resolve the compilation.
Think of source a way to both the compiler and the linker to 
resolve compilation and linking.

If you give only the import path, you will need a library.

What you actually want is to put your new importPath to the JSON 
array `sourcePaths`
Oct 26 2022
parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Wednesday, 26 October 2022 at 18:53:58 UTC, Hipreme wrote:

 On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote:

 On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh 
 wrote:

 On Wed, Oct 26, 2022 at 04:20:01PM +0000, DLearner via 
 Digitalmars-d-learn wrote:

 [...]


 Maybe try instead:

 	"importPaths": [ "C:\\Users\\..." ]

 since the error message indicates that it expects an array, 
 not a string.


 T


 Thanks for this.
 Following your suggestion, seems that DUB found the module (as 
 it got through to the linking step without complaint), but 
 then the linker failed to resolve the function name.

 However, when I moved the module to the project `'source'` 
 directory (and took out the `importPaths` JSON entry), 
 everything worked.

 But I don't really want to do this - the module is my 
 collection of utilities, used in a variety of projects, so 
 doesn't really belong within one specific project.

 Best regards


 The linker failed to resolve because it didn't include the 
 symbols you imported.
 Think of import a way to the compiler resolve the compilation.
 Think of source a way to both the compiler and the linker to 
 resolve compilation and linking.

 If you give only the import path, you will need a library.

 What you actually want is to put your new importPath to the 
 JSON array `sourcePaths`


Added `"sourcePaths": [ "C\\Users\\..." ]`
Unfortunately failed with 
`core.exception.AssertError source\dub\internal\vibecompat\inet\path.d(222):
Trying to append absolute path.`

I tried to construct a relative path to the module directory from 
the project directory, that didn't work either.
Oct 26 2022
parent reply Hipreme <msnmancini hotmail.com> writes:
On Wednesday, 26 October 2022 at 22:51:53 UTC, DLearner wrote:

 On Wednesday, 26 October 2022 at 18:53:58 UTC, Hipreme wrote:

 On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote:

 On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh 
 wrote:

 On Wed, Oct 26, 2022 at 04:20:01PM +0000, DLearner via 
 Digitalmars-d-learn wrote:

 [...]


 Maybe try instead:

 	"importPaths": [ "C:\\Users\\..." ]

 since the error message indicates that it expects an array, 
 not a string.


 T


 Thanks for this.
 Following your suggestion, seems that DUB found the module 
 (as it got through to the linking step without complaint), 
 but then the linker failed to resolve the function name.

 However, when I moved the module to the project `'source'` 
 directory (and took out the `importPaths` JSON entry), 
 everything worked.

 But I don't really want to do this - the module is my 
 collection of utilities, used in a variety of projects, so 
 doesn't really belong within one specific project.

 Best regards


 The linker failed to resolve because it didn't include the 
 symbols you imported.
 Think of import a way to the compiler resolve the compilation.
 Think of source a way to both the compiler and the linker to 
 resolve compilation and linking.

 If you give only the import path, you will need a library.

 What you actually want is to put your new importPath to the 
 JSON array `sourcePaths`


 Added `"sourcePaths": [ "C\\Users\\..." ]`
 Unfortunately failed with 
 `core.exception.AssertError source\dub\internal\vibecompat\inet\path.d(222):
Trying to append absolute path.`

 I tried to construct a relative path to the module directory 
 from the project directory, that didn't work either.


Okay. So this error is very strange, the other thing I can give 
you advice is:
If your other thing is another dub project, you can add it as a 
dependency by putting in your dub.json

```json
"dependencies" : {
    "your_project_name" : {"path" : "your/path/here"}
}
```

AFAIK, there is no problem in putting an absolute path 
dependency, in fact, I'm using things from another drive letter.
Oct 26 2022
parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Thursday, 27 October 2022 at 00:35:26 UTC, Hipreme wrote:

 On Wednesday, 26 October 2022 at 22:51:53 UTC, DLearner wrote:

 On Wednesday, 26 October 2022 at 18:53:58 UTC, Hipreme wrote:

 On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote:

 [...]


 The linker failed to resolve because it didn't include the 
 symbols you imported.
 Think of import a way to the compiler resolve the compilation.
 Think of source a way to both the compiler and the linker to 
 resolve compilation and linking.

 If you give only the import path, you will need a library.

 What you actually want is to put your new importPath to the 
 JSON array `sourcePaths`


 Added `"sourcePaths": [ "C\\Users\\..." ]`
 Unfortunately failed with 
 `core.exception.AssertError source\dub\internal\vibecompat\inet\path.d(222):
Trying to append absolute path.`

 I tried to construct a relative path to the module directory 
 from the project directory, that didn't work either.


 Okay. So this error is very strange, the other thing I can give 
 you advice is:
 If your other thing is another dub project, you can add it as a 
 dependency by putting in your dub.json

 ```json
 "dependencies" : {
    "your_project_name" : {"path" : "your/path/here"}
 }
 ```

 AFAIK, there is no problem in putting an absolute path 
 dependency, in fact, I'm using things from another drive letter.


Hi

I'm not getting on with DUB.
Maybe fewer people use it under Windows, so Windows constructs 
don't get exercised so much.

Is there a non-DUB way of arranging that
`import arsd.terminal;`
will use that module as held on GitHub?
(DUB name: "arsd-official:terminal": "~>10.9.4").

OS: Windows 10. Compiler: DMD.

Best regards
Oct 27 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 28/10/2022 5:40 AM, DLearner wrote:

 Maybe fewer people use it under Windows, so Windows constructs don't get 
 exercised so much.


I have actively contributed to dub specifically for Windows in the last 
year :)

There is enough of us.

Also UNC paths (those with drives and then the slash) are actually 
absolute, not relative.

There are relative ones, but the path processing in dub is pretty 
simplified.

You have to stick to completely relative, POSIX style.

https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats

You should be working with relatives paths in respect to the 
$PACKAGE_DIR, not the compiler or any root location of your file system 
(such as the drive would indicate).

https://dub.pm/package-format-json.html#environment-variables
Oct 27 2022
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 27 October 2022 at 16:40:20 UTC, DLearner wrote:


 I'm not getting on with DUB.
 Maybe fewer people use it under Windows, so Windows constructs 
 don't get exercised so much.

 Is there a non-DUB way of arranging that
 `import arsd.terminal;`
 will use that module as held on GitHub?
 (DUB name: "arsd-official:terminal": "~>10.9.4").

 OS: Windows 10. Compiler: DMD.


This has nothing to do with Windows. The source path error you 
encountered is an assertion failure that tells you what's wrong: 
dub does not allow you to add absolute paths to the source path. 
I don't know why. If you disagree, then you can file an issue in 
the dub github repository.

In the meantime, you'll need to work around the limitation. You 
could

1. Add the file to your source tree
2. Use a relative path in `sourcePaths`
2. Add arsd-official as a dub dependency

All of these would solve the problem. If you aren't going to do 
any of these things, then you'll need a fourth option.

The compiler (not dub) needs to know where to find imports, and 
the linker needs an object file to resolve symbols. So you should:

1. Compile /arsd/terminal.d as a static library with ldc (named 
e.g., "arsd-terminal.lib") and output the library to the path 
where you want it (e.g., C:\libs)
2. Add the parent directory of the arsd folder to your 
`importPaths` in dub.
3. Add linker flags to your dub project to tell the compiler 
where to find the library


you're working with, then you can just add the full path to the 
library in an `libs` entry:

```json
"libs": ["C:\\libs\\arsd-terminal"]
```

Note that you do not add the ".lib" extension here. Dub will do 
that for you.

If you have multiple external libs, then it's better to add the 
library path like so:

```json
"lflags": ["/LIBPATH:C:\\libs"],
"libs": ["lib1", "lib2", "lib3"]
```

Note that `/LIBPATH` is specific to the Microsoft linker, which I 
assume LDC uses on Windows:

https://learn.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=msvc-170

If it's using the LLVM linker, then you'll need the appropriate 
flag for that.

If you aren't planning to build on other platforms, then you'll 
want to make these dub directives platform specific, e.g., 
`libs-windows` rather than `libs`.
Oct 27 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 26 October 2022 at 16:20:01 UTC, DLearner wrote:

 Wanted to use a function stored in a module outside the main 
 source.


easiest thing to do with dub is to add it as a sourcePath or a 
sourceFile. Well, actually, easiest is to just copy the module 
right into your default src folder, but second easiest is to add 
the other thing as the sourcePath/sourceFile.

Messing with lib compiles and import paths rarely worth the 
hassle.

(and without dub btw you can make a generic lib directory, add it 
to your -I path, then just `dmd -I/path/to/libs -i 
yourmainfile.d` and it automatically picks up things from import 
paths. that's how i do it myself)


Also later i see you are using the arsd terminal.d, which you can 
also use through dub's dependency system by adding 
`arsd-official:terminal` to its list.
Oct 28 2022
parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Friday, 28 October 2022 at 11:35:44 UTC, Adam D Ruppe wrote:

 On Wednesday, 26 October 2022 at 16:20:01 UTC, DLearner wrote:

 Wanted to use a function stored in a module outside the main 
 source.


 easiest thing to do with dub is to add it as a sourcePath or a 
 sourceFile. Well, actually, easiest is to just copy the module 
 right into your default src folder, but second easiest is to 
 add the other thing as the sourcePath/sourceFile.

 Messing with lib compiles and import paths rarely worth the 
 hassle.

 (and without dub btw you can make a generic lib directory, add 
 it to your -I path, then just `dmd -I/path/to/libs -i 
 yourmainfile.d` and it automatically picks up things from 
 import paths. that's how i do it myself)


 Also later i see you are using the arsd terminal.d, which you 
 can also use through dub's dependency system by adding 
 `arsd-official:terminal` to its list.


Hi

To avoid confusion:

I wanted to use (yours I think!) arsd-official:terminal, and a 
(near-trivial) function (call it NTF) held inside one of my own 
modules (call it OM), itself inside my utilities directory (call 
it UD).
`
	"dependencies": {
		"arsd-official:terminal": "~>10.9.4"
	},
`
was set in the JSON file.
When I copied OM to the package 'source' directory, `dub run` 
executed, nothing blew up, and the whole thing went as expected.

However, going forward, I don't want copies of OM anywhere other 
than UD.
Doing that potentially leaves similar but non-identical copies of 
software around, causing problems at a later stage.

So I delected OM from the 'source' directory, and (following 
suggestions given earlier) reviewed my calculation of the 
_relative_ path from the package directory to UD, and put the 
result into `sourcePaths`.
`dub run` then seemed to find OM and the NTF inside it, as got 
through compile to:
`Target is a library. Skipping execution.`

Google then gave the suggestion:
`"targetType": "executable",`

Took suggestion, dub run then produced:
`Linking...
lld-link: error: subsystem must be defined
Error: linker exited with status 1`

Any further suggestions gratefully received.

Comments:
I am conscious that when OM was in the 'source' directory (with 
app), everything 'just worked'.
Therefore, to me, if OM is somewhere else, but I provide that 
location to dub, everything should work exactly as before.
But that does not happen.
I also thought it strange that I had to provide the UD location 
as a relative rather than absolute path.

Best regards
Oct 28 2022
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 28 October 2022 at 15:15:04 UTC, DLearner wrote:

 Took suggestion, dub run then produced:
 `Linking...
 lld-link: error: subsystem must be defined
 Error: linker exited with status 1`


That means the linker didn't see a `main` function. Make sure you 
have a `void main() {}` somewhere (and of course if you want the 
application to do something, make main do something)
Oct 28 2022
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 29/10/2022 4:15 AM, DLearner wrote:

 However, going forward, I don't want copies of OM anywhere other than UD.


If you want your own private library on your system (that will get used 
a lot), you can create a package and use ``$ dub add-local .`` to add it 
to the available packages for lookup, without needing a version control 
system.

Then you just add it as a dependency on an as needed basis (use ``*`` 
for version should work fine).
Oct 28 2022
parent DLearner <bmqazwsx123 gmail.com> writes:
On Friday, 28 October 2022 at 21:32:46 UTC, rikki cattermole 
wrote:

 On 29/10/2022 4:15 AM, DLearner wrote:

 However, going forward, I don't want copies of OM anywhere 
 other than UD.


 If you want your own private library on your system (that will 
 get used a lot), you can create a package and use ``$ dub 
 add-local .`` to add it to the available packages for lookup, 
 without needing a version control system.

 Then you just add it as a dependency on an as needed basis (use 
 ``*`` for version should work fine).


In the end, downloaded terminal.d from GitHub, stored in 
directory UD.
Then within 'source' directory, following Adam D Ruppe above,
`dmd -i -IC:\...\UD\ -run app`

And it just worked.

No calculating relative paths, no remembering to double `\`.

I think DUB is a little too sophisticated for my needs.
Oct 28 2022