Bug? b4xlibs using b4xlibs with Files in Release mode

[alwaysbusy]

It looks like resources in the Files folder from a sub-b4xlib (a b4xlib that is used in another b4xlib, using B4J.DependsOn) are not decompressed in Release mode and hence not found by the compiler.

Situation:

1. helper.b4xlib
code.bas
manifest.txt*
Files
---> helper.js

* content of manifest.txt

Version=1.01

2. css.b4xlib
code.bas
manifest.txt*
Files
---> css.js

* content of manifest.txt

Version=1.01
B4J.DependsOn=helper

3. DemoApp
Referenced libraries: only css.b4xlib

When compiling the Demo App in Debug mode, no problems.

When compiling the Demo App in Release mode, the b4xlibs/Files subfolder only contains css.js, NOT helper.js and the compiler shows something like this:

B4J Version: 7.80
Java Version: 9
Parsing code.    (0.06s)
Building folders structure.    (0.34s)
Compiling code.    (0.11s)
Compiling layouts code.    (0.01s)
Organizing libraries.    (0.00s)
Compiling generated Java code.    (2.88s)
Building jar file.    Error
System.IO.FileNotFoundException: Could not find file 'K:\BANano3.09\Demo\Objects\b4xlibs\Files/helper.js'.
File name: 'K:\BANano3.09\Demo\Objects\b4xlibs\Files/helper.js'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileInfo.get_Length()
   at fg.a(ec A_0, Dictionary`2 A_1, Tuple`2[] A_2)
   at er.a.ag()

 

[Erel]

Does it work if you reference the 'helper' library from DemoApp?

 

[alwaysbusy]

Does it work if you reference the 'helper' library from DemoApp?

Yes, but I thought the whole point of B4J.DependsOn was that you, as a user of a library, didn't had to worry about other libraries the referenced library used. And I found it weird I did not get the above error in debug mode, only in released mode.

 

[Erel]

You are correct. It was just a test to better understand the problem.

 

[Erel]

It is fixed for the next update.

 

[alwaysbusy]

Super! Thanks @Erel. I'll continue implementing this so it is supported in BANano.

 

[Erel]

Apparently this bug still exists (B4A v9.8 / B4i v6.30 / B4J v8.10), at least in some of the cases.

It is fixed for the next update.

The workaround is to explicitly add a reference to the required b4xlib.