-
Notifications
You must be signed in to change notification settings - Fork 674
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
Dokan_fuse build system enhancements #337
Conversation
@jetwhiz, can you give this a try once Appveyor has finished the compilation? The fuse-mirror-compilation actually tests this, but given that we are so close before 1.0.0 it would be nice to have another human-being taking a second look at it. One should be able to compile against libfuse or dokanfuse only by changing the include path and linker-path, i.e.
|
Also everyone else is welcome to review the individual commits and test the build, of course. Especially the installer might need attention, because that is an area I am not familiar with. I don't want to be the one that introduces a regression so close before 1.0.0 :-D |
Hi @Rondom -- I'll give it a shot! Can I build this using Visual Studio, or does this need to be done using Cygwin for the test? |
Compiler does not matter as long as you link to the right library (dokanfuse.dll for MSVC, libdokanfuse.dll for MinGW, cygdokanfuse.dll for CygWin). |
71adc37
to
543a4b5
Compare
@jetwhiz I messed up on the installer. 😳 It should be fixed now. Please download again. |
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.
@Rondom you removed dokanfuse.h, fusemain.h, scopehuard.h and utils.
For you they are not needed by someone wanting to link against the library ?
I thought they were C++ headers internal to dokan_fuse. Are they considered part of the API? If they are, they should be there of course. Oh, and can someone enlighten me what this ScopeGuard C++-template-craziness does? 😝 |
@Rondom -- I'm not sure if I'm doing something wrong, but when I replace the system32 dll files with the ones built from this branch, encfs4win dies. Dokan: debug mode on
Dokan: use stderr
AllocationUnitSize: 512 SectorSize: 512
Dokan Error: CreatFile Failed \\.\Dokan_1: 2
send global release for Z:
Dokan Error: Failed to open \\.\Dokan_1 with code 2
Failed to unmount: Z: |
Updating the driver as well should fix this. This was unfortunately necessary because of #320. |
@Liryna Indeed some of the stuff might be useful, other stuff looks more internal, especially the stuff relying on C++. Does someone have an idea or suggestions, about what is useful and what is internal? |
Unfortunately I'm not able to build the drivers in the project, since I don't have enough disk space to install the WDK 10. Do you have an already-built one for Windows 7 x86 prepared? Or maybe you could provide me with the branch's Dokany installer and I can install everything fresh. |
Oh! No need to build yourself. Appveyor is building binaries for every pull request and push. You can easily reach the Appveyor-builds by clicking the green ✓ next to the latest commit in the Pull-Request. Link to the artifacts of the at the time of this writing latest build of this PR |
@Rondom I have been able to build fusexmp.c on cygwin with your install package without issue 👍 There is only utils.h that should be added in the installer. It has some helper that provides the library and it is used by some projects (@jetwhiz does use it if I remember).
You know what ? I removed ScopeGuard.h, rebuild, and nothing happened 😄 Good job @Rondom 👍 and big ❤️ to the (there is a couple of warnings showed with https://github.com/dokan-dev/dokany/pull/337/files#diff-e2cb466c3a4e3af410a8719f1f2b0340R10, do you plan to fix it ? otherwise I will do it after) |
@Rondom -- I did a bit of testing using the PR artifact installer and didn't notice any problems that stood out on my end when running encfs4win. Regarding the PowerShell-script, unfortunately I don't have access to a Win 7 build machine -- I only do bare-bones testing in a pristine Win 7 VM. Does using CertMgr not work when Import-Certificate isn't detected? |
Ok, I will add back utils.h to the installation. This is a C++ header, shall I #ifdef things and disable symbol-mangling for the C-parts, so it can be used both in C++ and C (minus the C++ parts)? I will also delete ScopeGuard.h. I do not have the energy to find out myself, but I am still curious about what it does. ;-)
I intentionally enabled the warnings. Sometimes warnings point out things one is not aware of that should be fixed. If there are warnings that cannot be fixed, we can always disable individual warnings. |
@jetwhiz CertMgr.exe DOES work (see the wiki-article a few lines above). The only "problem" is that you need to download VS or Windows SDK to get these few kilobytes of an EXE which is a bit overkill. Copying over CertMgr from another machine with VS, works like a charm and so does using the GUI. :-D |
@Liryna I will also remove dokany/dokan_fuse/include/utils.h Lines 8 to 12 in 4d11614
The code is commented and not used anywhere as far as I can see. |
Yes this would be great! |
@Rondom I will provide you a patch for the build warnings tomorrow morning. I would like to make the release tomorrow. |
First thing I will do in the morning |
@Rondom here is the patch: |
If one build-command fails the other build commands wil still be run, but the script will exit with a non-zero errorcode once all commands are finished.
We still default to Release for CMAKE_RELEASE_TYPE, but if another value is specified on command line, we honour that.
This adds an install target that installs the headers in the same directory structure as libfuse. This makes it easy to support compiling against either libfuse or libdokanfuse1 from the same codebase. This fixes dokan-dev#250 for manual compilations under Cygwin or for MingW.
This is a rework of the dokan_fuse build-script: * out-of-tree build to avoid fragile deleting of files * use install target for "installation" into target-dir * fix MinGW output by calling bash directly, this makes the output visible on command-line. Closes dokan-dev#333. * return non-zero error code in case any of the commands fails
Installs the public FUSE headers in a directory structure that resembles that of Linux FUSE. Linux FUSE requires a fuse.h in the top-level include-directory. Closes dokan-dev#250.
DWORD and ULONG are defined as unsigned long int on Windows. Cygwin64 is LP64. Thus it defines them as unsigned int (to keep them 32-bits wide). In order to enable portable printing, we define macros modeled after inttypes.h like for example PRIuDWORD or PRIxDWORD. Using these macros ensures that the correct printf-format-specifier is used depending on the platform.
The file was not used anywhere in the code. So it is safe to delete it.
543a4b5
to
038c0d4
Compare
Disable symbol-mangling for the C-parts of utils.h to enable using some utility functions from C as well.
What I have tested:
Not tested:
|
Thank you @Rondom for making this and in time 😃 ! 👍 Let's the release begin ! |
One nitpick, can you (manually! don't delay the release further) add the version number to each file's filenames when you do the release? I think it is nicer that way because it keeps people's download-folder nice and tidy. i.e. DokanSetup-1.0.0.5000.exe and so on. |
@Rondom Alright I will do this 👍 |
Make sure this is mentioned in the changelog |
👍 I will do it Currently I have issue to build fuse on my windows 😢
did you face the issue ? If I run C:\cygwin\bin\bash outside the script it work 😢 |
Blind guess: Do you have multiple versions of Cygwin running? Did you upgrade today? Try a reboot to make sure no old stuff is loaded. |
Yes |
This branch contains changes that unify the directory structure of dokan_fuse. This enables compilation of the same code base against either dokanfuse or libfuse without changes.
We are also adding an install target so one can "install" dokanfuse into a Unix-directory hierarchy (Cygwin, MSYS, MingW-crosscompile under Linux) when compiling oneself.
In addition to that this branch contains commits that make build scripts return a non-zero error code in case one of the build-commands fails.
This work has been sponsored by Intel Corporation.