Replace some uses of Poco::Path with std::filesystem::path #38761
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jclarkeSTFC
added
Maintenance
jclarkeSTFC
force-pushed
the
37868_migrate_to_std_filesystem
branch
7 times, most recently
from
0e34c60 to
f1acfba
Compare
jclarkeSTFC
added
the
Extra Attention
jclarkeSTFC
force-pushed
the
37868_migrate_to_std_filesystem
branch
5 times, most recently
from
394349c to
b55c5d9
Compare
github-actions
bot
added
the
Has Conflicts
|
👋 Hi, @jclarkeSTFC, Conflicts have been detected against the base branch. Please rebase your branch against the base branch. |
Poco::Path::expand does not have an equivalent in the standard library.
To maintain the same Python API, return std::strings when getting directories from ConfigService.
Turns out it just removes any filename from the path object, so the equivalent is std::filesystem::path::remove_filename.
Representing a path as a string causes pain because you have to worry about whether or not there is a slash, which direction is the slash on which OS, etc.
Poco::Path::resolve did not like the std::filesystem::path not having a slash at the end (!), so I removed Poco to make this method use std instead.
Poco::Path::isDirectory only checks if the Poco::Path object has something labelled as a filename, not necessarily if it exists. Hence to get the same functionality we need to check if the path exists or not, and also if it is a directory or not. If it's an existing file then it's no good.
Msbuild apparently is not happy with creating Poco::File objects from std::filesystem::path so I gave it some help.
We shouldn't use a string to represent a file path, because then we have to worry about slashes and which way they're going, etc.
Msbuild requires that .string() on std::filesystem::path be called in a variety of places, whereas Clang and GCC don't have a problem going from a std::filesystem::path to a Poco::Path via a string.
jclarkeSTFC
force-pushed
the
37868_migrate_to_std_filesystem
branch
from
3cbfb29 to
559b0a0
Compare
jclarkeSTFC
removed
the
Has Conflicts
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've replaced some usages of
Poco::Pathwithstd::filesystem::path, and in some places where strings were being used to represent paths I switched tostd::filesystem::path. I made changes toConfigServiceso would be good to give this a thorough check. See #37868 for further details on this migration.Note:
Poco::Path::expanddoes not have an equivalent in the standard library, it expands all environment variables in the path.One gotcha I found, if you thought that
Poco::Path::makeDirectorywould make a directory, then you'd be wrong, it removes the filename from thePoco::Pathobject.Refs #37868.
To test:
This does not require release notes because this is an internal refactor, API should stay the same.
Reviewer
Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.
Code Review
Functional Tests
Does everything look good? Mark the review as Approve. A member of
@mantidproject/gatekeeperswill take care of it.Gatekeeper
If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.