prb28 / vscode-amiga-assembly

Amiga Assembly extension for Visual Studio Code
GNU General Public License v3.0
178 stars 12 forks source link

amigaassembly: compile current file does not honor vasm settings #188

Closed farmelle closed 2 years ago

farmelle commented 2 years ago

When modifying tasks.json to add extra command line switches, the amigaassembly: compile current file task doesn't reflect these changes. amigaassembly: build correctly uses these settings.

Steps to recreate:

  1. load the vscode-amita-wks-example-1.0.0 into VSCode
  2. Modify the vasm args
  3. open and save gencop.s
  4. build project
  5. compare the called command lines between compile current file and build

e.g. modifying vasm to use -m68020


Compiling current editor file...
Creating directory build
building p:\vscode-amiga-wks-example-1.0.0\build\gencop.o
c:\Users\amiga\AppData\Roaming\Code\User\globalStorage\prb28.amiga-assembly\file-downloader-downloads\vscode-amiga-assembly-binaries-@-1.0.0\prb28-vscode-amiga-assembly-binaries-a7978b7/vasmm68k_mot -m68000 -Fhunk -linedebug -o p:\vscode-amiga-wks-example-1.0.0\build\gencop.o p:\vscode-amiga-wks-example-1.0.0\gencop.s

Vs


Starting build...
Compiling_________________________________________
building p:\vscode-amiga-wks-example-1.0.0\build\gencop.o
c:\Users\amiga\AppData\Roaming\Code\User\globalStorage\prb28.amiga-assembly\file-downloader-downloads\vscode-amiga-assembly-binaries-@-1.0.0\prb28-vscode-amiga-assembly-binaries-a7978b7/vasmm68k_mot -m68020 -Fhunk -linedebug -o p:\vscode-amiga-wks-example-1.0.0\build\gencop.o p:\vscode-amiga-wks-example-1.0.0\gencop.s

Note that compile current file is still using 68000

prb28 commented 2 years ago

The build options for syntax checking are built-in. And I agree with you it's not a good idea. I don't know if the build task options are the best to check the syntax. Maybe it would be better to set these options in a workspace setting. What is you opinion?

prb28 commented 2 years ago

I think I've to declare these as a setting.

farmelle commented 2 years ago

I would say it should probably use the same settings as vasm when doing a build. Specific settings would add flexibility, but I imagine most people would change these settings for cpu targeting and include dirs (to allow better structured projects) which would need to be the same for both syntax checking and final assembly.

As it stands the work around is to just save the file (which for me generates errors predictably), then command a full build to syntax check.

prb28 commented 2 years ago

I agree. The build can be triggered with 3 tasks - a complete build (vasm+vlink), a one file build(vasm+vlink) and a one file compile(vasm only). Each task has a different configuration and is independent. The compile configuration can be added in the tasks.json (with the last fix) to set these parameters but you'll have to define twice the same vasm arguments. I'll do a little video to show how to handle this. You'll tell me if it looks odd.

prb28 commented 2 years ago

As published in the pre-release: syntaxcheckvasmconf

What do you think about this way to configure?

farmelle commented 2 years ago

Yeah, that looks great! Defining it twice does make some sense anyway in certain circumstances.

prb28 commented 2 years ago

Great, you can test it in the pre-release. I close this issue.

phaze101 commented 2 years ago

@prb28 This is something that I wanted to tackle and I missed this fact that you were discussing it. Can the VASM options be part of the settings in the extension and then be passed as a parameter to VASM. The reason being from time to time I want to change these. Few things of these is target different CPU or having a behaviour that VASM acts like Devpac and other acts like ASMOne. Sorry I posted here instead of open a new issue. I thought if not possible it is useless opening a new one.

prb28 commented 2 years ago

You can change them in the tasks.json file as showed. The use of a task is more in the "vscode logic", but maybe it's just my point of view.

phaze101 commented 2 years ago

@prb28 yeah from a coder point of view that know what he is coding is fine. From a beginners points of view the right place is the extension settings. I am uncomfortable showing this to beginners.

prb28 commented 2 years ago

Ok, I think it will fit in a new feature request to create and configure a workspace with an interface. It will have the selection of the emulator, the build settings, the kickstart, etc. Big work in perspective.

phaze101 commented 2 years ago

@prb28 Well we like to keep you busy :) Version 2 needs to have something in it :)

phaze101 commented 2 years ago

@prb28 when you have time check my emails.