This repository has been archived by the owner on Feb 3, 2022. It is now read-only.
Add command line switches to hptool for additional archives needed for Windows #289
Assignees
Comments
|
adding switches for all things sounds good. |
|
Good, then we shall add switches for the currently-positional parameters, as well. |
randen
added a commit
to randen/haskell-platform
that referenced
this issue
Jun 15, 2018
Fixes haskell-platform issue haskell#289 by removing all positional parameters from the command line for the hptool, replacing them with all with explicit switches, and adding new command line parameters via new switches in order to specify additional inputs needed for the Windows version of hptool. Fixing haskell#289 should make it a little easier to get the Windows HP builds to include the correct documentation and other ancillary files. Unit testing is introduced to the hptool package with this commit, which is immediately useful to the new command line functionality, but should be useful for future work as well. * hptool/hptool.cabal * To accomodate unit tests, break hptool up into a library that both the executable and the unit tests can reference. Also, add the new files introduced, and handle building the unit tests. * hptool/os-extras/win/templates/Nsisfile.nsi.mu * Update the doc short cuts which are created during installation, to track how GHC docs are currently structured. * hptool/os-extras/win/templates/index.html.mu * New. The template to use for the overall index.html file for the installed GHC docs. * hptool/src/CLArgs.hs * New. Handles the new command line argument processing. * hptool/src/Config.hs * Add to the Oracle, the new parameters that come from the command line, keeping them in a UserConfig. * hptool/src/Internal/CLArgs.hs * New. A separation of CLArgs functionality which allows the unit tests to access non-exported functions. * hptool/src/Main.hs * Replace the command line processing using the new CLArgs module, while updating the usage message, and connecting the args with the oracle. * hptool/src/OS/Win/WinNsis.hs * Rather than use a index.html file that has to be updated by hand for each release, use a template to generate one. * hptool/src/OS/Win/WinPaths.hs * Add paths for the index.html and its template. Remove the winExternalDocs path, since it is now unused. * hptool/src/OS/Win/WinRules.hs * Rather than copy a hand-crafted directory into the release, grab the appropriate pieces as specified by the user from the command line args (and pushed into the oracle), and untar those into the release instaed. * hptool/src/Package.hs * Compiler warning. * hptool/src/Types.hs * Add two types, BuildFlavor and UserConfig, for storing the user command line args. * hptool/tests/UnitTests.hs * New. The main unit tests file, which will invoke the sub-tests (so far only one: CLArgs) * hptool/tests/UnitTests/CLArgs.hs * New. Tests the new command line parsing/handling. * windows-platform.sh * Some updated paths; update the messages to match the new params; update the sanity checks; add a time stamp to start and end.
randen
added a commit
to randen/haskell-platform
that referenced
this issue
Jun 15, 2018
Resolve Windows installer should add MSYS to extra-prog-path/extra-lib-dirs/... (haskell#279). When the installer runs, Windows elevates the process, when possible, to the role of admin. If the installer writes the cabal.config under these privileges, the cabal.config file will have the wrong permissions for the end user. So, we must separate the privilege escalation, and perform the cabal.config change as the end user. A new sub-installer (not visible to the end-user) is introduced which performs this task, and also launches the full installer, which will get (when possible) raised privileges. As before, the full installer then launches the sub-installers. Add command line switches to hptool for additional archives needed for Windows (haskell#289) The GHC sub-installer has grown over the NSI 2GB uncompressed raw payload limit, so another split was done, breaking the GHC docs out into a separate sub-installer. As before, the sub-installers are not end-user visible (unless they looked really hard). * hptool/hptool.cabal * Add constraint to Cabal package for vers 2.2, as the cabal files generated during the build (by invocations of cabal.exe) have some changes which are not parsable with earlier versions of Cabal. * hptool/os-extras/win/templates/Bootstrapper.nsi.mu * New. This bootstrapper exists for one feature (currently) which must be done as the user, which is to write update/create the user's cabal config file. * hptool/os-extras/win/templates/CommonHP.nsh.mu * New. A few macros common to our (sub-)installer(s). * hptool/os-extras/win/templates/Extralibs.nsi.mu * hptool/os-extras/win/templates/GHC.nsi.mu * hptool/os-extras/win/templates/MSys.nsi.mu * Deleted. Replaced by using a common SubInstall.nsi.mu to generate the .nsi files for the sub-installers. * hptool/os-extras/win/templates/Nsisfile.nsi.mu * This is the "main" installer, which runs as an admin if possible. However, it is launched by the "Bootstrapper" installer (which continues to run as an unprivileged user). We want this main install to have its windows be on top of other windows. This installer handles all the user interaction, so if the user chooses not to have the cabal.config file updated, this installer needs to communicate back to the Bootstrapper that. So, when this main installer is successful (not cancelled by user or an error) *and* the user has chosen to update the cabal.config file, it returns to the shell a magic value 3 (rather than 0 or 1 for failure/success, respectively). * Moved some macros to CommonHP.nsh * Add some macros to do the sub-installer steps, and remove/edit the repeated steps which now use the macros * Add some "BringToFront" commands to try to make sure the installer window ends up on top of the windows stack. * Use nsExec::Exec rather than ExecWait, to get rid of the DOS window that shows up when we are running the ghc-pkg recache. * During the install, use the TEMP dir to hold the uncompressed installer payload (we already were doing this for the uninstaller). * hptool/os-extras/win/templates/SubInstall.nsi.mu * New. Templatized version of the sub-installer .nsi files (Extralibs.nsi.mu, GHC.nsi.mu, and MSys.nsi.mu, which are deleted), used to generate the .nsi for the Extralibs, GHC, Msys, and the new GHCDoc sub-installers. * hptool/src/GhcDist.hs * Pass in a param to allow the multiple untarrings of GHC to be named independently (which allows parallel untarring). * hptool/src/OS/Win.hs * Move most of the steps from osRules into genNsisFiles time, so that parallel building can be done shake. * hptool/src/OS/Win/WinNsis.hs * Use the SubInstall.nsi.mu to generate the sub-installer nsi files, rather than using separate files for each. * In adding the sub-installer, we added a couple more template variables which need expanding, and this requires a bit more info to be threaded through. * Add a new sub-installer, GHCDoc, needed since the main GHC sub-installer has again went over the NSI limit of 2GB (uncompressed, raw payload). * Re-order some steps, taking some from the function osRules in Win.hs, to reflect better dependencies and thus allow more parallelism in the shake build. * The function copyWinTargetExtras is moved from WinRules to this module. * hptool/src/OS/Win/WinPaths.hs * Filename re-working due to the new sub-installer template, CommonHP.nsh, plus adding the new GHCDoc sub-installer and the "Bootstrapper.nsi". * hptool/src/OS/Win/WinRules.hs * Add the FilePath for the top-level output (the "main" installer) to the winRules, so this can be passed to genNsisFiles. * Change the command which takes the untarred ghc directory and allows it to moved to a specified location, which is part of the change to allow the installer build to do the two ghc untars in parallel. * Move copyWinTargetExtras from here to WinNsis.hs * copyFileAction, copyFilesAction, copyDirAction moved to WinUtils in order to to move the body of copyWinTargetExtras into WinNsis. Note that WinRules imports WinNsis, so these common functions needed to be in a module separate from either. * HPTOOL/src/OS/Win/WinUtils.hs * copyFileAction, copyFilesAction, copyDirAction moved here from WinRules, which imports/exports fixed up accordingly. * hptool/src/Paths.hs * Add an extra parameter for ghcBinDistDir in order to name the ghc bin dist directory differently for the two times we have to untar the ghc tar file, which allows those two un-tars to be done potentially in parallel. * hptool/src/Target.hs * Separated two targets, "ghcVirtualTarget" and "haddockDocDir" so they won't be done in parallel (we really need to go through the dependencies of this entire project, as there have been a few occasional things, e.g., sometimes timing-dependent behavior of dependencies not being available when needed, etc.) * Added missing newline at end-of-file. * hptool/src/Utils.hs * Added a log message during makeDirectory. * windows-platform.sh
|
The new command line arguments: Most of these are for the Windows builds, but the main ones will affect the other platforms. Here is an example for building Windows 64-bit core HP:
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Background:
The Windows build of Haskell Platform has always used some static (but relative to the build) directory locations for ghc documentation, which itself is due to the fact that we do not build ghc for the Windows HP but instead use a pre-built archive (which does not include all the documentation). The hptool continued that tradition of using the static locations. Well, that has bit us on a couple of releases, when I forgot to manually update those directories with the latest docs.
We should add some additional command line switches, applicable to the Windows version of the hptool, which will be used to designate archive files for the ghc docs.
There are 4 files needed:
Uncompressing and untarring these additional archives will take a more execution time for hptool when building HP releases.
Another thing to note is that the hptool currently uses some positional arguments for the ghc archive, stack installer, and the cabal executable. Rather than continue this positional parameters (which is a bit unsafe and might result, e.g., in the cabal and stack files being swapped), I will at least add switches for the new pieces needed for Windows. I could make switches for the other 3 which are currently positional, but it would mean hptool user's would need to change their scripts or hand-written notes, etc.
The changes visible to the hptool user would be these switches. Internally, the Windows specifics in the hptool would need to add to the configuration to store these new parameters, rules to do the uncompression and untarring, and a place to invoke those rules (within an existing rule that allows build platform-specific behavior).
The text was updated successfully, but these errors were encountered: