Closed KrzysFR closed 7 years ago
Yes on all points.
Let me first ensure latest synchronisation with zstd
project.
I have no idea about a correct dll
name and scope.
There is no plan to deliver stand-alone libraries for fse or huff0.
So it could be any.
Just note that huff0 depends on fse for encoding its own header.
sync completed. ready to update for Windows DLL
So we can go with a PUBLIC_API
macro, that would be set only on methods exposed in fse.h
and huf.h
, and nothing else (for the moment). For the dll, can I suggest libfse.dll
?
yes, good to go
Quick question: what about the #ifdef FSE_STATIC_LINKING_ONLY
in fse.h
? It looks like it defines a bunch of very internal methods that would probably not be used with Windows dll directly, so maybe they should be exported? (such as FSE_count_wksp
, FSE_countFast_wksp
, FSE_buildCTable_rle
, FSE_encodeSymbol
, ...)
Edit: same with with HUF_STATIC_LINKING_ONLY
in huf.h
It's up to you. I would suggest to not expose them if you don't need them.
_btw : that's the purpose of calling the unlocking macro FSE_STATIC_LINKING_ONLY
..._
I'm writing the .rc files (adds descriptions, copyright and file versions to .exe and .dll) and I was not able to find any version information in the .h files .... so... what is the current version of FSE ? :)
I can add FSE_VERSION_MAJOR
and cie, so that I can reuse the same trick in zstd.rc (includes zstd.h directory and use the the ZSTD_VERSION_xxx
macros)
There is no version number on fse yet. Reason is, it was not forecasted to be a stand-alone library. But if now it is, then it indeed requires a version number
No clear idea about best version number. Maybe 1.0.0, since it's part of zstd >= 1.0.0, hence is supposed to be stable. Or 0.9.0 if there is a need to test all this before moving to 1.0.0.
see #75
As stated in facebook/zstd#472, I would like to use FSE and HUFF0 methods from .NET which requires having a Windows DLL with public method marked as exported.
As was done for zstd, we just need to add a macro that does the same thing as here: https://github.com/facebook/zstd/blob/426a9d4b7128ef54d79627cff346173e833f733a/lib/zstd.h#L21
I can try putting a PR together for this, but I have a few questions:
1) Should there be a single
PUBLIC_API
macro used in all thefse.h
,huf.h
error_public.h
? Or should there be multipleFSE_API
,HUF_API
macros to opt-in/out of each module?2) Can we consider all methods declared in
fse.h
,huf.h
anderror_public.h
as public, and everything else as private? What aboutbitstream.h
andmem.h
?3) the VC2012 project does not seem to provide a name for the generated dll (so it's probably . Would there be objections to updating the project to generate
libfse.dll
instead? Though if it can contains huff0 as well, manylibfse.dll
is too specific, and there should be another name for this library? (the repo is namedFiniteStateEntropy
but the title says "New Generation Entropy coders"...)