Closed earltacs closed 6 years ago
How are you compiling? Do you actually set the correct target directory?
Hmm? That didn't strike my mind at all.
No I didn't, since in windows the compiler specifically compiles already at the gamemodes folder.
Does the linux compiler not do the same thing?
More Info: IDE = Visual Code for linux Task =
{
"version": "2.0.0",
"tasks": [
{
"label": "build-normal",
"type": "shell",
"command": "${workspaceRoot}/pawno/pawncc",
"args": ["${relativeFile}", "-d:3"],
"group": {
"kind": "build",
"isDefault": true
},
"isBackground": false,
"presentation": {
"reveal": "silent",
"panel": "dedicated"
},
"problemMatcher": "$pawncc"
}
]
}
This compiling method works on windows. and it compiles within the method
this - "-(+" and this - "-;+"
Since linux is a bit complicated, I added libpawnc.so and the whole includes folder on /usr/local/lib and pawncc and pawndisasm on /usr/local/bin but also let it remain on the pawn folder. Removing either will give me an error of pawncc not being found or libpawnc.so not found.
No, pawno
specifies the output directory by passing it on the command line, not windows. They both just use the current working directory otherwise.
Also, why didn't you use the issue template?
So there are three ways of controlling this:
options.cwd
-D
flag-o
to specify an output .amx fileAhhh, I do get it though, does it mean that I do need to skim through the source code and change the path or is there a way without touching the compiler source code?
I thought that was just a guideline for me on what to show...
to correct the improper
Is this a BUG REPORT, FEATURE REQUEST or QUESTION?:
What happened: Compiler compiled .amx outside of gamemode folder
What you expected to happen: Compiler should compile .amx inside the gamemode folder on which where the .pawn script is located
Anything else we need to know?: I didn't compile the compiler on my own, I just downloaded it through the release page.
So there are three ways of controlling this:
setting the current working directory of the command invocation via options.cwd <- Will research setting the -D flag <- This is printed incorrectly, it is Dpath instead of D<path> using -o to specify an output .amx file <- and this is the magical option
so I followed southclaw's instructions
{
"version": "2.0.0",
"tasks": [
{
"label": "build-normal",
"type": "shell",
"command": "${workspaceRoot}/pawno/pawncc",
"args": ["${relativeFile}", "-d:3", "-o:gamemodes/${fileBasenameNoExtension}.amx"],
"group": {
"kind": "build",
"isDefault": true
},
"isBackground": false,
"presentation": {
"reveal": "silent",
"panel": "dedicated"
},
"problemMatcher": "$pawncc"
}
]
}
luckily vscode got that no extension call. And it compiled to the correct place now.
Now this is just a question though, Why does it that we don't need to add -o option in the Windows Operating Systems but should be used in the linux distros. Is there some difference between the pawno linux and pawno windows?
minor gripe: pawno is the ancient editor that ships with the SA:MP server distro and since you're using vscode pawno isn't relevant here. pawn is the language and pawncc is the compiler.
As far as I've seen, I don't think there's a difference between the compiler builds on Windows and Linux when it comes to output file (correct me if I'm wrong) so it's most likely vscode acting different on different platforms.
The only way to know for sure is execute the compiler from the command line on both operating systems to eliminate the editor invocation as a source of the issue.
I just did what you said
This is when I am in the pawno folder
../pawno/pawncc battleroyal.pwn -d3
Pawn compiler 3.10.6 Copyright (c) 1997-2006, ITB CompuPhase
Header size: 7000 bytes
Code size: 433420 bytes
Data size: 1209264 bytes
Stack/heap size: 17039360 bytes; estimated max. usage=1443 cells (5772 bytes)
Total requirements:18689044 bytes
and this is when I'm in the gamemodes folder, it compiles within the folders
pawncc ../gamemodes/battleroyal.pwn -d3
Pawn compiler 3.10.6 Copyright (c) 1997-2006, ITB CompuPhase
Header size: 7000 bytes
Code size: 433420 bytes
Data size: 1209264 bytes
Stack/heap size: 17039360 bytes; estimated max. usage=1443 cells (5772 bytes)
Total requirements:18689044 bytes
I understand this is also how it works on windows since I tested this out before, since I wanted to know how the compiler works and there is really no difference.
If I did this on the vscode and I placed the .pwn within the pawno folder it would still do the same earlier, compiling .amx outside of the pawno folder. Which means that vscode is currently doing the default thing. Vscode has the ${workspace} thing which holds the workspace and that's how the .json works for the compiler but rather than
executing this
${workspace}/gamemodes$ ../pawno/pawncc battleroyal.pwn -d3
it executed this
${workspace}$ ../pawno/pawncc battleroyal.pwn -d3
ommiting the folder that is executed at... That's how I understand things...
Thanks by the way, I think I find my ways now. Might as well open this as an issue on the vscode repository... Since this is not part of the pawn problem.
Yeah vscode will by default use the workspace as the working directory for the executable. You can either set options.cwd
to ${workspace}/gamemodes
or pass gamemodes/battleroyale.pwn
as the argument.
But, feel free to open it on vscode-pawn
repo, even though it's not directly related to the plugin it'll make sense to keep the discussion there.
Before everything else O.S = Linux Distribution = Ubuntu Version = 17.x SA-MP Version = 0.3DL - RC 1
Now that's out of the subject, the only problem I have is the compilation. As of now I have compiled my gamemode and it compiles outside of the gamemodes folder. Don't know if this is a bug on my part or on the compiler, the compiled .amx is not broken of some sort, even using fixes, YSI(modefied for linux compilers), and other plugins and includes. Now is there a way to fix this?
I have little bit of knowledge of C language and since I was from a Windows 7, I still have ways to learn in the Linux distribution, and have no means of editing the code for the linux side.