get include length size

[DeadlyKom]

1.20.3

example

ifdef _REBUILD
Pack            EQU $
                include "Original/Explosion.inc"
                include "Original/Ground.inc"
Pack.Size       EQU $ - Pack
                savebin "Core/Module/Graphics/UI/Menu/Original/Parallax.pack", Pack, Pack.Size
                include "Compress.inc"
                else
Pack            incbin "Compressed/Parallax.pack.ar"
.Size           EQU $ - Pack
                endif

in the first pass, when the _REBUILD preprocessor is installed, N files are assembled into one common file and this file is subsequently archived. in the second case, when the _REBUILD preprocessor is not installed, the archived block is embedded. This is the main problem, is it possible to somehow get the length of the inlud files (in the first case), but being in the second, so that after unzipping them in memory. Thus, upon receiving the length of the first include, the address of the next one can be calculated, etc. example: address + size of the first insert = new address of the next insert, etc.

[ped7g]

If I understand you correctly, your issue is that Pack.Size is different when building with _REBUILD (raw uncompressed data size) vs building without _REBUILD when the Pack.Size is the compressed size of .ar file.

I think for this the least hacky way is to preserve raw labels from _REBUILD type of build, which can be done for example with help of EXPORT feature: http://z00m128.github.io/sjasmplus/documentation.html#po_export

You can then INCLUDE the resulting file in non-REBUILD builds, and use different labels for compressed size if you need also that, etc.

I'm using that in my own displayedge library to give possible option of building the library binary with sjasmplus and including/use that in project using other assembler/build tools (if it is at least compatible with those equ in the exported file).

Let me know, if I understood you correctly, and if this helps, or why you can't use this approach.

[DeadlyKom]

Sorry that it took so long, I tried different things, in general you can live with this, but it’s very inconvenient to use this. If it were possible to assign a file name in the right place via OPT, may be would improve the situation. in general, now my assembly is not automatic but manual in 3 passes

1. creating export lables (not archived data)
2. based on export lables, creating code and archiving them
3. assembly of code taking into account compressed data