Skip to content

Use std filesystem instead of Boost.Filesystem if available.#7

Open
Mike-Devel wants to merge 3 commits into
boostorg:developfrom
Mike-Devel:std_filesystem
Open

Use std filesystem instead of Boost.Filesystem if available.#7
Mike-Devel wants to merge 3 commits into
boostorg:developfrom
Mike-Devel:std_filesystem

Conversation

@Mike-Devel

@Mike-Devel Mike-Devel commented Oct 16, 2018

Copy link
Copy Markdown
Contributor

Makes the cmake based boostdep build independent of an installed boost library when you have a recent c++17 toolchain.

Afaik this currently only works with MSVC2017, as gcc-8 needs special linker flags for now and I don't think it is worth supporting that. I tested it locally, but unfortunately I'm not sure how to hook this up with appveyor CI.

@pdimov

pdimov commented Oct 28, 2018

Copy link
Copy Markdown
Member

What special flags are needed on g++ 8?

@Mike-Devel

Copy link
Copy Markdown
Contributor Author

Afaik you have to explicitly link the filesystem library with '-lstdc++fs'.

@pdimov

pdimov commented Oct 28, 2018

Copy link
Copy Markdown
Member

If that's true, these changes will break boostdep on g++ 8.

@Mike-Devel

Copy link
Copy Markdown
Contributor Author

You mean because the cmake file will link to boost, but main.cpp will compile against std::filesystem?
I think you are right. Sorry, didn't think this through. I'm not at a dev machine right now, but I can provide a fix tomorrow or the day after.

@pdimov

pdimov commented Oct 28, 2018

Copy link
Copy Markdown
Member

Same when using b2 - the source will try to use <filesystem> and fail to link.

Is this worth the trouble? :-)

@Mike-Devel

Copy link
Copy Markdown
Contributor Author

The fix seems straight forward: Don't detect std::filesystem in source, but ifdef on a flag set by the build system.

I'd consider it worth the trouble to propose the PR, because other than b2, cmake can't trigger the build of boost filesystem on demand (yet). Whether it is worth the trouble for you to review and maintain it I don't know.

Comment thread CMakeLists.txt Outdated
else()

message(STATUS "Using Boost::filesystem as filesystem library")
if( NOT TARGET Boost::filesystem )

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not fond of if TARGET because it's order-dependent.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. Shall I remove it?

@Mike-Devel Mike-Devel force-pushed the std_filesystem branch 2 times, most recently from 5f3aba3 to 88ac1c4 Compare November 2, 2018 11:37
@Mike-Devel

Copy link
Copy Markdown
Contributor Author

So, I removed the check for the boost::filesystem target and added a test to travis to make sure my changes don't break gcc 8. Do you think it is worth it to integrate into the main repo? If so, any other changes you want me to make?

@pdimov

pdimov commented Nov 2, 2018

Copy link
Copy Markdown
Member

The fact that dist/bin/boostdep --list-exceptions apparently doesn't output anything (https://travis-ci.org/boostorg/boostdep/jobs/449797943) worries me a little, but I don't have time to investigate.

Apart from that, were I to integrate this, I'd probably drop all autodetections and just let the user choose -DBOOSTDEP_USE_STD_FS.

@Mike-Devel

Copy link
Copy Markdown
Contributor Author

The fact that dist/bin/boostdep --list-exceptions apparently doesn't output anything (https://travis-ci.org/boostorg/boostdep/jobs/449797943) worries me a little, but I don't have time to investigate.

Last time I checked, develop and master had the same problem, so I ignored it. It seems to be fixed on develop - will investigate why it still fails on this PR.

@pdimov

pdimov commented Nov 2, 2018

Copy link
Copy Markdown
Member

No, they don't have this problem. The job fails because the exceptions differ, but it doesn't fail - like here - because the output is completely missing.

@Mike-Devel Mike-Devel force-pushed the std_filesystem branch 2 times, most recently from 2ce5c52 to 82b7665 Compare November 5, 2018 11:54
@Mike-Devel

Copy link
Copy Markdown
Contributor Author

OK, so I found the error: I accidentially inverted an if <is_folder> condition.
I also removed the fs autodetection from cmake and simplified the file as much as possible.

The main remaining problem with this PR - as far as I can tell - is that no CI check actually covers the std::filesystem path, as I'm not sure how to best hook this up to appveyor. Do you have a suggestion? Or can you add that check yourself?

@Mike-Devel

Copy link
Copy Markdown
Contributor Author

Ping.
Is there any interest in this or should I just close it?

@pdimov

pdimov commented Dec 8, 2018

Copy link
Copy Markdown
Member

Keep it open.

Hasn't the CMake community figured out how to link to stdc++fs or c++fs automatically as required?

@Mike-Devel

Copy link
Copy Markdown
Contributor Author

Not that I know of. Here is some information on the topic: https://gitlab.kitware.com/cmake/cmake/issues/17834.

Seems it is less a question of how to do it, but more if they should/want to do it.

@pdimov

pdimov commented Dec 8, 2018

Copy link
Copy Markdown
Member

std::filesystem isn't present in the 7.x branch, and I hope it will be part of libstdc++.so in the 9.x branch, so it should only be needed for 8.x releases.

Sounds like the GCC problem will be going away, but libc++ meanwhile decided to add libc++fs as well.

@pdimov

pdimov commented Dec 8, 2018

Copy link
Copy Markdown
Member

Or maybe not. https://wandbox.org/permlink/tlXI44j9XzL7XUqr

@Mike-Devel

Mike-Devel commented Dec 10, 2018

Copy link
Copy Markdown
Contributor Author

Considering that gcc still requires -latomic in some scenarios, I won't hold my breath for them to "fix" the -lstdc++fs requirement.

@Mike-Devel

Copy link
Copy Markdown
Contributor Author

std::filesystem seems to work with latest trunk versions of clang and gcc (according to the wandbox link you posted). So I guess there is hope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants