Repository navigation
Configuration "unittest" leads to error "only one main... allowed" #1270
Description
I use configuration "unittest" to add a dependency to a unittest framework. But there is some strange behavior which an unexperienced developer cannot understand.
Execute command: dub init bug1
Add configurations to dub.json
"configurations": [
{
"name": "debug"
},
{
"name": "unittest"
}
]
Issue 1: Although the package contains an app.d file, running command "dub test" will detect the targetType "library". Target type library will add itself a void main method which will now lead to error:
Generating test runner configuration 'bug1-test-unittest' for 'unittest' (library).
...
source\app.d(3,6): Error: only one main/WinMain/DllMain allowed. Previously found main at ..\..\AppData\Local\Temp\dub_test_root-4ddc4093-e161-491c-b61b-b8f1c8b719fd.d(9,12)
There is no information, that the second main method was generated by dub. Although why is target type "library" detected?
Issue 2:: Attribute mainSourceFile is quite hard to understand. By adding this attribute, app.d is excluded from the compilation (...Excluding main source file source/app.d from test...)
{
"name": "unittest",
"mainSourceFile": "source/app.d"
}
What is hard to understand is following: If I now also add attribute "targetType = executable" then mainSourceFile attribute is ignored and app.d isn't excluded anymore.
If this behavior is the expected / designed behavior, could you please add some sentences on the documentation (https://code.dlang.org/package-format?lang=json) explaining the mechanics:
unittest > library -> auto generated main -> mainSourceFile -> targetType Executable
Activity
Timoses commentedon Dec 20, 2018
This is quite annoying if all one wants to do is to e.g. simply start a script before/after building a unittest. Adding the "unittest" configuration somehow breaks the "normal" unittest behaviour. See below example.
Minimal example
source/app.d:dub.sdl:Output of
dub test --verbose(succeeds):Now let's break it
Change
dub.sdlto:Output of
dub test --verbose(fails):In the working case the output shows
whereas that is not shown in the non-working output.
The behaviour feels very opaque. Apparently, specifying the unittest configuration overwrites the behaviour.
One could specify in
dub.sdl:However, that still fails with "only one main allowed. ...". Additionally it tells that user:
Well.. How then should a custom "unittest" configuration be set up? And what are the quirks behind the scene that make
dub testwork in one case but not in the other?tastyminerals commentedon Aug 11, 2021
Bump! Same issue. Is this going to be fixed? How should one trigger unittests in dub?
Geod24 commentedon Aug 11, 2021
Use
mainSourceFilein your configuration. It will be automatically excluded from other configurations.tastyminerals commentedon Aug 11, 2021
Unfortunately, it doesn't work with
dub test:Geod24 commentedon Aug 12, 2021
Where is the
configurationsarray ?What I meant was:
tastyminerals commentedon Aug 12, 2021
Here is the current dub.json
{ "name": "alerter", "sourcePaths": ["source"], "copyFiles": ["./resources"], "targetPath": "build", "configurations": [ { "name": "debug", "mainSourceFile": "source/alerter.d" }, { "name": "unittest" } ], "buildTypes": { "release": { "buildOptions": [ "releaseMode", "inline", "optimize" ] }, "tests": { "buildOptions": [ "unittests" ] } } }And here is what I get, when I try to run
dub buildin the project dir.I tried
dub -boptions and they also don't work.Geod24 commentedon Aug 12, 2021
So you aren't building the
debugconfiguration, andsource/alerter.dis excluded from thealerterconfiguration.tastyminerals commentedon Aug 12, 2021
Ok,
dub -b debugsuccessfully builds the project. However, it uses the "library" target type by default and if I specify the"targetType" : "executable"{ "name": "debug", "mainSourceFile": "alerter.d", "targetType": "executable" }I get :(
Do you have a working
dub.jsonby chance for a single executable script with a custom name?vnayar commentedon Feb 6, 2022
I have run into this problem as well and while searching for answers, I ran into this GitHub issue. In the current dub version, the system does work, but it's quite confusing for newer engineers due to the following reasons:
applicationorlibraryconfigurations are not visible, so there is no easy way to know that special logic was being done by default, and the user just assumes this is normal behavior.configurationcauses the defaults to be lost, e.g. someone adding a special test configuration suddenly finds errors like this while simply trying to build the app or run unittests.With that being said, I find the following
dub.sdldoes most of what is needed for my use case (having a separate integration test configuration that tests the fully built program from the outside):