INCBIN command assumes current OS path based on the .asm file where it resides. Does this have to be the case?

[specke]

Version	Platform	Topic
v1.20.x (tested on 1.20.1 and 1.20.3)	Windows 10	INCBIN

The INCBIN does not take the current directory into the account. I am trying to include a necessary binary file from a file included elsewhere, and it uses the current directory of the included file as the current folder. Please see the example below:

; overall directory structure

CURRENT DIRECTORY
|
|-- bin
    |-- example.bin     <- file that I'd like to include
|-- include
    |-- bin
        |-- example.bin   <- the file that I need to have there, but would not like to include
    |-- example.asm
|-- bug.asm

; contents of file "include/bin/example.bin"
WRONG FILE

; contents of file "include/example.asm"
	IF INCLUDE_ELSEWHERE != 0
		INCBIN "include/example.bin"
	ENDIF

; contents of file "bin/example.bin"
RIGHT FILE

; contents of file "bug.asm"
		DEVICE ZXSPECTRUM48
INCLUDE_ELSEWHERE:	EQU 0
			ORG 32768
			INCLUDE "example.asm"
		IF INCLUDE_ELSEWHERE == 0
			INCBIN "bin/example.bin"
		ENDIF

I am running sjasmplus with the command sjasmplus --msg=war --syntax=abfw --inc=include bug.asm. The problem is that if INCLUDE_ELSEWHERE is 0, right binary file gets included, whereas if INCLUDE_ELSEWHERE is non-zero, sjasmplus includes the wrong file. Annoyingly, this cannot be overridden by using angular brackets, because if the wrong file is present it gets included first, for any type of brackets.

Why would I want to do keep binary files in the include folder? I don't actually, this is just a simple example to show the problem. In my case, I am trying to create a standard library, stored in a centralized repository of include files, which to build .tap files in a standartized fashion. I can include this library in every folder where I am building my .tap, but it feels ulgy and wasteful. However, when I am attempting to use this kind of "included" tap builder, I cannot configure it for building my tap locally, as it is trying to get file from its own context.

I am not sure if this qualifies as a bug, as it is partly covered in the documentation. However, I think that this behaviour is unhelpful, so it is indeed not a bug, please treat it as a feature request.

[specke]

My apologies, it turns out that my minimal example does not reproduce the issue after all. Am closing the issue until I can figure this out.

[ped7g]

I'm almost 100% sure the INCBIN has same rules as INCLUDE:

If the file cannot be found in the current directory (the current directory is the directory the current asm file comes from!) the file will be searched for in the directories specified at the commandline. When angle brackets are used, the commandline directories are searched before the current directory.

EDIT:

INCLUDE_ELSEWHERE is non-zero, sjasmplus gives a cryptic error message and binary file does not get included.

would it be too difficult to copy/paste it into the issue, or at least screenshot it? "cryptic error message" doesn't help much.

[specke]

Thanks, @ped7g, your comment helped me to understand the issue better. Indeed, it is the assumption to measure the current folder from the current .asm file which I am having problems with. I updated the example and text around, could you please have a look again?

[ped7g]

Note for myself (to not forget when I get some dev time again): indeed the include search behaviour is not unified across all INCsomething, only INCLUDE respects quotes vs angle brackets, INCBIN works always as if quotes were used (others need check).

I guess it would be better to change everything to use quotes vs angles, may probably break some old projects, but should be rare. (I also believe it's not a good project source design what OP was originally trying to achieve, but that's just personal preference :) ).

edit: also error for incbin "" is a bit lame... :grin: