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

Add s/cmm-sources + extra-bundled-libraries #4857

Merged
merged 9 commits into from
Nov 3, 2017

Conversation

angerman
Copy link
Collaborator

@angerman angerman commented Nov 1, 2017

Please include the following checklist in your PR:

  • Patches conform to the coding conventions.
  • Any changes that could be relevant to users have been recorded in the changelog.
  • The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

So this is primarily, so that I can give the rts package rts.cabal file.
But I believe these have uses outside of the rts as well.

# Conflicts:
#	Cabal/Distribution/PackageDescription/Check.hs
#	Cabal/Distribution/PackageDescription/Parsec/FieldDescr.hs
#	Cabal/Distribution/Parsec/Types/FieldDescr.hs
#	Cabal/doc/developing-packages.rst
# Conflicts:
#	Cabal/Distribution/PackageDescription/Parsec/FieldDescr.hs
Copy link
Member

@23Skidoo 23Skidoo left a comment

Choose a reason for hiding this comment

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

Looks okay to me, but please add changelog notes.

@@ -1031,6 +1031,8 @@ checkPaths pkg =
++ concat
[ [ (path, "c-sources") | path <- cSources bi ]
++ [ (path, "cxx-sources") | path <- cxxSources bi ]
++ [ (path, "s-sources") | path <- sSources bi ]
Copy link
Member

Choose a reason for hiding this comment

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

IMO asm-sources would be a better name. One question is whether we should have asm-x86-sources, asm-x86_64-sources, etc. instead of a single catch-all field... probably not.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'd argue for using if arch(...): in those cases.

I'm fine with asm-soures as well.

Copy link
Member

Choose a reason for hiding this comment

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

Yep, I also think that if(arch) is the right approach.

Copy link
Member

Choose a reason for hiding this comment

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

especially given @phadej's elif using if arch(...) is quite ok I think

mkProfLibName lib = mkGenericStaticLibName (getHSLibraryName lib ++ "_p")


mkGenericSharedLibName :: CompilerId -> String -> String
Copy link
Member

Choose a reason for hiding this comment

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

Please add a Haddock comment.

@@ -493,6 +493,9 @@ binfoFieldDescrs =
, listFieldWithSep vcat "extra-ghci-libraries"
showToken parseTokenQ
extraGHCiLibs (\xs binfo -> binfo{extraGHCiLibs=xs})
, listFieldWithSep vcat "extra-bundled-libraries"
Copy link
Member

Choose a reason for hiding this comment

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

Needs docs.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Will see to this and the haddocks tomorrow. Thanks for the review!

@hvr
Copy link
Member

hvr commented Nov 1, 2017

This is not critical/urgent, but in general it'd be sensible to have things like {c,cmm,asm}-sources imply a constraint on the compiler implementation. E.g. specifying c-sources would imply a compiler that supports linking C FFI functions; currently afaik, GHCJS doesn't support C FFI as an example.

@angerman
Copy link
Collaborator Author

angerman commented Nov 2, 2017

Building test suite 'check-tests' for Cabal-2.1.0.0..
[1 of 1] Compiling Main             ( tests\CheckTests.hs, dist\build\check-tests\check-tests-tmp\Main.o )
Linking dist\build\check-tests\check-tests.exe ...
C:/ProgramData/chocolatey/lib/ghc/tools/ghc-8.0.2/mingw/bin/ld.exe: cannot find -lHSCabal-2.1.0.0-FQui7antlcKGtClAj2Mabp
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)

Hmm... so how did I cause that. let's see.

Not absolutely happy with this solution. I fail to come up with a better one though.
The issue is that for some libraries, you might want to have _debug, _p, _l, as well as _thr_debug, _thr_p, _thr_l flavours.
@angerman angerman force-pushed the feature/extra-fields branch from 8eb3bd1 to 7577105 Compare November 3, 2017 01:56
@angerman
Copy link
Collaborator Author

angerman commented Nov 3, 2017

I'm pretty annoyed that travis isn't checking this :(

@23Skidoo 23Skidoo merged commit 357d49d into haskell:master Nov 3, 2017
@23Skidoo
Copy link
Member

23Skidoo commented Nov 3, 2017

Merged, thanks!

bgamari pushed a commit to ghc/ghc that referenced this pull request Nov 11, 2017
Summary:
This is in prerpation for cabalification of the `rts`. To be actually able to parse this file, a rather recent Cabal is required. One after commit `357d49d` of haskell/cabal. The relevant PR to support the new `asm-srouces` and `cmm-sources` is haskell/cabal/pull/4857.

Not that this does *not* allow cabal to build the RTS. It does however provide enough information such that cabal can `copy` and `register` the package properly in the package database, if all the build artifacts have been build properly.

As such it does not require any custom handling of the `rts` package. As the rts as well as all the other packages built by the GHC built system are built outside of cabal anyway.

Reviewers: bgamari, hvr, erikd, simonmar

Subscribers: rwbarton, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D4174
bgamari pushed a commit to ghc/ghc that referenced this pull request Nov 11, 2017
Summary: With the introduction of `asm-srouces` and `cmm-sources` in haskell/cabal/pull/4857. Which was merged into `haskell/cabal` HEAD in`357d49d`. We can now declare the `cmm-files` properly, and as such they can be read out by the cabal library.

Reviewers: bgamari, hvr

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D4176
angerman added a commit to zw3rk/cabal that referenced this pull request Nov 15, 2017
…res, extra-library-flavours, and virtual-modules.

As pointed out by @hvr, haskell#4857, haskell#4875 did not contain the necessary "check" logic. This PR tries to address this shortcoming.
@angerman angerman mentioned this pull request Nov 15, 2017
4 tasks
bgamari pushed a commit to ghc/ghc that referenced this pull request Nov 15, 2017
This is in preparation for cabalification of the `rts`. To be actually
able to parse this file, a rather recent Cabal is required. One after
commit 357d49d of haskell/cabal. The relevant PR to support the new
`asm-sources` and `cmm-sources` is haskell/cabal/pull/4857.

Not that this does *not* allow cabal to build the RTS. It does however
provide enough information such that cabal can `copy` and `register`
the package properly in the package database, if all the build
artifacts have been build properly.

As such it does not require any custom handling of the `rts` package.
As the rts as well as all the other packages built by the GHC built
system are built outside of cabal anyway.

Reviewers: bgamari, hvr, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D4174
@bgamari bgamari mentioned this pull request Jul 20, 2019
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.

3 participants