-
Notifications
You must be signed in to change notification settings - Fork 68
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
Starting on new port #309
Comments
|
Been working on this for a couple of weeks, and the cmake stuff now compiles the kernel section. But I noticed I don't appear to be able to "deploy" to the target-VM from VC when it is in CMake style, so that is a bit of a show stopper. |
OK so, it seems I can use Cmake files to produce vcproj files, using:
and loading that .sln into VC. Which would take care of debugging and deploying. However, I see that the "clang can't make drivers" is now an issue. If I play with the produced project files, it will use clang fine, but only to generate an "application". The answer there is possibly to have cmake generate all the libs (libkernzfs, libkernspl, ...) with clang, and finally compile |
OK, flipping it around, the module will use MSVC cl.exe to compile, and each library, as in spl, zfs, spi etc, has:
which compiles the libs with clang, makes porting easy. Then for I do wonder if I can make that cleaner, since I have to put those lines in 10 odd files, and there are a few compiler options to set. Wonder if CMake can do functions from toplevel file and I can just "SetClangCompiler" or something, so there isn't so much repetition. |
@lundman Not sure if it's legal in CMake. Clean way would be to have two root I am not sure why clang can't build |
In stackoverflow they said:
Two top level cmakes? How does that work, it just automatically builds both, figuring out dependency? |
Isn't There is |
Could be just linking would work, but I discovered the cmake -G "Visual Studio" generated projects files are wrong, made as "Application" and not kernel extension - and I don't see a way to "add" kernel debugger parts, so I can not deploy. Not entirely sure what to do about it. Wondering if I can make a shell project now that just deploys an already built .sys file. (build by cmake, then just deploy from project files). |
@lundman do you have a release plan for this new port given that the upstream OpenZFS 2.0 is planned to be released this month? |
OKOK I could not get any of those things to work. But for now, top level CMake to build openzfs.sys. This will be enough for most. |
So looking at the re-organisation of files to fit in with OpenZFS 2.0 repo.. no code changes, just a bunch of renaming, and moving functions around between files.
But it would be nice to get some comments.
*) There are currently two build systems, the (Windows) make files, and devstudio projects. Is it common to maintain two build systems? Can they be made from the other? Can devstudio import makefiles, or, create a solution that just runs the makes?
*) clang now optionally ships with devstudio. Would it be acceptable to switch default build to clang? It would simplify quite a few things. Can it be done as a selection in devstudio? Where you pick x64/x32/arm/clang_x64 ?
*) I'm not a fan of how you define the macros for build, like we set _KERNEL, DEBUG, __LP64, in devstudio properties - It would fit better like upstreams "-include zfs_config.h". Which clang supports, but perhaps not MSVC++.
Would any of these decisions impact you? What is the "norm" for Windows dev? What we have in ZFSin works, but here's a chance to change things, should there be better ways.
The text was updated successfully, but these errors were encountered: