Re: DUB error I can't make sense of
On Saturday, 16 March 2024 at 07:27:17 UTC, Richard (Rikki) Andrew Cattermole wrote: Do you? ``module nxt.algorithm.comparsion;`` comparsion doesn't look much like comparison to me ;) I know. I'm crushed. Am I getting dislyctic? ;)
Re: DUB error I can't make sense of
On Saturday, 16 March 2024 at 07:23:09 UTC, Per Nordlöw wrote: Do you? Fixed it. There was some invisible character that confused the compiler.
Re: DUB error I can't make sense of
On 16/03/2024 8:23 PM, Per Nordlöw wrote: https://github.com/nordlow/phobos-next/releases/tag/v0.6.10 fails to build as ``` ../../.dub/cache/phobos-next/0.6.10/code/phobos-next-test-library-unittest-nyN4MEoglVgAJ1A9GyL6uA/dub_test_root.d(11,15): Error: module `nxt.algorithm.comparsion` from file src/nxt/algorithm/comparison.d must be imported with 'import nxt.algorithm.comparsion;' ``` and I have no clue how to fix it. Do you? ``module nxt.algorithm.comparsion;`` comparsion doesn't look much like comparison to me ;)
DUB error I can't make sense of
https://github.com/nordlow/phobos-next/releases/tag/v0.6.10 fails to build as ``` ../../.dub/cache/phobos-next/0.6.10/code/phobos-next-test-library-unittest-nyN4MEoglVgAJ1A9GyL6uA/dub_test_root.d(11,15): Error: module `nxt.algorithm.comparsion` from file src/nxt/algorithm/comparison.d must be imported with 'import nxt.algorithm.comparsion;' ``` and I have no clue how to fix it. Do you?
Re: DUB "Error: only one `main` allowed."
On Wednesday, 11 August 2021 at 11:44:42 UTC, Steven Schveighoffer wrote: On 8/11/21 5:31 AM, tastyminerals wrote: [...] `dub -b unittest` should work (you don't need the extra build type stuff) dub test does something funky -- it removes the *whole module* where your main function is (if you identify it, or if it's `app.d`) and then builds its own main module. Why does it do this? Legacy reasons, the runtime used to run main after running unittests, which dub didn't want to do. It also is useful on a library where there is no main function. However, dub with a build type of `unittest` just enables the unittest switch, and builds all your stuff as normal. -Steve I see. Thank you for a detailed answer! I just with this was somehow reflected in the DUB docs...
Re: DUB "Error: only one `main` allowed."
On 8/11/21 5:31 AM, tastyminerals wrote:
I would like to trigger tests in a simple dub project.
```
source/my_script.d
dub.json
```
Here is a dub config:
```json
{
"targetPath": "build",
"targetType": "executable",
"sourcePaths": ["source"],
"name": "my_script",
"buildTypes": {
"release": {
"buildOptions": [
"releaseMode",
"inline",
"optimize"
]
},
"tests": {
"buildOptions": [
"unittests"
]
}
}
}
```
The project builds but when I attempt to run `dub test`, I get
```
.dub/code/my_script-test-application-unittest-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.26.0-8A5B544D5AC6B47B68DE875ACB4BA60E_dub_test_root.d(9,12):
Error: only one `main` allowed. Previously found `main` at
source/my_script.d(131,6)
```
How can one run tests with dub?
`dub -b unittest` should work (you don't need the extra build type stuff)
dub test does something funky -- it removes the *whole module* where
your main function is (if you identify it, or if it's `app.d`) and then
builds its own main module. Why does it do this? Legacy reasons, the
runtime used to run main after running unittests, which dub didn't want
to do. It also is useful on a library where there is no main function.
However, dub with a build type of `unittest` just enables the unittest
switch, and builds all your stuff as normal.
-Steve
Re: DUB "Error: only one `main` allowed."
On Wednesday, 11 August 2021 at 09:38:13 UTC, tastyminerals wrote: Hahaha, I fixed it by renaming the `my_script.d` to `app.d`. Oh boy. What you want is the `mainSourceFile` entry. From the dub documentation, [under "Build Settings"][1]: Determines the file that contains the main() function. This setting can be used by dub to exclude this file in situations where a different main function is defined (e.g. for "dub test") - this setting does not support platform suffixes `app.d` has special significance to dub in that it automatically triggers the executable target type if it's present. I assume dub also considers it the main source file by default if you have one. [1]: https://dub.pm/package-format-json.html#build-settings
Re: DUB "Error: only one `main` allowed."
On Wednesday, 11 August 2021 at 09:31:46 UTC, tastyminerals wrote:
I would like to trigger tests in a simple dub project.
```
source/my_script.d
dub.json
```
Here is a dub config:
```json
{
"targetPath": "build",
"targetType": "executable",
"sourcePaths": ["source"],
"name": "my_script",
"buildTypes": {
"release": {
"buildOptions": [
"releaseMode",
"inline",
"optimize"
]
},
"tests": {
"buildOptions": [
"unittests"
]
}
}
}
```
The project builds but when I attempt to run `dub test`, I get
```
.dub/code/my_script-test-application-unittest-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.26.0-8A5B544D5AC6B47B68DE875ACB4BA60E_dub_test_root.d(9,12):
Error: only one `main` allowed. Previously found `main` at
source/my_script.d(131,6)
```
How can one run tests with dub?
Hahaha, I fixed it by renaming the `my_script.d` to `app.d`. Oh
boy.
DUB "Error: only one `main` allowed."
I would like to trigger tests in a simple dub project.
```
source/my_script.d
dub.json
```
Here is a dub config:
```json
{
"targetPath": "build",
"targetType": "executable",
"sourcePaths": ["source"],
"name": "my_script",
"buildTypes": {
"release": {
"buildOptions": [
"releaseMode",
"inline",
"optimize"
]
},
"tests": {
"buildOptions": [
"unittests"
]
}
}
}
```
The project builds but when I attempt to run `dub test`, I get
```
.dub/code/my_script-test-application-unittest-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.26.0-8A5B544D5AC6B47B68DE875ACB4BA60E_dub_test_root.d(9,12):
Error: only one `main` allowed. Previously found `main` at
source/my_script.d(131,6)
```
How can one run tests with dub?
Re: DUB "Error: only one `main` allowed."
On Wednesday, 11 August 2021 at 09:31:46 UTC, tastyminerals wrote:
I would like to trigger tests in a simple dub project.
```
source/my_script.d
dub.json
```
Here is a dub config:
```json
{
"targetPath": "build",
"targetType": "executable",
"sourcePaths": ["source"],
"name": "my_script",
"buildTypes": {
"release": {
"buildOptions": [
"releaseMode",
"inline",
"optimize"
]
},
"tests": {
"buildOptions": [
"unittests"
]
}
}
}
```
The project builds but when I attempt to run `dub test`, I get
```
.dub/code/my_script-test-application-unittest-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.26.0-8A5B544D5AC6B47B68DE875ACB4BA60E_dub_test_root.d(9,12):
Error: only one `main` allowed. Previously found `main` at
source/my_script.d(131,6)
```
How can one run tests with dub?
On a side note, can somebody advise a less buggy build tool for
D? Does meson work any better?
Re: DUB Error with packcage dformlib
For some weird reason , https://code.dlang.org Has lots of packages without maintainer ... Git repositories which are put read-only ... I.e. no "Issues"
Re: DUB Error with packcage dformlib
On Sunday, 18 April 2021 at 07:31:12 UTC, Imperatorn wrote: On Sunday, 18 April 2021 at 01:37:14 UTC, Marcone wrote: I have this message when try build dub. How solve it? Unresolvable dependencies to package dformlib app ~master depends on dformlib ~0.2.2> Just a comment, dforms is millions of years old. It would be nice to see support for it again, but I would probably choose another framework. Really. But in D everything is old and obsolete.
Re: DUB Error with packcage dformlib
On Sunday, 18 April 2021 at 01:37:14 UTC, Marcone wrote: I have this message when try build dub. How solve it? Unresolvable dependencies to package dformlib app ~master depends on dformlib ~0.2.2> Just a comment, dforms is millions of years old. It would be nice to see support for it again, but I would probably choose another framework.
Re: DUB Error with packcage dformlib
It might be a dead monkey. You could try: https://github.com/o3o/dguihub
DUB Error with packcage dformlib
I have this message when try build dub. How solve it? Unresolvable dependencies to package dformlib app ~master depends on dformlib ~0.2.2>
Re: help: cannot build profdump, dub error (bug): Enforcement failed
On 9/29/20 4:38 PM, drug wrote: It reproduces. As a workaround you can use ``` dub run profdump ``` this command works as expected, I guess it is a bug of dub Do not execute this command in cloned `profdump` repository - it will fail too. It works if is called from other places, for example in home.
Re: help: cannot build profdump, dub error (bug): Enforcement failed
On 9/29/20 3:41 PM, mw wrote: I remember I used to able to build this package: https://github.com/AntonMeep/profdump but now, I cannot. Since that package haven't changed for 2 years, maybe it's a dub bug? System information $ uname -a Linux 4.15.0-117-generic #118-Ubuntu SMP Fri Sep 4 20:02:41 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ /usr/bin/dub --version DUB version 1.23.0, built on Sep 27 2020 $ /usr/bin/dmd --version DMD64 D Compiler v2.094.0 Copyright (C) 1999-2020 by The D Language Foundation, All Rights Reserved written by Walter Bright $ /usr/bin/dub build -v Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json ... ... No valid package found in current working directory: Enforcement failed Enforcement failed Bug Description Enforcement failed How to reproduce? ``` git clone https://github.com/AntonMeep/profdump cd profdump dub build ``` https://github.com/dlang/dub/issues/2017 It reproduces. As a workaround you can use ``` dub run profdump ``` this command works as expected, I guess it is a bug of dub
help: cannot build profdump, dub error (bug): Enforcement failed
I remember I used to able to build this package: https://github.com/AntonMeep/profdump but now, I cannot. Since that package haven't changed for 2 years, maybe it's a dub bug? System information $ uname -a Linux 4.15.0-117-generic #118-Ubuntu SMP Fri Sep 4 20:02:41 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ /usr/bin/dub --version DUB version 1.23.0, built on Sep 27 2020 $ /usr/bin/dmd --version DMD64 D Compiler v2.094.0 Copyright (C) 1999-2020 by The D Language Foundation, All Rights Reserved written by Walter Bright $ /usr/bin/dub build -v Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json ... ... No valid package found in current working directory: Enforcement failed Enforcement failed Bug Description Enforcement failed How to reproduce? ``` git clone https://github.com/AntonMeep/profdump cd profdump dub build ``` https://github.com/dlang/dub/issues/2017
Re: Dub Error Message "Invalid variable: DUB"
On Monday, 8 June 2020 at 18:38:17 UTC, Paul Backus wrote: On Monday, 8 June 2020 at 17:55:24 UTC, Andre Pany wrote: I had a second look on the descriptions and from a non native speaker view it sounds correct. But you are right from a native speaker view the wording might be incorrect. If you have time, could you check the wording and make a proposal? https://github.com/dlang/dub-docs/blob/master/views/inc.package_format.envvars.dt Kind regards Andre https://github.com/dlang/dub-docs/pull/26 Thanks a lot. Kind regards Andre
Re: Dub Error Message "Invalid variable: DUB"
On Monday, 8 June 2020 at 17:55:24 UTC, Andre Pany wrote: I had a second look on the descriptions and from a non native speaker view it sounds correct. But you are right from a native speaker view the wording might be incorrect. If you have time, could you check the wording and make a proposal? https://github.com/dlang/dub-docs/blob/master/views/inc.package_format.envvars.dt Kind regards Andre https://github.com/dlang/dub-docs/pull/26
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 16:54:48 UTC, Paul Backus wrote: On Sunday, 7 June 2020 at 16:26:17 UTC, Andre Pany wrote: On Sunday, 7 June 2020 at 15:37:27 UTC, Paul Backus wrote: On Sunday, 7 June 2020 at 12:52:12 UTC, Andre Pany wrote: I am not sure but $DUB is a variable which could be used in dub descriptor file but it isn't an environment variable. $DUB_EXE is an environment variable. Kind regards Andre If what you say is true, the Dub documentation needs to be updated: https://dub.pm/package-format-json.html#environment-variables Each of the table has an explanation section were they can be used. $DUB can only be used within the dub descriptor but not within scripts called from the hooks. From the hooks you can use these environment variables: https://github.com/andre2007/dub/blob/376ff5854dcd7bbc6116f72001c8c6d13eb3cbf0/source/dub/generators/generator.d#L763 Kind regards Andre The documentations says: Inside of custom commands directives a number of additional variables is available: ...and then lists the variables from the function you linked to. "Additional" implies that they are not the only variables that can be used in hooks, and that the variables listed previously (such as $DUB) can also be used. If this is not the case, then the documentation is inaccurate and should be updated. I would also add: if you feel the need to link to the source code to explain to use a feature, rather than referring to the documentation, that is a good sign that the documentation is inadequate. I had a second look on the descriptions and from a non native speaker view it sounds correct. But you are right from a native speaker view the wording might be incorrect. If you have time, could you check the wording and make a proposal? https://github.com/dlang/dub-docs/blob/master/views/inc.package_format.envvars.dt Kind regards Andre
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 16:26:17 UTC, Andre Pany wrote: On Sunday, 7 June 2020 at 15:37:27 UTC, Paul Backus wrote: On Sunday, 7 June 2020 at 12:52:12 UTC, Andre Pany wrote: I am not sure but $DUB is a variable which could be used in dub descriptor file but it isn't an environment variable. $DUB_EXE is an environment variable. Kind regards Andre If what you say is true, the Dub documentation needs to be updated: https://dub.pm/package-format-json.html#environment-variables Each of the table has an explanation section were they can be used. $DUB can only be used within the dub descriptor but not within scripts called from the hooks. From the hooks you can use these environment variables: https://github.com/andre2007/dub/blob/376ff5854dcd7bbc6116f72001c8c6d13eb3cbf0/source/dub/generators/generator.d#L763 Kind regards Andre The documentations says: Inside of custom commands directives a number of additional variables is available: ...and then lists the variables from the function you linked to. "Additional" implies that they are not the only variables that can be used in hooks, and that the variables listed previously (such as $DUB) can also be used. If this is not the case, then the documentation is inaccurate and should be updated. I would also add: if you feel the need to link to the source code to explain to use a feature, rather than referring to the documentation, that is a good sign that the documentation is inadequate.
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 15:37:27 UTC, Paul Backus wrote: On Sunday, 7 June 2020 at 12:52:12 UTC, Andre Pany wrote: I am not sure but $DUB is a variable which could be used in dub descriptor file but it isn't an environment variable. $DUB_EXE is an environment variable. Kind regards Andre If what you say is true, the Dub documentation needs to be updated: https://dub.pm/package-format-json.html#environment-variables Each of the table has an explanation section were they can be used. $DUB can only be used within the dub descriptor but not within scripts called from the hooks. From the hooks you can use these environment variables: https://github.com/andre2007/dub/blob/376ff5854dcd7bbc6116f72001c8c6d13eb3cbf0/source/dub/generators/generator.d#L763 Kind regards Andre
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 12:52:12 UTC, Andre Pany wrote: I am not sure but $DUB is a variable which could be used in dub descriptor file but it isn't an environment variable. $DUB_EXE is an environment variable. Kind regards Andre If what you say is true, the Dub documentation needs to be updated: https://dub.pm/package-format-json.html#environment-variables
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 12:24:13 UTC, Russel Winder wrote: On Sun, 2020-06-07 at 10:30 +, Basile B. via Digitalmars-d-learn wrote: […] What is the docker image that you use ? If it is an older version maybe that the $DUB env variable is not yet supported by the dub version that's installed (it exists since 2.084.0 according to [1]). I am using ubuntu:focal. ubuntu:bionic has ldc 1.8 which is far too old. Focal has ldc 1.20. I think the dub version is 1.19. I am having to manually symbolically link /usr/bin/gcc and /usr/bin/cc so I suspect the installation of focal is not going quite right. Especially as I have to manually set a TZ variable to avoid a lock up. In my .gitalab-ci.yml I use 'dlang2/ldc-ubuntu' [2] or 'dlang2/dmd-ubuntu' [3] which give always recent versions of D. [1] https://dlang.org/changelog/2.084.0.html [2] https://hub.docker.com/r/dlang2/ldc-ubuntu [3] https://hub.docker.com/r/dlang2/dmd-ubuntu I shall have to investigate these docker images in favour of working with a bare Ubuntu. Yes because that works reasonably well on gitlab. The only problem is that you might have to setup other things as their ubuntu image is very light. Software like zip or even git are not there by default. A simple example of `.gitlab-ci.yml` file to support D is --- job: image: dlang2/dmd-ubuntu before_script: # tools that are not in their base ubuntu image - apt-get update -y - apt-get install -y supplemental_package_x - apt-get install -y supplemental_package_y # similarly to what's done on most of the other CI services script: - bash some_script.sh - dub build - dub test # - etc. ---
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 10:06:14 UTC, Russel Winder wrote: On Sun, 2020-06-07 at 10:24 +0100, Russel Winder wrote: Hi, Why on earth is Dub sending out this error message (Invalid variable: DUB) on GitLab but not on Travis-CI or locally? OK, that was slightly rhetorical, more reasonably, why is dub sending out this message at all? I am assuming that the error comes from the line: preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main -- -f generated/ut_dub_main.d -d $DUB" in the unittest configuration as suggested for using unit-threaded. The question is why does the symbol DUB not need to be defined locally or on Travis-CI, but only on GitLab? |> printenv | grep -i dub |> On Travis-CI and locally Dub find where it is, why does it not do this on GitLab? It is at /usr/bin/dub in all cases. $DUB is a variable but not an environment variable. This is also the background why the environment variable $DC needs to be escaped here. Kind regards Andre
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 11:21:03 UTC, Jacob Carlborg wrote: On 2020-06-07 11:24, Russel Winder wrote: Hi, Why on earth is Dub sending out this error message (Invalid variable: DUB) on GitLab but not on Travis-CI or locally? OK, that was slightly rhetorical, more reasonably, why is dub sending out this message at all? Dub is supposed to make an environment variable named "DUB" available to the build script. It should contain the path to the Dub executable. I guess that somehow fails. Might be some unexpected character in the path? I am not sure but $DUB is a variable which could be used in dub descriptor file but it isn't an environment variable. $DUB_EXE is an environment variable. Kind regards Andre
Re: Dub Error Message "Invalid variable: DUB"
On Sun, 2020-06-07 at 13:21 +0200, Jacob Carlborg via Digitalmars-d-learn wrote: > On 2020-06-07 11:24, Russel Winder wrote: > > Hi, > > > > Why on earth is Dub sending out this error message (Invalid variable: DUB) > > on > > GitLab but not on Travis-CI or locally? > > > > OK, that was slightly rhetorical, more reasonably, why is dub sending out > > this > > message at all? > > Dub is supposed to make an environment variable named "DUB" available to > the build script. It should contain the path to the Dub executable. I > guess that somehow fails. Might be some unexpected character in the path? I guess dub 1.19 is just too old. I have to manually set "export DUB=/usr/bin/dub". -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Dub Error Message "Invalid variable: DUB"
On Sun, 2020-06-07 at 10:30 +, Basile B. via Digitalmars-d-learn wrote: […] > What is the docker image that you use ? If it is an older > version maybe that the $DUB env variable is not yet supported by > the dub version that's installed (it exists since 2.084.0 > according to [1]). I am using ubuntu:focal. ubuntu:bionic has ldc 1.8 which is far too old. Focal has ldc 1.20. I think the dub version is 1.19. I am having to manually symbolically link /usr/bin/gcc and /usr/bin/cc so I suspect the installation of focal is not going quite right. Especially as I have to manually set a TZ variable to avoid a lock up. > In my .gitalab-ci.yml I use 'dlang2/ldc-ubuntu' [2] or > 'dlang2/dmd-ubuntu' [3] which give always recent versions of D. > > [1] https://dlang.org/changelog/2.084.0.html > [2] https://hub.docker.com/r/dlang2/ldc-ubuntu > [3] https://hub.docker.com/r/dlang2/dmd-ubuntu I shall have to investigate these docker images in favour of working with a bare Ubuntu. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Dub Error Message "Invalid variable: DUB"
On 2020-06-07 11:24, Russel Winder wrote: Hi, Why on earth is Dub sending out this error message (Invalid variable: DUB) on GitLab but not on Travis-CI or locally? OK, that was slightly rhetorical, more reasonably, why is dub sending out this message at all? Dub is supposed to make an environment variable named "DUB" available to the build script. It should contain the path to the Dub executable. I guess that somehow fails. Might be some unexpected character in the path? -- /Jacob Carlborg
Re: Dub Error Message "Invalid variable: DUB"
On Sunday, 7 June 2020 at 10:06:14 UTC, Russel Winder wrote: On Sun, 2020-06-07 at 10:24 +0100, Russel Winder wrote: Hi, Why on earth is Dub sending out this error message (Invalid variable: DUB) on GitLab but not on Travis-CI or locally? OK, that was slightly rhetorical, more reasonably, why is dub sending out this message at all? I am assuming that the error comes from the line: preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main -- -f generated/ut_dub_main.d -d $DUB" in the unittest configuration as suggested for using unit-threaded. The question is why does the symbol DUB not need to be defined locally or on Travis-CI, but only on GitLab? |> printenv | grep -i dub |> On Travis-CI and locally Dub find where it is, why does it not do this on GitLab? It is at /usr/bin/dub in all cases. What is the docker image that you use ? If it is an older version maybe that the $DUB env variable is not yet supported by the dub version that's installed (it exists since 2.084.0 according to [1]). In my .gitalab-ci.yml I use 'dlang2/ldc-ubuntu' [2] or 'dlang2/dmd-ubuntu' [3] which give always recent versions of D. [1] https://dlang.org/changelog/2.084.0.html [2] https://hub.docker.com/r/dlang2/ldc-ubuntu [3] https://hub.docker.com/r/dlang2/dmd-ubuntu
Re: Dub Error Message "Invalid variable: DUB"
On Sun, 2020-06-07 at 10:24 +0100, Russel Winder wrote: > Hi, > > Why on earth is Dub sending out this error message (Invalid variable: DUB) > on > GitLab but not on Travis-CI or locally? > > OK, that was slightly rhetorical, more reasonably, why is dub sending out > this > message at all? I am assuming that the error comes from the line: preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main -- -f generated/ut_dub_main.d -d $DUB" in the unittest configuration as suggested for using unit-threaded. The question is why does the symbol DUB not need to be defined locally or on Travis-CI, but only on GitLab? |> printenv | grep -i dub |> On Travis-CI and locally Dub find where it is, why does it not do this on GitLab? It is at /usr/bin/dub in all cases. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Dub Error Message "Invalid variable: DUB"
Hi, Why on earth is Dub sending out this error message (Invalid variable: DUB) on GitLab but not on Travis-CI or locally? OK, that was slightly rhetorical, more reasonably, why is dub sending out this message at all? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [dub] Error: module `main` from file source\main.d is specified twice on the command line
On Saturday, 23 June 2018 at 08:10:08 UTC, Jacob Carlborg wrote: On 2018-06-22 21:41, Anonymouse wrote: What can I do? It might be this issue [1], should be fixed in the latest version of Dub. [1] https://github.com/dlang/dub/issues/1454 Thanks.
Re: [dub] Error: module `main` from file source\main.d is specified twice on the command line
On 2018-06-22 21:41, Anonymouse wrote: I'm trying to set up AppVeyor to build and test my project. After some dancing to get a 64-bit dmd.exe in there (which should really be included in the 7z in 2018) everything seems like it should work, but compiling with dub build fails. dub test works but claims that it's excluding main.d twice. Everything just works locally. appveyor.yml: https://github.com/zorael/kameloso/blob/b278468eb69f221c0db6b96274cec2b0fd25612f/appveyor.yml#L92 dub.json: https://github.com/zorael/kameloso/blob/b278468eb69f221c0db6b96274cec2b0fd25612f/dub.json#L8 Slightly summarized: $ dub test -c cygwin # ...excluded main.d twice but worked $ dub build -c cygwin Performing "debug" build using dmd for x86_64. requests 0.7.4: building configuration "std"... kameloso 1.0.0-rc.1+commit.322.gb278468e: building configuration "cygwin"... Error: module `kameloso.main` from file source\kameloso\main.d is specified twice on the command line dmd failed with exit code 1. Job log: https://ci.appveyor.com/project/zorael/kameloso/build/job/kd6lqu2kxg4vxqmv dub.json does have a mainSourceFile entry, so I thought to remove that, but if I do it breaks dub test with "only one `main` allowed". $ dub test -c vanilla Executable configuration "vanilla" of package kameloso defines no main source file, this may cause certain build modes to fail. Add an explicit "mainSourceFile" to the package description to fix this. Generating test runner configuration 'kameloso-test-vanilla' for 'vanilla' (executable). Excluding package.d file from test due to https://issues.dlang.org/show_bug.cgi?id=11847 Performing "unittest" build using dmd for x86_64. kameloso 1.0.0-rc.1+commit.316.gc9216fa3: building configuration "kameloso-test-vanilla"... source\kameloso\main.d(744,6): Error: only one `main`, `WinMain`, or `DllMain` allowed. Previously found `main` at C:\Users\appveyor\AppData\Local\Temp\1\dub_test_root-5d1d92fa-e527-43b0-a181-184253ffcc9d.d(45,12) dmd failed with exit code 1. Job log: https://ci.appveyor.com/project/zorael/kameloso/build/1.0.0-rc.2.143/job/8tox3hym32leik7u What can I do? It might be this issue [1], should be fixed in the latest version of Dub. [1] https://github.com/dlang/dub/issues/1454 -- /Jacob Carlborg
[dub] Error: module `main` from file source\main.d is specified twice on the command line
I'm trying to set up AppVeyor to build and test my project. After some dancing to get a 64-bit dmd.exe in there (which should really be included in the 7z in 2018) everything seems like it should work, but compiling with dub build fails. dub test works but claims that it's excluding main.d twice. Everything just works locally. appveyor.yml: https://github.com/zorael/kameloso/blob/b278468eb69f221c0db6b96274cec2b0fd25612f/appveyor.yml#L92 dub.json: https://github.com/zorael/kameloso/blob/b278468eb69f221c0db6b96274cec2b0fd25612f/dub.json#L8 Slightly summarized: $ dub test -c cygwin # ...excluded main.d twice but worked $ dub build -c cygwin Performing "debug" build using dmd for x86_64. requests 0.7.4: building configuration "std"... kameloso 1.0.0-rc.1+commit.322.gb278468e: building configuration "cygwin"... Error: module `kameloso.main` from file source\kameloso\main.d is specified twice on the command line dmd failed with exit code 1. Job log: https://ci.appveyor.com/project/zorael/kameloso/build/job/kd6lqu2kxg4vxqmv dub.json does have a mainSourceFile entry, so I thought to remove that, but if I do it breaks dub test with "only one `main` allowed". $ dub test -c vanilla Executable configuration "vanilla" of package kameloso defines no main source file, this may cause certain build modes to fail. Add an explicit "mainSourceFile" to the package description to fix this. Generating test runner configuration 'kameloso-test-vanilla' for 'vanilla' (executable). Excluding package.d file from test due to https://issues.dlang.org/show_bug.cgi?id=11847 Performing "unittest" build using dmd for x86_64. kameloso 1.0.0-rc.1+commit.316.gc9216fa3: building configuration "kameloso-test-vanilla"... source\kameloso\main.d(744,6): Error: only one `main`, `WinMain`, or `DllMain` allowed. Previously found `main` at C:\Users\appveyor\AppData\Local\Temp\1\dub_test_root-5d1d92fa-e527-43b0-a181-184253ffcc9d.d(45,12) dmd failed with exit code 1. Job log: https://ci.appveyor.com/project/zorael/kameloso/build/1.0.0-rc.2.143/job/8tox3hym32leik7u What can I do?
Re: DUB Error
Am 26.02.2014 08:00, schrieb Steve Teale:
On Wednesday, 26 February 2014 at 03:33:38 UTC, Jesse Phillips wrote:
On Tuesday, 25 February 2014 at 14:32:42 UTC, Steve Teale wrote:
What does the somewhat cryptic DUB error
Trying to append absolute path.
mean.
By a process of elimination, the offending line in the json file is
importPaths: [/usr/local/include/d/gtkd-2]
Steve
The path you have provide is an absolute path, I suspect that
somewhere in the code it is doing something like:
buildPath(curDir, importPath);
However, buildPath doesn't have a check for appending absolute path,
so probably a custom path library which is basically saying your
ignoring the working directory.
I guess I was misunderstanding 'importPaths'. I got a little further
along when I used
dflags: [/usr/local/include/d/gtkd-2]
instead.
But you'd think that since it is targeting D, importFlags might have
that purpose.
Steve
I'll check what goes wrong. Usually all places where paths are handled
do if (!path.absolute) path = package_path ~ path; and thus
*shouldn't* produce such errors. However, dflags: [-I/user/lo...]
(with -I) ought to work, too, even if it will produce a warning that
recommends to use importPaths instead, to stay compatible with all D
compilers.
In this particular case I'd recommend to add dependencies: {gtk-d:
~master} to use the DUB package for GTK instead (but please ignore me
here if that's actually a completely different library).
DUB Error
What does the somewhat cryptic DUB error Trying to append absolute path. mean. By a process of elimination, the offending line in the json file is importPaths: [/usr/local/include/d/gtkd-2] Steve
Re: DUB Error
On Tuesday, 25 February 2014 at 14:32:42 UTC, Steve Teale wrote: What does the somewhat cryptic DUB error Trying to append absolute path. mean. By a process of elimination, the offending line in the json file is importPaths: [/usr/local/include/d/gtkd-2] Steve The path you have provide is an absolute path, I suspect that somewhere in the code it is doing something like: buildPath(curDir, importPath); However, buildPath doesn't have a check for appending absolute path, so probably a custom path library which is basically saying your ignoring the working directory.
Re: DUB Error
On Wednesday, 26 February 2014 at 03:33:38 UTC, Jesse Phillips wrote: On Tuesday, 25 February 2014 at 14:32:42 UTC, Steve Teale wrote: What does the somewhat cryptic DUB error Trying to append absolute path. mean. By a process of elimination, the offending line in the json file is importPaths: [/usr/local/include/d/gtkd-2] Steve The path you have provide is an absolute path, I suspect that somewhere in the code it is doing something like: buildPath(curDir, importPath); However, buildPath doesn't have a check for appending absolute path, so probably a custom path library which is basically saying your ignoring the working directory. I guess I was misunderstanding 'importPaths'. I got a little further along when I used dflags: [/usr/local/include/d/gtkd-2] instead. But you'd think that since it is targeting D, importFlags might have that purpose. Steve
