-
Notifications
You must be signed in to change notification settings - Fork 696
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
Implement show-build-info
for cabal-install
#7478
Conversation
bebb70e
to
c44cb87
Compare
The third time is the right time! |
, "unit-id" .= JsonString (T.pack $ prettyShow $ componentUnitId clbi) | ||
, "compiler-args" .= JsonArray (map JsonString $ getCompilerArgs bi lbi clbi) | ||
, "modules" .= JsonArray (map (JsonString . T.pack . display) modules) | ||
, "src-files" .= JsonArray (map (JsonString . T.pack) sourceFiles) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not ideal as sourceFiles
are relative to hs-src-dirs
. Getting the final Filepath for the source file requires more post-processing in tooling.
f544427
to
d2f0035
Compare
d2f0035
to
3693a56
Compare
This allows users to get a JSON representation of various information about how Cabal would go about building a package. The output of this command is intended for external tools and therefore the format should remain stable.
Add (currently nonfunctional) new-show-build-info Fix compile error Make new-show-build-info functional Use silent verbosity by default on showBuildInfo commands to keep output json clean Make show-build-info commands hidden Implement write-autogen-files Make new-write-autogen-files work Make new-write-autogen-files configure if necessary Use target selectors for new-show-build-info Don't prune plan for new-show-build-info Only configure in new-show-build-info and new-write-autogen-files if no persist build info file is found Wrap multiple target output of new-show-build-info in json list
8e3d211
to
d0471c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Low confidence accept from me, since I didn't read the issues and old PRs (much).
d0471c2
to
cf4ec5d
Compare
Also, rename new-show-build-info to show-build-info in ShowBuildInfo Get cabal-install building again Fix typo Don't hardcode cabal version in showbuildinfo tests Remove some unnecessary files from test package Refactor show-build-info tests Undo some changes no longer needed in Main.hs Add back explicit exports and fix typos Tidy up imports Update showBuildInfoAction documentation Cosmetic fixes
cf4ec5d
to
4bc4f15
Compare
show-build-info
for cabal-installshow-build-info
for cabal-install
-- Also shut up haddock since it dumps warnings to stdout | ||
flags' = flags { haddockFlags = haddockFlags { haddockVerbosity = Flag silent } | ||
, configFlags = configFlags { Cabal.configTests = Flag True | ||
, Cabal.configBenchmarks = Flag True | ||
} | ||
} | ||
cliConfig = commandLineFlagsToProjectConfig globalFlags flags' | ||
-- flags' = flags { haddockFlags = haddockFlags { haddockVerbosity = Flag silent } | ||
-- , configFlags = configFlags { Cabal.configTests = Flag True | ||
-- , Cabal.configBenchmarks = Flag True | ||
-- } | ||
-- } | ||
cliConfig = commandLineFlagsToProjectConfig globalFlags flags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not a problem any more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verbosity is still set to silent
by default for the aforementioned reason (E.g. pollutes output and makes piping the results harder). However, since we do have a file output flag, I am not against changing the default verbosity to normal
.
This used to enable tests and benchmarks by default, which I dislike, as we might ignore user configuration for basically no reason. There might be even a good reason why these have been disabled. So, I prefer explicit over implicit, and I think this is the more reasonable behaviour. People can and should explicitly enable these if they want information about them. (Although I just found out that tests and benchmarks are automagically enabled iff all their dependencies are already built. Still, my point stands :D)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haddock verbosity might be still an issue, have to test that code-path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed some extra lines in test output with HADDOCK in them. Not sure if related.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, but I personally don't believe HADDOCK is really an issue.
@@ -1313,10 +1316,24 @@ buildInplaceUnpackedPackage verbosity | |||
Tar.createTarGzFile dest docDir name | |||
notice verbosity $ "Documentation tarball created: " ++ dest | |||
|
|||
-- Build info phase | |||
{- buildInfo <- -} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove
-- Build info phase | ||
{- buildInfo <- -} | ||
whenBuildInfo $ do | ||
-- Write the json to a temporary file to read it, since stdout can get |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update comment
-- Write the json to a temporary file to read it, since stdout can get | ||
-- cluttered | ||
let dir = distProjectCacheDirectory </> "buildinfo" | ||
let fp = dir </> (unUnitId $ elabUnitId pkg) <.> "json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filenames look like this: hie-bios-0.8.0-inplace-hie-bios.json
Not really stable and not nice to look at. Besides that these files are not strictly necessary, would there be a way to improve them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Problem? I thought that is a feature? But probably no.
However, I am thinking about removing it and maybe we can talk about this in a follow-up pr.
buildResultDocs :: DocsResult, | ||
buildResultTests :: TestsResult, | ||
buildResultLogFile :: Maybe FilePath, | ||
buildResultBuildInfo :: Maybe Text |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused, also what do these BuildResults really do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. I'd like this answered too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like they were intended to be cached somehow, but it kind of looks like they are always created on the fly.
Probably going to re-activate the usage in favour of the cache files in dist-newstyle/cache/buildinfo
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
f52d06c
to
aee85f5
Compare
This means that cabal-install now extracts the LocalBuildInfo etc. itself for each component, and now assembles the JSON without the need for writing to temporary files. It also means that one build info JSON object can be returned instead of an array. It works by configuring each component separately as before, and instead of making its own build info object, it just collects the component information. This one build info object now reports the compiler used with the ElaboratedSharedConfig, which is shared across all components. Fix haddock parsing in TargetProblem Build dependencies in show-build-info Update .prod/.zinz templates Silence Haddock output
07ed561
to
b3cfd45
Compare
This fixes a lot of edge cases for example where the package db wasn't created at the time of configuring. Manually doing the setup.hs wrapper stuff was hairy. Turns out we do need to keep the show-build-info part inside Cabal as we rely on LocalBuildInfo which can change between versions, and we would need to do this anyway if we wanted to utilise the ProjectPlanning/Building infrastructure.
Changes the internal representation of JSON to Text rather than String, and introduces the buildinfo-components-only flag in the Cabal part to make it easier to stitch back the JSON into an array in cabal-install.
Simplifies writing tests for show-build-info Add trailing path separator to make testing simpler.
6bef1c7
to
3240ecc
Compare
@@ -257,6 +257,7 @@ library | |||
Distribution.Utils.NubList | |||
Distribution.Utils.ShortText | |||
Distribution.Utils.Progress | |||
Distribution.Utils.Json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 👍
3240ecc
to
2b51b5e
Compare
Closed in favour of #7498 |
Rebase, squash and further development of #6241.
Basically brings the PR back into shape, building on top of the work of @bubba and others.
This is a new PR since the old one has quite a lot of outdated review comments and I thought it might be easier to review here.
However, there are quite a lot of insights in the previous PR, so it is still a must-read for understanding details and implementation details.
So, what works? Basically, the command works for
build-type: Simple
and on top of that, hie-bios has a POC powered by cabal's show-build-info support (HLS POC is also on the way).(I haven't tested
build-type: Custom
yet, so no promises at the moment)What doesn't work? The caching is pretty broken, e.g. whenever you invokeshow-build-info
, the state cache changes andbuild
will rebuild local packages, but I think we can fix that.Additionally, I want to add a caching mechanism forshow-build-info
, and implemented here a POC whereshow-build-info
for each component is written todist-newstyle/cache/buildinfo
and it is re-generated whenever a local package needs to be rebuilt.The intention is that
show-build-info
is lightning fast on the happy path. That commit can be reverted though if that behaviour is undesired.Writes json of show-build-info to a file in
dist-newstyle/cache/buildinfo
but it is not really necessary.TODOS:
--pick-first-target
Add AmbiguityResolver to decide how to resolve ambiguity #7482