This repository was archived by the owner on Feb 3, 2022. It is now read-only.
Fix #289, #279; Windows-specific changes for 8.2.2, 8.4.2 #308
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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
Shuffling the path components left hscolour out, which is needed for building the source documentation. (Remember, the specific paths here would needed to be changed for who ever is running them.)
The changes for haskell#279 (Windows installer should add MSYS to extra-prog-path/extra-lib-dirs/...) broke silent installs. * hptool/os-extras/win/templates/Bootstrapper.nsi.mu * Force /D= to the launched sub-installer to fix haskell#311 * Add many comments about the weirdness of handling $INSTDIR
Most of the changes were to derive some instances that allows
us to place nicely with shake. The 0.16-required changes
were to define some type instances in our "oracle".
* hptool/hptool.cabal
* need shake >=0.16 now
* hptool/src/Config.hs
* Previously, all of the oracle data types were smashed
into strings (if they were not already), but shake allows
them to be any type, so by deriving some instances in
Types.hs for the non-string data items which are in the
oracle, we can simplify some of this module.
* For each type of item stored, we did need to add a type
instance of RuleResult (part of the changes needed for
shake 0.16).
* Provide an Eq instance for the Release structure, to
account for the lists it contains.
* Some lines were shuffled to restore the grouping of
newtype's with the function that uses each.
* hptool/src/Types.hs
* Derive instances of Eq, Generic, Hashable, Binary, NFData
for the data structures (and any nested structures) which
we store in the oracle mechanism.
…ws 10
When cabal is invoked during an HP build, we will set and use
a default cabal config file.
* hptool/src/Target.hs
* Entries from the build-machine-user's cabal config file
are copied into the <package>.conf files. We need to
insulate against this inadvertent pollution of the built
packages. So, with each cabal invocation, specify a path
to a cabal config file to use. The first time cabal
runs, it will create this file with all defaults, and
that file will be used for all the other uses of cabal
during the HP build.
Using cabal-install 2.0, if a "cabal clean" is done on a
non-existent directory, it will successfully complete. In
cabal-install 2.2, "cabal clean" on a non-existent directory
will fail (on Windows, at least) with "dist\build:
getDirectoryContents:findFirstFile: does not exist (The
system cannot find the path specified.)" So, we will
temporarily work around this by creating the directory if it
doesn't already exist, before we invoke "cabal clean".
* hptool/src/Target.hs
* use createDirectoryIfMissing (via Util.makeDirectory) to
create the directory about to be "cleaned" if not already
there, to work-around the cabal issue.
|
(Mentioning, with Github-recognizable syntax, the haskell/cabal#5362 issue.) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix issue #289, Add command line switches to hptool for Windows
Fix issue #279: add MSys to user's cabal.config
NOTE: The changes for adding/changing the command line switches will affect the other build environments. Issue #289 includes the changes, but in summary, the --Xc, --Xf, --Xg, --Xs, --Xx will likely be needed, replacing the positional (and some flags) params from before.
NOTE: There are some changes here which aim to help allow shake to run parallel actions. Using shake's "-j" switch (which hptool accepts, as it is shake which processes the arguments first) can control how many parallel threads are used. Also, cabal will run its own build steps in parallel when it can, depending on its own "jobs" parameter from the user's cabal config file.