libdcp/src/search.cc, branch fed43 DCP handling library https://git.carlh.net/cgit/libdcp/atom?h=fed43 2025-10-20T18:44:54Z Clarify comment. 2025-10-20T18:44:54Z Carl Hetherington cth@carlh.net 2025-10-20T18:44:54Z urn:sha1:219776f17374c273d4da176c262e8c7ec7b1329b Add method to search for potential DCPs. 2025-03-01T15:44:18Z Carl Hetherington cth@carlh.net 2025-02-28T22:46:53Z urn:sha1:0ed7443df8c5cc41873e03d69582f7e9f18dd91d Add wrappers around boost::filesystem methods that handle the 2023-10-08T23:20:01Z Carl Hetherington cth@carlh.net 2023-10-06T00:04:49Z urn:sha1:e4b2ebd80779a44d24fe87af26ef278c1e2d97d2 required mangling of long filenames on Windows. Also wrap lots of missing places (e.g. calls to asdcplib, libxml++, libcxml etc.) in dcp::filesystem::fix_long_path(). The idea is to keep paths un-mangled until they we call some filesystem-related API and mangle them at that point. Otherwise we end up serialising mangled names, which seems like it will not end well. Should fix DoM #2623. Don't try to create non-existent DCPs when searching for CPLs (DoM #2344). 2022-09-26T17:43:47Z Carl Hetherington cth@carlh.net 2022-09-26T17:43:47Z urn:sha1:8e971733f7e001f944d6dd29193938ebadafd0be Fix failure to find_and_resolve_all_cpls() in some cases. 2022-04-20T18:06:55Z Carl Hetherington cth@carlh.net 2022-01-04T20:54:24Z urn:sha1:819261fbb48c1b4bfbe2a7d5e88bc1529c912845 It seems to me that we need to ignore as-yet-unresolved assets otherwise if we see them in the wrong order we'll throw an exception. Move code to find CPLs in directories out of DCP-o-matic. 2022-04-20T18:06:40Z Carl Hetherington cth@carlh.net 2022-01-03T23:26:49Z urn:sha1:52c03575531045c08de6e8769e8f4b00204b5ccc This adds find_and_resolve_cpls().