Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Bazel no longer manage modules #383

Merged
merged 1 commit into from
Aug 3, 2018
Merged

Conversation

mrkkrp
Copy link
Member

@mrkkrp mrkkrp commented Aug 2, 2018

Close #375, close #168.

It used to be that we would infer modules from the names of source
files, and then create a dependency graph based on these module names.
But this is,

  1. unnecessary and somewhat more complicated,
  2. incorrect in the general case, because GHC knows module names
    better than we do.

Both #375 and #168 are cases where module names don't match what we
expect. The solution is to stay out of the business of managing
modules, and manage only packages. Rather than create individual
outputs for each module, we can use declare_directory to create
a single output for all the interface files of a library, another for
all the object files etc.

@mrkkrp mrkkrp requested a review from mboes August 2, 2018 11:49
@mrkkrp
Copy link
Member Author

mrkkrp commented Aug 2, 2018

There are still a couple of things to check experimentally though, so don't merge just yet.

@mrkkrp mrkkrp force-pushed the arbitrary-file-layout branch from 496df30 to 68fbc5a Compare August 2, 2018 14:39
@mrkkrp
Copy link
Member Author

mrkkrp commented Aug 2, 2018

OK, this is good to go.

Copy link
Member

@mboes mboes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great.

@mboes
Copy link
Member

mboes commented Aug 2, 2018

Resolve conflicts and merge.

It used to be that we would infer modules from the names of source
files, and then create a dependency graph based on these module names.
But this is,

1. unnecessary and somewhat more complicated,
2. incorrect in the general case, because GHC knows module names
   better than we do.

Both #375 and #168 are cases where module names don't match what we
expect. The solution is to stay out of the business of managing
modules, and manage only packages. Rather than create individual
outputs for each module, we can use `declare_directory` to create
a single output for all the interface files of a library, another for
all the object files etc.
@mrkkrp mrkkrp force-pushed the arbitrary-file-layout branch from 68fbc5a to 3d0c4a9 Compare August 3, 2018 05:20
@mrkkrp mrkkrp merged commit be5cf67 into master Aug 3, 2018
@mrkkrp mrkkrp deleted the arbitrary-file-layout branch August 3, 2018 09:52
thufschmitt pushed a commit that referenced this pull request Sep 20, 2018
Probably due to #383, calling `haskell_doctest` without a `module`
argument resulted in doctest being run on no module at all instead of
all the modules.
thufschmitt pushed a commit that referenced this pull request Sep 20, 2018
Probably due to #383, calling `haskell_doctest` without a `module`
argument resulted in doctest being run on no module at all instead of
all the modules.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Be as lenient as GHC about module file names Make main_file redundant where possible
2 participants