Skip to content

[WIP] initial build of GVFS provider for Linux#810

Closed
chrisd8088 wants to merge 13 commits intomicrosoft:features/linuxprototypefrom
github:linux-gvfs-initial-build
Closed

[WIP] initial build of GVFS provider for Linux#810
chrisd8088 wants to merge 13 commits intomicrosoft:features/linuxprototypefrom
github:linux-gvfs-initial-build

Conversation

@chrisd8088
Copy link
Contributor

@chrisd8088 chrisd8088 commented Feb 20, 2019

Please DO NOT MERGE -- this is a WIP branch to debug issues getting the GVFS provider to build and run on Linux.

(Note to @jrbriggs et al: I'm opening this PR because I want to see if this passes the CI checks on Mac and Windows; there may well be additional things I need to tweak in the tooling before it does. Thanks and apologies!)

This is largely a duplicate of the macOS build tooling and platform-specific code, with some changes to ensure we build successfully on Linux (e.g., testing for '$(OS)' != 'Windows_NT' is no longer sufficient to determine that the platform is OS X).

Note that for now the BuildGVFSForLinux.sh script exits early, without checking if a native libprojfs library is available, performing any installation or packaging, etc.

The GVFS.sln configuration changes should ensure that the ProjFS.Linux.Managed and GVFS.Platform.Linux subprojects are built on all platforms (and the Mac and Windows equivalents
are built on Linux), so as to allow the GVFS.UnitTests project to build on Linux, as it seems to do multi-platform unit testing.

However, we don't yet require the GVFS.Mount.Linux project to build on other platforms, and the GVFS.FunctionalTests project's configuration and dependencies will also need to be revisited
once the Linux code is actually functional.

/cc @kivikakk @wrighty

@chrisd8088
Copy link
Contributor Author

Huh, OK -- well, that passed CI, somewhat to my surprise!

@jrbriggs, @wilbaker, et al -- would you be able to check that you can still load things in Visual Studio, run builds on Windows and Mac, etc., with these changes? And if they look OK, merge them (or make suggestions as necessary)?

Thanks very much!
Chris.

@kivikakk
Copy link
Contributor

I've opened a PR that stacks on top of this one at github#4 which extracts GVFS.Platform.Posix from the commonalities between Mac and Linux. Let me know what you think; it should make supporting the two similar platforms less of a maintenance burden.

@jrbriggs jrbriggs force-pushed the features/linuxprototype branch from e8eb0a6 to ebec5f1 Compare February 28, 2019 20:23
@kivikakk kivikakk force-pushed the linux-gvfs-initial-build branch from 7355332 to 17928ab Compare March 1, 2019 03:12
@kivikakk
Copy link
Contributor

kivikakk commented Mar 1, 2019

This PR has been rebased (as of the reset in #818).

@kivikakk kivikakk force-pushed the linux-gvfs-initial-build branch from e1dee1c to 130fa35 Compare March 1, 2019 06:01
@kivikakk
Copy link
Contributor

kivikakk commented Mar 5, 2019

@jrbiggs I've refactored the Linux and Mac platforms into a common base in this PR; seeing as this may not get merged for some time, the drift in the Mac platform will make rebasing this painful, as most of the changes will need to get moved to the Posix platform.

Would you accept a PR to master that did the refactor without introducing the Linux platform? This would make the eventual PR to merge Linux into the mainline much less fraught.

@jrbriggs
Copy link
Member

jrbriggs commented Mar 7, 2019

Hey @kivikakk sorry for the delay. I like the idea of just doing the Posix refactoring in this PR and deferring the Linux work. I'm going to start reviewing this today. The biggest concern I have after the initial look is the introduction of the Mono dependency that would now be shipped on the Mac. Can you tell me more about why we need this? Could we defer that introduction until we have done the rest of the platform refactoring, with the introduction of the Linux platform? I think that would help focus the goals of each PR. Thanks!

@chrisd8088 chrisd8088 force-pushed the linux-gvfs-initial-build branch 3 times, most recently from ca7819c to ab13aa6 Compare March 12, 2019 21:56
@kivikakk
Copy link
Contributor

Could we defer that introduction until we have done the rest of the platform refactoring, with the introduction of the Linux platform?

Happy to! I'll get a PR up for that soon.

@kivikakk
Copy link
Contributor

➡️ #926

chrisd8088 and others added 2 commits March 14, 2019 01:32
This is largely a duplicate of the macOS build tooling and
platform-specific code, with some changes to ensure we build
successfully on Linux (e.g., testing for "!= Windows" is no longer
sufficient to determine that the platform is OS X).

Note that for now the BuildGVFSForLinux.sh script exits early,
without checking if a native libprojfs library is available,
performing any installation or packaging, etc.

The GVFS.sln configuration changes should ensure that the
ProjFS.Linux.Managed and GVFS.Platform.Linux subprojects
are built on all platforms (and the Mac and Windows equivalents
are built on Linux), so as to allow the GVFS.UnitTests project
to build on Linux, as it seems to do multi-platform unit testing.

However, we don't yet require the GVFS.Mount.Linux project
to build on other platforms, and the GVFS.FunctionalTests project's
configuration and depedencies will also need to be revisited
once the Linux code is actually functional.
Since the GVFS.Mount.Mac project is also built for Windows,
build the Linux counterpart as well.

Co-authored-by: Ashe Connor <ashe@kivikakk.ee>
@chrisd8088 chrisd8088 force-pushed the linux-gvfs-initial-build branch from 1390343 to 0f7f437 Compare March 14, 2019 08:32
@chrisd8088 chrisd8088 changed the title Linux: initial build of GVFS provider for Linux [WIP] initial build of GVFS provider for Linux Mar 19, 2019
Upgrade the required libgit2 native binary to the latest
LibGit2Sharp.NativeBinaries release (2.0.267), as recent
NuGet packages eliminate most external dependencies other than
OpenSSL, and the OpenSSL dependency no longer requires an older
version of that library with now-deprecated CURL_OPENSSL_3 symbols.

This allows us to include the compiled libgit2.so from the
LibGit2Sharp.NativeBinaries NuGet package in our Linux build.
As we ported this code from the macOS implementation which uses
BSD sizes and constants, they need to be revised for Linux.
@chrisd8088 chrisd8088 force-pushed the linux-gvfs-initial-build branch 3 times, most recently from 551e24e to e1a3ffa Compare March 27, 2019 05:32
As with commit 256334e, we need to
revise the size of the mode_t type for Linux (as we ported this code
from the Darwin/BSD version), as well as change the order and size of
data fields in the stat(2) structure and the function signatures of
various libc calls such as chmod() and read() to confirm to their
Linux definitions.
Also add a TODO note regarding the git.cmd script which is ignored
on Linux as it's not in $PATH and also not named "git".
Rename common.mac.cpp to common.posix.cpp so it can be used as
a basis for Linux hook programs as well.
Note that we need to include <string.h> for the hook programs'
C++ code to compile, at least on some Linux systems.
Also fix our out-of-date and previously unused copy of
GVFS.Hooks.Linux.csproj so it fully aligns with the Mac version.
The storage configuration file is unique to Linux and will be
read at mount time to locate the lower storage directory.
@chrisd8088 chrisd8088 force-pushed the linux-gvfs-initial-build branch from bd65c2a to 1e706e5 Compare March 29, 2019 00:20
@chrisd8088 chrisd8088 closed this Mar 30, 2019
@chrisd8088 chrisd8088 deleted the linux-gvfs-initial-build branch March 30, 2019 23:52
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.

3 participants