dxfread (and DISABLED_DXF/WRITE source inclusion issues)

[fr-an-k]

This serves my use case of a javascript production environment (I'm using it already); converting to/from JSON uing CLI, until I can produce an npm or WASM equivalent of DXF <-> JSON converter.

Javascript is the most popular language dominating many platforms and it seems very uncommon for a library to not have bindings for it.

Converting indirectly through DWG is undesirable since this is very error prone and makes end users have to wait longer; the DXF files that I have to support are tens of MB.

Having this in the master branch would greatly simplify further development, especially since most of the DXF that I have to support are currently failing.

[fr-an-k]

@rurban dxf_read_file was defined only when USE_WRITE was enabled, in what appears to be your commit.
I removed that part of the conditional to pass the tests, or was there a reason for that?
In that case I will solve it differently and add a comment to clarify.

[fr-an-k]

I assumed LIBREDWG_DISABLE_WRITE is intended to exclude functions that write the dwg structure to any kind of file.

[rurban]

USE_WRITE is needed because preR13 needs the add api for the control objects.

[fr-an-k]

Ok thanks, shoulnd't USE_WRITE then ideally only be used to include preR13 support in dxf_read_file?
Also, it is correct that all the programs should be turned off for --disable-write?
Otherwise they would pretty much be an empty executable; even dwglayers and dwggrep have write dependencies.
Maybe it's better to simply remove the ifdefs for write (and tests for disable write), so it's always enabled.

[fr-an-k]

@rurban would it be appropriate if I change dwgfuzz to support any input to any output?
Just for improved testing and to pass the PR tests, not for my own needs.

I ended up fixing the USE_WRITE issue by including encode.c when USE_WRITE is disabled but DXF is enabled.

[rurban]

Sure, as in llvmfuzz