Windows installer #4
Conversation
nhorman
requested review from
levitte,
hlandau,
t8m,
t-j-h,
mattcaswell and
paulidale
nhorman
force-pushed
the
windows-installer
branch
3 times, most recently
from
72b64ff
to
5c21d00
Compare
It occured to me that we can simplify the installer greatly by running the install command for each binary set, and just doing a recursive file copy in the installer for x64 and x32. This is adventageous as it lets us package whatever configuration we built, and will include any files created as part of the install in the future. It also makes the installer script significantly smaller
| - name: config x32 | ||
| working-directory: openssl/_build32 | ||
| run: | | ||
| perl ..\Configure --banner=Configured no-makedepend enable-fips VC-WIN32 |
There was a problem hiding this comment.
Do we need to specify the openssldir here? Not sure what it defaults to on Windows - but you are installing in a directory which includes the version number
There was a problem hiding this comment.
I don't (think) so. We could, but I believe the same output results from specifying DESTDIR during the install command
There was a problem hiding this comment.
Hmm. I don't think that is the case. The openssldir is used for certain compiled in locations used by the libraries at run time. So if you plan to install to a non-default location then I think you need to specify it.
There was a problem hiding this comment.
Based on our refinement conversation today, I've created the following issues:
openssl/project#550
openssl/project#551
If we can get this merged, I can follow up and get us using registry keysto dynamically determine OPENSSL_DIR and do directory permisssions checking
|
nmake install places the dlls in the bin folder, alongside the executables, which is what makes the running of openssl in a shared build work, based on the library search path order. The only thing I see that goes in the lib folder are the static libs |
There was a problem hiding this comment.
Approved on the basis that openssl/project#550 and openssl/project#551 will resolve outstanding issues
|
Ping @t8m for second review |
t8m
added
the
approval: done
As part of openssl/project#20 I've created this draft PR to propose a windows installer framework. The installer currently:
This PR expressly omits any official building of the installer, as we need to determine how we would want to manage code signing certificates, as well as how we want to incorporate the building and releasing of the installer as part of our release process, but I think the installer itself is in pretty good shape. My proposal would be to incorporate this PR in 3.4 and target 3.5 for integrating a signed installer release into the 3.5 development cycle