examples/generated-source does not work. Regression in preGenerateCommands.

[veelo]

System information

• dub version: dub 1.9.0
• OS Platform and distribution: Windows 10, and Travis-CI (Linux)
• compiler version dmd-2.080.0

Bug Description

examples/generated-sources does not work.

How to reproduce?

git clone https://github.com/dlang/dub.git
cd dub\examples\generated-sources
dub build

Produces a link error. A second invocation of dub succeeds.

Expected Behavior

Success upon initial invocation.

Logs

.dub\build\application-debug-windows-x86-dmd_2080-33BFC7CE2FACCDF4772619001CE7CA74\generated-sources.obj(generated-sources)
 Error 42: Symbol Undefined __D4test3funFZi
Error: linker exited with status 1

Maybe add this to the test directory? (Make sure the generated file is deleted before the test is run.) This is a regression, see issue #144.

[veelo]

For reference: forum post and failing use case https://forum.dlang.org/post/zhndrynwhtoryxiykxvy@forum.dlang.org

[veelo]

As a work-around, Travis builds can be fixed by prepending a dummy - dub generate sublimetext step, as in veelo/Pascal2D@b098389

[veelo]

If all sources are generated, the error is different:
Configuration 'application' of package [...] contains no source files. Please add {"targetType": "none"} to its package description to avoid building it. Main package must have a binary target type, not none. Cannot build.
When this issue is fixed, the above case should probably also be tested.

Edit: The workaround for this case is different: adding an empty dum.d file in sources helps.

[wilzbach]

A PoC fix for this #1708

[andre2007]

@wilzbach my assumption is, the use case is wrong. The pre generate commands are executed "always". Generating source code using pre generate commands causing therefore a painful behavior as in the referenced issue from @MikeWey.
The correct use case is in my opinion to use the pre build commands for generating source code. Therefore the build settings needs also be refreshed here too.

[veelo]

@wilzbach my assumption is, the use case is wrong. The pre generate commands are executed "always". Generating source code using pre generate commands causing therefore a painful behavior as in the referenced issue from @MikeWey.
The correct use case is in my opinion to use the pre build commands for generating source code. Therefore the build settings needs also be refreshed here too.

I don't understand. As I read it, gtkd-developers/GlibD#6 (comment), @MikeWey says the opposite, that using preBuildCommands won't work in a fresh checkout. That's also my experience. You need commands that are always executed, so preGenerateCommands. The commands themselves should be smart enough to not generate code unnecessarily, e.g. make -f generate.mk, or rdmd generate.d where generate.d considers file modification times. This will prevent the painfulness mentioned in gtkd-developers/GlibD#6.

[andre2007]

@veelo my understanding is, pregenerate and prebuilt commands both suffers from a similar bug. I would say @MikeWey describes this in the first section. The list of known source files must be refreshed after both execution.

Of course preGenerateCommands can implement a logic to generate code only when necessary. In my opinion this additional logic is superfluous if you use preBuildCommands.

[s-ludwig]

@veelo is right here, with the main logical problem being that pre-build commands are potentially out of reach for dub (e.g. when a Visual Studio solution is generated). The only workaround would be to inject something like a dub generate command into the solution/make file as a custom build command, which would partially defeat the purpose of dub generate in the first place.

So in short, we could make pre-buid commands work for BuildGenerator, but for the other generator types it's not really possible in a clean way. As far as I can see, fixing and advocating pre-generate commands is the way to go here.

[veelo]

Of course preGenerateCommands can implement a logic to generate code only when necessary.

How? Dub will need to know on what condition to execute the commands. A proposal: #1857.

[Geod24]

Fixed in #2035