Open bgamari opened 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:
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.
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.
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
andExpression
move toHadrian.Context
,Hadrian.Expression
.Rules
andSettings
move toGHC.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.
andHadrian.
namespaces may be a bit blurry at times, but it sounds like a nice ideal to strive towards.
Cheers,
@bgamari Thanks, I'll give it a try.
what is the status of this issue now?
@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.
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.