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

[ped7g]

Another option is to always include the uncompressed data first (to have correct uncompressed size) and then override them with compressed ones.

Pack
                include "Original/Explosion.inc"
                include "Original/Ground.inc"
.Size       EQU $ - Pack
        ifdef _REBUILD
                savebin "Core/Module/Graphics/UI/Menu/Original/Parallax.pack", Pack, .Size
                include "Compress.inc"
        endif
                ; overwrite uncompressed data with compressed pack
                org Pack
                incbin "Compressed/Parallax.pack.ar"
.PackedSize     EQU $ - Pack

And one more option is to use lua script and it's io API to figure out file length (I assume it's possible to do in Lua script).

I still think the most sjasmplus-intended-way is to have multi-stage build, assembling uncompressed data first which will define + export uncompressed labels with final memory layout, prepare compressed archive and then the final asm includes compressed archive and the exported original labels for code manipulating with the decompressed data.

---

Not sure what enhancement would help here, add directive to get file length? I see there is FPOS for output file, so something similar maybe like FLEN filename returning length or -1? I think full C-like fstat doesn't make sense, but length only seems mostly harmless and doable. I would assume the file already exists before first pass of assembling (not a file generated by the current assembling) and doesn't change length during assembling (no appending to it by sjasmplus or some other process), as it would probably check the length during first pass and return the same cached value in all following passes?

Syntax would be probably like this:

explosion.size FLEN "Original/Explosion.inc"
ground.size FLEN "Original/Ground.inc"
    ASSUME 0 <= explosion.size && 0 <= ground.size ; or maybe the FLEN would raise error in case of missing file
Pack.Size EQU = explosion.size + ground.size

Does this make sense to you, do you think this is worth of implementing? I don't see much value in such addition, but also I don't see any big issue with adding it.

(adding this to 1.21 milestone, as I'm going to either implement something or close this, doesn't feel like this will become clearer after few years of being open)