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

Implement show-build-info for cabal-install #7478

Closed
wants to merge 11 commits into from

Conversation

fendor
Copy link
Collaborator

@fendor fendor commented Jul 8, 2021

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 invoke show-build-info, the state cache changes and build will rebuild local packages, but I think we can fix that.
Additionally, I want to add a caching mechanism for show-build-info, and implemented here a POC where show-build-info for each component is written to dist-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:

@jneira
Copy link
Member

jneira commented Jul 8, 2021

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)
Copy link
Collaborator Author

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.

cabal-install/src/Distribution/Client/Setup.hs Outdated Show resolved Hide resolved
cabal-install/src/Distribution/Client/Setup.hs Outdated Show resolved Hide resolved
bgamari and others added 2 commits July 12, 2021 10:37
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
@fendor fendor force-pushed the cabal-sbi-expirement branch 3 times, most recently from 8e3d211 to d0471c2 Compare July 12, 2021 09:27
Copy link
Member

@Mikolaj Mikolaj left a 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).

cabal-install/src/Distribution/Client/Setup.hs Outdated Show resolved Hide resolved
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
@fendor fendor changed the title WIP: Implement show-build-info for cabal-install Implement show-build-info for cabal-install Jul 12, 2021
Comment on lines 136 to 142
-- 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
Copy link
Member

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?

Copy link
Collaborator Author

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)

Copy link
Collaborator Author

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.

Copy link
Member

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.

Copy link
Collaborator Author

@fendor fendor Jul 12, 2021

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.

cabal-install/src/Distribution/Client/ProjectBuilding.hs Outdated Show resolved Hide resolved
cabal-install/src/Distribution/Client/ProjectBuilding.hs Outdated Show resolved Hide resolved
@@ -1313,10 +1316,24 @@ buildInplaceUnpackedPackage verbosity
Tar.createTarGzFile dest docDir name
notice verbosity $ "Documentation tarball created: " ++ dest

-- Build info phase
{- buildInfo <- -}
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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"
Copy link
Collaborator Author

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?

Copy link
Collaborator Author

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
Copy link
Collaborator Author

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?

Copy link
Member

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

Copy link
Collaborator Author

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.

cabal-install/src/Distribution/Client/Setup.hs Outdated Show resolved Hide resolved
cabal-install/src/Distribution/Client/Setup.hs Outdated Show resolved Hide resolved
Copy link
Member

@jneira jneira left a comment

Choose a reason for hiding this comment

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

As @Mikolaj approving by pure trust and a quick look 😄
It would be nice if reviewers of the superseded pr (@phadej, @DanielG) could take a last look to this one

@fendor fendor force-pushed the cabal-sbi-expirement branch 2 times, most recently from f52d06c to aee85f5 Compare July 14, 2021 07:11
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
@fendor fendor force-pushed the cabal-sbi-expirement branch 2 times, most recently from 07ed561 to b3cfd45 Compare July 14, 2021 07:38
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.
@fendor fendor force-pushed the cabal-sbi-expirement branch 4 times, most recently from 6bef1c7 to 3240ecc Compare July 14, 2021 14:15
@@ -257,6 +257,7 @@ library
Distribution.Utils.NubList
Distribution.Utils.ShortText
Distribution.Utils.Progress
Distribution.Utils.Json
Copy link
Member

Choose a reason for hiding this comment

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

Thanks 👍

@fendor
Copy link
Collaborator Author

fendor commented Aug 15, 2021

Closed in favour of #7498

@fendor fendor closed this Aug 15, 2021
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.

None yet

5 participants