Re: MSYS2 package for GHC 7.10.1
With the helpful pointers from ezyang on IRC, I pushed this a bit forward. I converted most of the patches into more reasonable commits including short descriptions and created a git branch for it. See https://github.com/ghc/ghc/compare/ghc-7.10.1-release...elieux:msys2-pkgbuild. As mentioned previously, the changes should be uncontroversial except for two big changes: removing bundled mingw, perl and touchy and changing the directory layout. While the directory layout change is mostly self-contained (barring any tools hardcoding ..\lib), the bundled dependency removal will required major changes to the build process. My proposals follow. For hacking on GHC == 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Get a GHC repository ready 3. Hack, hack, hack 4. Build and test as usual 5. GOTO 3 Alternatively, this could be replaced with a makepkg-based flow: 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Get a mingw-w64-ghc-git PKGBUILD 3. $ makepkg-mingw --nobuild # clone the repositories 4. Go to src/ghc and hack, hack, hack 5. $ makepkg-mingw --noextract --noprepare --noarchive # build and test 6. GOTO 4 For binary release == Phase 1: pacman package. This can be done in coordination with the MSYS2 maintainers, or a separate GHC-owned pacman repository can be created. 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Update the mingw-w64-ghc PKGBUILD to point to the new source release 3. $ makepkg-mingw # build a package 4. Upload the package to a pacman repository Phase 2: stand-alone bindist 1. Download the package and its dependencies 2. Extract them into a temporary directory 3. Create a tarball or an installer from that 4. Upload to GHC servers This is essentially what the new Git for Windows does (and what some other projects that use MSYS2 as their build environment do). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...] Bardur Arantsson wrote: I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC. Agreed, that would work. But I thought that the idea was that we wanted it actually integrated into GHC. That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. However, due to the, sadly, mostly non-technical issues brought up, it seems to me that isolating cpphs into a separate process (w/ the option to configure GHC to use some other cpp implementation at your own risk if you need to avoid the cpphs implementation at all costs) would be the compromise acceptable to everyone in the short run while addressing the primary goal to decouple the default-configuration of GHC from the fragile system-cpp semantics. NB: Nothing's been decided yet by GHC HQ PS: As an observation, http://packdeps.haskellers.com/reverse/cpphs shows that cpphs is already used by popular packages like hlint and haskell-src-exts (and thus an indirect build-dep of the haskell-suite project). Therefore, if LGPL+SLE is unacceptable in some work-environments, it may require some vigilance to keep track where cpphs may sneak into as a build-dependency... I'm surprised there's still such resistance given the ubiquity of Linux distributions made up of numerous (L)GPLed components, IMHO it's kinda like tilting at windmills... Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Interesting. I'm not completely clear, when you say that your company distributes binaries to third-parties: do you distribute ghc itself? Or just the product that has been built by ghc? Regards, Malcolm On 21 May 2015, at 10:16, Yitzchak Gale wrote: LGPL is well-known and non-acceptable here. Show me some serious case law for Malcolm's customized LGPL and we can start talking. Other than that, explanations are not going to be helpful. Thanks, Yitz On Thu, May 21, 2015 at 4:51 AM, Howard B. Golden howard_b_gol...@yahoo.com wrote: Hi Yitzchak, I believe there are good explanations of open source licenses aimed at lawyers and management. I don't think their fears are well-founded. If you work for a timid company that isn't willing to learn, you should consider going elsewhere. You may be happier in the long run. Respectfully, Howard On May 20, 2015, at 7:39 AM, Yitzchak Gale g...@sefer.org wrote: The license issue is a real concern for any company using GHC to develop a product whose binaries they distribute to customers. And it is concern for GHC itself, if we want GHC to continue to be viewed as a candidate for use in industry. The real issue is not whether you can explain why this license is OK, or whether anyone is actually going to the trouble of building GHC without GMP. The issue is the risk of a *potential* legal issue and its potential disastrous cost as *perceived* by lawyers and management. A potential future engineering cost, no matter how large and even if only marginally practical, is perceived as manageable and controllable, whereas a poorly understood potential future legal threat is perceived as an existential risk to the entire company. With GMP, we do have an engineering workaround to side-step the legal problem entirely if needed. Whereas if cpphs were to be linked into GHC with its current license, I would be ethically obligated to report it to my superiors, and the response might very well be: Then never mind, let's do the simple and safe thing and just rewrite all of our applications in Java or C#. Keeping the license as is seems to be important to Malcolm. So could we have an option to build GHC without cpphs and instead use it as a stand-alone external program? That would make the situation no worse than GMP. Thanks, Yitz ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 05/21/2015 12:31 PM, Herbert Valerio Riedel wrote: Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...] Bardur Arantsson wrote: I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC. Agreed, that would work. But I thought that the idea was that we wanted it actually integrated into GHC. That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 21 May 2015, at 15:54, Bardur Arantsson wrote: fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. Don't count on it. On our Windows desktop machines, fork/exec costs approximately one third of a second, instead of the expected small number of milliseconds or less. The reasons are unknown, but we suspect a misconfigured anti-virus scanner (and for various company policy reasons we are prohibited from doing the investigation that could confirm or deny this hypothesis). This means that when ghc --make does lots of external things requiring a fork, such as preprocessing, a medium sized project (using many library packages) can take a surprisingly large amount of time (minutes instead of seconds), even for an incremental build where very little code has changed. We think an in-process cpphs could make some of our compilations literally hundreds of times faster. Regards, Malcolm ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 05/21/2015 05:36 PM, Malcolm Wallace wrote: On 21 May 2015, at 15:54, Bardur Arantsson wrote: fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. Don't count on it. On our Windows desktop machines, fork/exec costs approximately one third of a second, instead of the expected small number of milliseconds or less. The reasons are unknown, but we suspect a misconfigured anti-virus scanner (and for various company policy reasons we are prohibited from doing the investigation that could confirm or deny this hypothesis). Yeah, that sounds... broken. Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting. Don't you still have to support -pgmF? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote: On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting. Don't you still have to support -pgmF? I guess so, unfortunately... so we'd have to keep a legacy code-path for external cpp processing around, at least in the short run... ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote: [...] That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
