-
Notifications
You must be signed in to change notification settings - Fork 460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DRAFT: ocioarchive enhancements #1931
base: main
Are you sure you want to change the base?
Changes from all commits
b796a6f
4869a87
a115736
54121ce
c727983
8671def
ec3e761
94a0221
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,6 +12,7 @@ | |
#include <string> | ||
#include <fstream> | ||
#include <vector> | ||
#include <set> | ||
|
||
#include "OpenColorABI.h" | ||
#include "OpenColorTypes.h" | ||
|
@@ -1503,7 +1504,7 @@ class OCIOEXPORT Config | |
* | ||
* \return bool Archivable if true. | ||
*/ | ||
bool isArchivable() const; | ||
bool isArchivable(bool minimal) const; | ||
|
||
/** | ||
* \brief Archive the config and its LUTs into the specified output stream. | ||
|
@@ -1521,15 +1522,21 @@ class OCIOEXPORT Config | |
* trying to resolve all the FileTransforms in the Config to specific files is because of the | ||
* goal to allow context variables to continue to work. | ||
* | ||
* Archiving a minimal Config will try resolve these file references using the current context. | ||
* | ||
* If a Config is created with CreateFromStream, CreateFromFile with an OCIOZ archive, or | ||
* CreateFromConfigIOProxy, it cannot be archived unless the working directory is manually set | ||
* to a directory that contains any necessary LUT files. | ||
* | ||
* The provided output stream must be closed by the caller, if necessary (e.g., an ofstream). | ||
* | ||
* \param ostream The output stream to write to. | ||
* \param flags Flags top control archive creation | ||
*/ | ||
void archive(std::ostream & ostream) const; | ||
void archive(std::ostream & ostream, ArchiveFlags flags) const; | ||
|
||
//TODO: document | ||
void GetAllFileReferences(std::set<std::string> & files) const; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we want this in the public API or is it only for OCIOZArchive need? If the latter, there might be a way to move it to ConfigUtils.h instead. If the former, I'd vote to return a vector instead of set in the spirit of reducing STL headers included here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That was one of my thoughts, I would think other uses for the list of files would be interesting and thus a public function may be needed. Note that the existing code uses them as a set rather than a vector as this then makes each entry unique as it is obviously possible to use the same external file in multiple transforms in a config file (we use the same placeholder file for some of our configuration files). If we want to turn that into a vector for a public API then I guess that is fine. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Personally it seems this new method is not strictly needed as you can implement it with the existing public API (if I'm not mistaking), but I'm not opposed to adding it if you think there is a strong benefit to have it. Yes I think the use of set is appropriate for the implementation but not strictly required in the public API, might be nitpicking but seems slightly cleaner! |
||
|
||
Config(const Config &) = delete; | ||
Config& operator= (const Config &) = delete; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this accept the Flag enum instead, could make it more future proof? Adding it as an overload might be cleaner for current users of isArchivable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I don't like the use of Flags as they can hide the actual meaning so I guess I defaulted to a single boolean, that said I'd prefer not using multiple bool's in APIs, so if we needed other parameters in the future then I'd suggest wanting to wrap the boolean in a stronger type to avoid calling
function(true, false, true, ...)
but if others want Flags That is simple enoughThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you, although to me, even one boolean is not very explicit here, when you see
isArchivable(true)
somewhere randomly in the code. Flags are already used in other places of the API like for the Processor queries so that might be more consistent.