Make targets extensible #99
Merged
Conversation
|
오늘안에 보겠습니다 ㅋㅋ |
This was referenced Mar 4, 2017
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Target
classThis patch makes more targets can be added. In order to decouple target-specific backend from the intermediate compilation, I need to introduce a new typeclass named
Target
. This new class has the following purposes:Every target can have its own configuration specific to the target language. So target-specific settings need to be interpreted by the corresponding target. Meanwhile, these settings ideally should be altogether with settings of other targets and package metadata: package.toml file.
To achieve that,
Target
'sparseTarget
function takes only the part of the settings needed by each target. If it returns errors, or has successfully parsed the part the result is automatically propagated and merged to the result of the whole build process.Instead of defining the common types for error/successful result to be used by every target and the whole build process altogether,
Target
makes each target to define their own types for the internal representations and functions to render them to the outer representation. For error types (CompileError
), they have to be rendered to error messages to be printed (showCompileError
), and for successful result types (CompileResult
), they have to be rendered toByteString
to be finally written to object files (toByteString
).Every target has its own name. Although it's not used by CLI yet, there are APIs to discover a corresponding target by its name text. It determines the section name for the target in package.toml file. (Read the below.)
package.toml
To build a package to a target, its package.toml need to has a settings specific for the target. It's configured to
targets.{targetName}
section in table. See examples/package.toml:The above
targets.python.name
field is for Python target and determines the PyPI distribution name. See also docs/package.md for details.Template Haskell
To implement discovery of
Target
instances, I need to add some amount of Template Haskell.Nirum.Targets.List
module is only for it, and it's used byNirum.Targets
module.buildPackage
function takes a target name string, and Template Haskell magic finds the proper target instance from the given string. I'd hacked it to implement target discovery without Template Haskell for more than a month, but found Template Haskell is necessary to implement it.Python's PyPI distribution name
As I mentioned above, now generated setup.py doesn't hardcode its
name
field toTestPackage
anymore. Instead, it's determined bytargets.python.name
in the package.toml file. #41 is fixed.