Open jonathanbennett73 opened 5 years ago
Thanks! That's weird... have to boot my gaming(windows;-) machine to test.
It seems to work on my windows 10.
Are you sure VASM can reach the included file ? VASM documentation:
2.4 Include Files Vasm supports include files and defining include paths. Whether this functionality is available depends on the syntax module, which has to provide the appropriate directives.
On startup vasm will define at least one default include path: the current working directory, where the assembler program was launched from. When the input file is loaded from a different directory, i.e. the input file is a relative or absolute path and not a single file name, then the path to the input file name will be added as another include path.
Include paths are searched in the following order:
Do you have an INCDIR command ? You can try to add a -I command in the vasm build settings of the extension.
Everything still assembles ok.
Really ??? The error message seems frightening:
fatal error 13: could not open <../include/exec/exec_lib.i> for input aborting...
And on my machine, the .o file is not compiled.
There is definitely an inconsistency in the error handling: when you click on the build button the extension does not now which source has a problem so it shows a dialog. When you save you file, the extension searches the string in the source so you have a line error. I've to see if I can do a better job on that.
Ok sorry. I'm being misleading :)
I'm not using the extension build functionality. Instead I'm running my own batch/makefile to do gfx/module conversions and assembling. And then it runs vasm on various source files and then vlink. So my demo structure is:
workspace: /includes /includes/custommacros.i demomain.s /demosubpart /demosubpart/subpart.s ( includes ../includes/custommacro.i )
So I will never use the Build button - kind of like the makefile scenario in another issue. I will just open the workspace, edit files. Assemble in the background/task and then debug back in vscode via your extension. If that makes sense? I can send you my workspace folder example if it helps? Let me know an email.
The reason it doesn't work with normal build is that I want to do pre/post tasks and also sometimes I want to assemble subpart.s as a "standalone.exe" for quick testing.
If that makes sense?
Yes a lot, it's the best way to go for a more complex project.
I've reproduced your problem with a subdir containing an relative include: /includes/custommacros.i /demosubpart/subpart.s ( includes ../includes/custommacro.i )
The extension needs to make a vasm build on save to have a syntax error highlight. and vasm doesn't seem to like this construction. I'll dig into this later but I found a workaround, in your settings add the root includes dir:
"amiga-assembly.vasm": {
"enabled": true,
"file": "bin/vasmm68k_mot",
"options": [
"-m68000",
"-Fhunk",
"-linedebug",
"-I",
"includes"
]
},
and in your source add the include:
INCLUDE "custommacro.i"
The error can come from an included file in the custommacro.i
. Once again, I have to do more investigations.
Hope it helps.
Is use follow on my Win10 and its work great ;)
...backslash work too^^
Hi, Awesome extension - I'm totally using this workflow now :)
I'm on Windows and using a workspace and having a conflict with slashes. If I write code like this: INCLUDE "../Includes/SomeInclude.i" then vscode highlights it in red as a problem in the editor/workspace.
But if I change it to backslashes like: INCLUDE "..\Includes\SomeInclude.i" then vscode is happy but then I get a popup from the amiga extension with the message: "fatal error 13: could not open <..\Includes\SomeInclude.i">
Everything still assembles ok, but I have to choose which of the two errors I want to see :)