LinearTapeFileSystem
Windows Annex K. Function Integration
Is your feature request related to a problem? Please describe. Microsoft suggests using Annex K. Functions when using Microsoft Visual C++ Compiler. These functions should be implemented only for compilation in Windows since Annex K. Functions on Linux systems are not required.
Describe the solution you'd like Create a glue layer to bind Annex K Functions with a ltfs naming convention where the Windows platform is used. Using inline functions where needed and macros where there is no other solution. Current solution is implemented on branch v2.4.8-windows and the final result expected is it to merge a final solution to 2.4-stable
Additional context Using Microsoft Visual C++ Compiler is also suggested to be the compilation tool for the Windows platform. The value for the oss community is to have security best practices implemented for Windows users. The principal issue and discussion are that this makes the code less readable for new users since they would need to understand ltfs approach on this.
I believe Annex K thing is a part of "making this tree compilable on windows with free version of the visual studio".
Using Annex K has no value if you just use it on this repository.
In other words, using Annex K is not an objective, it is just needed by compiling this tree on windows with free version of the visual studio.
So you mean it should not be merged with the current stable branch?
I agree the solution proposed is only functional to the Windows users of this project.
So you mean it should not be merged with the current stable branch?
I cannot understand what you are saying. What should be merged you think? v2.4.8-windows-support branch?
If a PR includes windows build support for libltfs, I will accept the PR against any branch.
I agree the solution proposed is only functional to the Windows users of this project.
I believe I'm saying only one thing. What is the points you disagree. Please clarify.
I cannot understand what you are saying. What should be merged you think? v2.4.8-windows-support branch?
v2.4.8-windows-support to 2.4-stable.
If a PR includes windows build support for libltfs, I will accept the PR against any branch.
What would you describe as a windows build support for libltfs?
I believe I'm saying only one thing. What is the points you disagree. Please clarify.
I think this PR currently has advantages for windows users, and maybe we can get to a solution to get it more refined.
What would you describe as a windows build support for libltfs?
Clone the v2.4.8-windows-support branch and build the libltfs DLL and the unified ioscheduler DLL by the visual studio community.
I think this PR currently has advantages for windows users, and maybe we can get to a solution to get it more refined.
I don't think so because "windows user" I mean is that developers who wants to contribute this project not a consumer who are using LTFS binary provided from IBM.
Clone the v2.4.8-windows-support branch and build the libltfs DLL and the unified ioscheduler DLL by the visual studio community.
So, in this case, having the configuration file to support the compilation of libltfs and unified DLLs on Visual Studio will mean we support it properly?
Yes. To be more clear.
A developer can create 2 DLLS. libltfs.dll and libiosched-unified.dll by the procedure below.
- Clone this repository
- Open the solution file by the visual studio community
- Run "Build"
- 2 DLLs are generated correctly on somewhere in the tree
I believe this must be is the first step of windows support.