-
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
show-build-info (exe:cabal part plus tests) #6241
Conversation
2e70d3d
to
c946e9a
Compare
@@ -304,7 +305,8 @@ mainWorker args = do | |||
, hiddenCmd win32SelfUpgradeCommand win32SelfUpgradeAction | |||
, hiddenCmd actAsSetupCommand actAsSetupAction | |||
, hiddenCmd manpageCommand (manpageAction commandSpecs) | |||
|
|||
, hiddenCmd CmdShowBuildInfo.showBuildInfoCommand |
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.
should it be a hidden command?
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 don't see any reason to hide it. We're treating it like an API, right? What is our API guarantee for the returned JSON anyways? Should probably write that down somewhere.
No breaking changes within a Cabal major version? No breaking changes ever?
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.
Someone else needs to define this, I dont know enough of the process and the ramifications of such promises.
c946e9a
to
e4c648d
Compare
CI fail seems to be unrelated to this pr. |
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 for pushing this through! Functionality loooks good apart from the fact that we still don't have any tests that actually use the build info we get to run GHC or anything.
While testing out the lib:Cabal side show-build-info
I noticed that what we get back from that doesn't include the inplace package-db because that's added very late by the build
command. See the createInternalPackageDB
calls in Simple/Build.hs
.
Some pretty basic tests that call GHC would have cought this, just saying ;) I found it because I have such tests in cabal-helper.
I think we should definetly fix that issue before merging but we can just fix it up on the cabal-install side for now, I'm not sure it even makes sense to fix that on the Cabal side anyways.
Other minor things:
- The code is still a bit messy and needs quite some cleanup.
- I'd like to see some deduplication of the test code.
cabal-testsuite/PackageTests/ShowBuildInfo/A/build-info-exe-exact.test.hs
Outdated
Show resolved
Hide resolved
cabal-testsuite/PackageTests/ShowBuildInfo/A/build-info-exe-exact.test.hs
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,12 @@ | |||
# cabal show-build-info | |||
cabal: Internal error in target matching. It should always be possible to find a syntax that's sufficiently qualified to give an unambiguous match. However when matching 'exe:B' we found exe:B (unknown-component) which does not have an unambiguous syntax. The possible syntax and the targets they match are as follows: |
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.
Um, this sounds like a cabal bug to me. Certainly nothing that should be expected test output or ever seen by users! Please find out what's going on here.
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.
That error message looks like #5081.
I've been trying to integrate this with
|
@phadej @fendor I've changed this to avoid calling Setup.hs to get the show-build-info result (It still uses it for configuring the components). That way we can collect the component information separately and use the correct compiler information, and return just one build info object rather than several, whilst also avoiding the temporary files. So there's a bit of poking about done with |
test.hs
Outdated
build-depends: base | ||
with-compiler: ghc-8.6.5 | ||
-} | ||
main = putStrLn "hey" |
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.
Ugh accidentally added this and hie.yaml during a rebase. Will fix
I think
Passing the targets to the build part will be important, as with |
If project contains packages We don't have such more of operation currently. Would be good to have. Actually both:
|
I ran into this whilst testing out integrating this with hie-bios, #6874 and I think there should be a mechanism to allow for ambiguous target selectors to be resolved, e.g. by just selecting the first one. Namely, hie-bios isn't going to care what component's flags |
Todo
|
fb02daa
to
0dff8a6
Compare
9a5d4bd
to
11de41c
Compare
Tricky situation with dependencies: Given this simple cabal file
If we are to run Edit: this has been solved with a new |
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.
Every other command defaults to what they used to do. show-build-info now just chooses the first choice, since it doesn't care about ambiguity.
@DanielG Phew, reworked it to now use the nix stuff. Hopefully ci passes |
These are needed by tooling to setup GHC sessions.
5084eb1
to
00ba53b
Compare
New and noteworthy things in this PR:
|
| JsonString !Text | ||
|
||
-- | A type to mirror 'ShowS' | ||
type ShowT = Text -> 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.
I spotted this via your comment. Why this and not https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text-Lazy-Builder.html
The ShowT = Text -> Text
is worse than ShowS
, as it copies all intermediate values, causing quadratic behavior.
Yet, if you doing this for performance reasons, you should use ByteString
and its builder, like aeson
.
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.
Accidentally quadratic, how embarrassing! I'll switch this all over to ByteString
, didn't realise Text
was also locale dependent
|
||
case fileOutput of | ||
Nothing -> T.putStrLn res | ||
Just fp -> T.writeFile fp res |
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 locale dependent, better to serialise to ByteString
and write it.
Separate JSON utility into own PR, it is independent and can be reviewed and committed independently. |
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. It also 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. 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.
@fendor has been this superseeded so we could close? |
@jneira @fendor Sorry, would you mind expanding on what this has been superseded with? There seems to now be a network of issues about Is there a "can i run |
This issue summarises the current ideas, discussions and efforts: #7489 Specifically this is a PR overview: #7489 (comment) |
Please include the following checklist in your PR:
[ci skip]
is used to avoid triggering the build bots.Please also shortly describe how you tested your change. Bonus points for added tests!
Since #6108 merged parts of #5954, the original pr #5954 got obsolete.
This now is the second part that contains only changes to cabal-install and the test-suite.
This is a push to get s-b-i merged for
exe:cabal
, enabling further improvements to it.cc @hvr, @DanielG, @mpickering