snowleopard / hadrian

Hadrian: a new build system for the Glasgow Haskell Compiler. Now merged into the GHC tree!
https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian
MIT License
209 stars 37 forks source link

Better organize source tree to separate policy from mechanism #347

Open bgamari opened 7 years ago

bgamari commented 7 years ago

Looking through the source tree (especially at the top level) it can be rather hard to sort out at first glance what files are defining general mechanisms (e.g. Target, Expression, Way, Stage, Builder, etc.) and which are defining specific details of the build process. It would be nice if this were more evident from the source layout.

snowleopard commented 7 years ago

Thanks! Indeed, I'd like to do this before The Merge, so that users don't need to re-learn the source tree.

Do you have any advice on the best tree structure?

I think we should have two separate directories: one for the generic build infrastructure (expressions, etc.), and one for GHC specifics (build rules, command line templates, etc.).

One possible structure:

In this way Hadrian.* could eventually become a reusable library, although it may be hard to disentangle it completely from GHC.

snowleopard commented 7 years ago

Some of the command line templates, e.g. 'building a C object' could be pulled into Hadrian.Template.C, because they are GHC-independent and may be reused.

bgamari commented 7 years ago

Andrey Mokhov notifications@github.com writes:

Thanks! Indeed, I'd like to do this before The Merge, so that users don't need to re-learn the source tree.

Do you have any advice on the best tree structure?

I think we should have two separate directories: one for the generic build infrastructure (expressions, etc.), and one for GHC specifics (build rules, command line templates, etc.).

One possible structure:

  • Context and Expression move to Hadrian.Context, Hadrian.Expression.
  • Rules and Settings move to GHC.Rules, GHC.Settings.

In this way Hadrian.* could eventually become a reusable library, although it may be hard to disentangle it completely from GHC.

This sounds like a reasonable structure to me. Of course, as you point out, the line between the GHC. and Hadrian. namespaces may be a bit blurry at times, but it sounds like a nice ideal to strive towards.

Cheers,

snowleopard commented 7 years ago

@bgamari Thanks, I'll give it a try.

izgzhen commented 6 years ago

what is the status of this issue now?

snowleopard commented 6 years ago

@izgzhen I've factored out quite a lot of code to a generic library that lives in the Hadrian subdirectory, but further work is currently on hold until we merge #445. Once #445 is merged, I'll continue working on this.