Debugger runs incorrect hashlink file when a display.hxml is present

[tbrosman]

Version: 1.1.0 (works fine in 1.0.0)

Example project: https://github.com/tbrosman/tube-engine-shell (not quite a "minimal" repro, but not many moving parts)

Steps:

• Build TestRunner
• Run TestRunner

Expected: should run TestRunner
Actual: HashLink debugger attempts to run the output hl corresponding to vshaxe-display.hxml. I get the following error

Error: ENOENT: no such file or directory, open 'bin/ignore.hl'

Called from fs.js line 447 column 3
Called from electron/js2c/asar.js line 140 column 31
Called from electron/js2c/asar.js line 140 column 31
Called from fs.js line 349 column 35
Called from fs.readFileSync (electron/js2c/asar.js line 542 column 40)
Called from fs.readFileSync (electron/js2c/asar.js line 542 column 40)
Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\adapter.js line 314 column 79
Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\adapter.js line 127 column 29
Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\node_modules\vscode-debugadapter\lib\debugSession.js line 342 column 22
Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\node_modules\vscode-debugadapter\lib\protocol.js line 97 column 38

[ncannasse]

You need to select the correct hxml in vscode for compilation as 1.1.0 will use this one to locate the .hl - no longer the one in launch.json Le dim. 21 juin 2020 à 01:44, Tommy Brosman <notifications@github.com> a écrit :

…

Version: 1.1.0 (works fine in 1.0.0) Example project: https://github.com/tbrosman/tube-engine-shell (not quite a "minimal" repro, but not many moving parts) Steps: - Build TestRunner - Run TestRunner *Expected:* should run TestRunner *Actual:* HashLink debugger attempts to run the output hl corresponding to vshaxe-display.hxml. I get the following error Error: ENOENT: no such file or directory, open 'bin/ignore.hl' Called from fs.js line 447 column 3 Called from electron/js2c/asar.js line 140 column 31 Called from electron/js2c/asar.js line 140 column 31 Called from fs.js line 349 column 35 Called from fs.readFileSync (electron/js2c/asar.js line 542 column 40) Called from fs.readFileSync (electron/js2c/asar.js line 542 column 40) Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\adapter.js line 314 column 79 Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\adapter.js line 127 column 29 Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\node_modules\vscode-debugadapter\lib\debugSession.js line 342 column 22 Called from c:\Users\Tommy\.vscode\extensions\haxefoundation.haxe-hl-1.1.0\node_modules\vscode-debugadapter\lib\protocol.js line 97 column 38 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZXQHIOAVJQMKPIYA55SLRXVCULANCNFSM4ODS5WSQ> .

[tbrosman]

I was looking through the VS Haxe documentation earlier. I am not sure how to do this. Which file to I specify it in? (settings.json somehwere?)

[ncannasse]

At the bottom of vscode window - blue bar Le dim. 21 juin 2020 à 01:50, Tommy Brosman <notifications@github.com> a écrit :

…

I was looking through the VS Haxe documentation earlier. I am not sure how to do this. Which file to I specify it in? (settings.json somehwere?) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZXQGPLFU3KPDWQ6TNNV3RXVDNDANCNFSM4ODS5WSQ> .

[tbrosman]

You mean the haxe.configurations, right? In my case that is my display.hxml. I have multiple sub-projects that each have their own classpaths. To make code completion work across all sub-projects, I've been using a display.hxml that includes the superset of all of those classpaths. It is kind of gimpy, but worked until now.

If display-only hxml isn't supported, I'll have to switch the active configuration when I edit/build different projects (which seems inconvenient). Also, I see that only top-level hxml files are auto-detected by vshaxe, which is a problem for my project structure. Is there a better pattern for this kind of project?

[ncannasse]

Ping @Gama11 Le dim. 21 juin 2020 à 02:17, Tommy Brosman <notifications@github.com> a écrit :

…

You mean the haxe.configurations, right? In my case that is my display.hxml. I have multiple sub-projects that each have their own classpaths. To make code completion work across all sub-projects, I've been using a display.hxml that includes the superset of all of those classpaths. It is kind of gimpy, but worked until now. If display-only hxml isn't supported, I'll have to switch the active configuration when I edit/build different projects (which seems inconvenient). Also, I see that only top-level hxml files are auto-detected by vshaxe, which is a problem for my project structure. Is there a better pattern for this kind of project? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZXQEZIH2LL7DGQKWJ6HDRXVGRJANCNFSM4ODS5WSQ> .

[Gama11]

We could look into supporting automatic debug configurations at some point.

[ncannasse]

Or we could reallow to specify hxml in launch options. Would be optional. Le dim. 21 juin 2020 à 09:42, Jens Fischer <notifications@github.com> a écrit :

…

We could look into supporting automatic debug configurations <https://code.visualstudio.com/updates/v1_45#_automatic-debug-configurations> at some point. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZXQFHGIXNOGRGAY42CITRXW2WTANCNFSM4ODS5WSQ> .

[Gama11]

But the hashlink-debugger would need the HXML parsing code we wanted to get rid of again.

[tbrosman]

@Gama11 and @ncannasse: I thought about this some more. The root problem is when I edit a file in a multi-hxml project, the debugger doesn't have a way of knowing which hxml intend to build it with. The current solution requires me to specify which hxml file is "most appropriate" for my current configuration. There are a couple approaches that could be taken:

• A) Allowing the user to specify a project-wide display.hxml (roughly what I was doing). These kinds of files are inconvenient because they have to contain a superset of all the build.hxml libraries/etc.
• B) The extension detects which hxml is effective for a particular haxe file. This could work similar to how TypeScript resolves the current tsconfig (https://www.typescriptlang.org/docs/handbook/tsconfig-json.html): start in the current directory (in this case, the source file's directory) and work upwards until it finds one. This fails when multiple hxml_s live in a single directory (common) or the hxml it finds is not the "intended" target (uncommon).
• C) Some kind of project file that isn't an hxml. Similar to (B), but it's not a build target. Example vshaxe-project.json:

{
  "display-hxml": "my-display.hxml"
}

It would only be required in the case where (B) fails.