hadrian-util: An experiment in a more usable hadrian UX

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

hadrian-util: An experiment in a more usable hadrian UX

Ben Gamari-3
Hi everyone,

For the past few months I have been using Hadrian for the majority of my
GHC builds. In due course I have encountered a few papercuts:

 * hadrian/cabal.build.sh is quite wordy (#16250); moreover, you need to
   be in the source root to invoke it (#16667)

 * editing hadrian.settings is quite difficult due to the lack of
   availability of tab-completion in vim

 * maintaining multiple build roots is quite error-prone since you must
   remember which build flavour you used for each (#16481, #16638)
 
 * there is no equivalent to setting `stage=2` in `mk/build.mk` to make
   the stage-1-freeze persistent

To address these I cobbled together a small wrapper, hadrian-util. I
have this installed in my home-manager environment with a shell alias,
`hu`, meaning that building GHC is as easy as typing `hu run` anywhere
in the tree.

As discussed in the README, `hadrian-util` supports multiple build
roots, has a moderately convenient interface for manipulating
hadrian.settings (with completion!) and has enough persistent state to
eliminate most of the error-prone boilerplate from Hadrian invocations
without being confusing.

There is the question of what the long-term future of hadrian-util
should be. Arguably it is merely a hack papering over some of the
shortcomings of Hadrian's current UX; perhaps eventually these will be
fixed. However, in the meantime, I've found that hadrian-util makes
hadrian quite pleasant to use.

I hope others also find this useful.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: hadrian-util: An experiment in a more usable hadrian UX

Alp Mestanogullari-2

For reference, hadrian-util lives at: https://gitlab.haskell.org/bgamari/hadrian-util

I quite like the idea of trying out improvements to the UX via an external wrapper. For wider adoption, we'd have to distribute it in a nicer way I suppose, but taking this one step at a time sounds good.

On 05/01/2020 19:30, Ben Gamari wrote:
Hi everyone,

For the past few months I have been using Hadrian for the majority of my
GHC builds. In due course I have encountered a few papercuts:

 * hadrian/cabal.build.sh is quite wordy (#16250); moreover, you need to
   be in the source root to invoke it (#16667)

 * editing hadrian.settings is quite difficult due to the lack of
   availability of tab-completion in vim

 * maintaining multiple build roots is quite error-prone since you must
   remember which build flavour you used for each (#16481, #16638)
 
 * there is no equivalent to setting `stage=2` in `mk/build.mk` to make
   the stage-1-freeze persistent

To address these I cobbled together a small wrapper, hadrian-util. I
have this installed in my home-manager environment with a shell alias,
`hu`, meaning that building GHC is as easy as typing `hu run` anywhere
in the tree.

As discussed in the README, `hadrian-util` supports multiple build
roots, has a moderately convenient interface for manipulating
hadrian.settings (with completion!) and has enough persistent state to
eliminate most of the error-prone boilerplate from Hadrian invocations
without being confusing.

There is the question of what the long-term future of hadrian-util
should be. Arguably it is merely a hack papering over some of the
shortcomings of Hadrian's current UX; perhaps eventually these will be
fixed. However, in the meantime, I've found that hadrian-util makes
hadrian quite pleasant to use.

I hope others also find this useful.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: hadrian-util: An experiment in a more usable hadrian UX

Richard Eisenberg-5
In reply to this post by Ben Gamari-3
This looks really useful, and might bridge the gap between the UX I'm used to and Hadrian, allowing me to adopt Hadrian sooner than I otherwise would. However, I would be disappointed to see hadrian-util still in active use when `make` is removed (#17527). I'm glad to see Ben's %Make removal milestone, which gives me more confidence that we'll wait until hadrian is really ready for prime-time before removing the old build system.

Thanks!
Richard

> On Jan 5, 2020, at 6:30 PM, Ben Gamari <[hidden email]> wrote:
>
> Hi everyone,
>
> For the past few months I have been using Hadrian for the majority of my
> GHC builds. In due course I have encountered a few papercuts:
>
> * hadrian/cabal.build.sh is quite wordy (#16250); moreover, you need to
>   be in the source root to invoke it (#16667)
>
> * editing hadrian.settings is quite difficult due to the lack of
>   availability of tab-completion in vim
>
> * maintaining multiple build roots is quite error-prone since you must
>   remember which build flavour you used for each (#16481, #16638)
>
> * there is no equivalent to setting `stage=2` in `mk/build.mk` to make
>   the stage-1-freeze persistent
>
> To address these I cobbled together a small wrapper, hadrian-util. I
> have this installed in my home-manager environment with a shell alias,
> `hu`, meaning that building GHC is as easy as typing `hu run` anywhere
> in the tree.
>
> As discussed in the README, `hadrian-util` supports multiple build
> roots, has a moderately convenient interface for manipulating
> hadrian.settings (with completion!) and has enough persistent state to
> eliminate most of the error-prone boilerplate from Hadrian invocations
> without being confusing.
>
> There is the question of what the long-term future of hadrian-util
> should be. Arguably it is merely a hack papering over some of the
> shortcomings of Hadrian's current UX; perhaps eventually these will be
> fixed. However, in the meantime, I've found that hadrian-util makes
> hadrian quite pleasant to use.
>
> I hope others also find this useful.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs