Page MenuHomeFreeBSD

pgj (Gábor Páli)
User

Projects

User does not belong to any projects.

User Details

User Since
May 20 2017, 6:28 AM (118 w, 2 d)

Recent Activity

Jan 6 2018

pgj accepted D12043: Switch C compiler used by GHC to Clang..

Sure. But I will not commit it myself as I do not have the resources to double check the changes (so I could not take the responsibility for them, including committing further fixes for potential fallout).

Jan 6 2018, 6:00 PM

Dec 31 2017

pgj added a comment to D12043: Switch C compiler used by GHC to Clang..
In D12043#286791, @6yearold_gmail.com wrote:
In D12043#286756, @pgj wrote:

All right, that sounds like a good idea.

Updating to 8.2 or just pulling in the patch?

Dec 31 2017, 3:26 PM
pgj added a comment to D12043: Switch C compiler used by GHC to Clang..
In D12043#284778, @6yearold_gmail.com wrote:

Update the revision. With this poudriere bulk lang/ghc */hs-* devel/stack compiles without error on 11.1-RELEASE {i386,amd64}.

Dec 31 2017, 11:58 AM

Aug 21 2017

pgj added a comment to D12043: Switch C compiler used by GHC to Clang..
In D12043#251056, @6yearold_gmail.com wrote:

I don't see why is this Clang's fault. The FreeBSD build system for compiler-rt lacks some flags, and that's it no?

Aug 21 2017, 10:05 PM
pgj added a comment to D12043: Switch C compiler used by GHC to Clang..
In D12043#251051, @6yearold_gmail.com wrote:

And what would make enough evidence? Building whole stackage? I can give it a try, if you ask.

Aug 21 2017, 9:59 PM
pgj added a comment to D12043: Switch C compiler used by GHC to Clang..

Let me add a recent example of why I am not entirely satisfied with base system Clang.

Aug 21 2017, 9:16 PM
pgj added a comment to D12043: Switch C compiler used by GHC to Clang..
In D12043#251046, @6yearold_gmail.com wrote:

The whole point of this patch was to get rid from GCC completely.

Aug 21 2017, 7:29 PM
pgj added a comment to D12043: Switch C compiler used by GHC to Clang..

Would not it be possible to make this optional (like it was before)? I am not endorsing GCC here, but in my experience it is much more supported in Haskell circles. So, I would keep that as the default, and make the use of Clang optional as an option to the port. Also, we would not have to be so strict on build failures that way.

Aug 21 2017, 5:35 PM

Aug 14 2017

pgj committed rP447927: Fix build on __FreeBSD_version >= 1200033..
Fix build on __FreeBSD_version >= 1200033.
Aug 14 2017, 9:14 AM

Aug 10 2017

pgj accepted D11960: Fix textproc/cgrep.
Aug 10 2017, 8:42 PM
pgj added a comment to D11961: Fix patch in lang/ghc.

Generally, it looks okay to me. Although let me add that there was a '@' before ${REINPLACE_CMD} ... at the post-patch target in the earlier version of the lang/ghc/Makefile. Currently it displays the respective sed(1) on the patch target, which is just noise. I guess that is leftover from debugging.

Aug 10 2017, 8:40 PM

Aug 8 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

While toying with the related commit message, I realized that your change wants to re-add the math/hs-nats port that was removed on the last major update. It actually had a reason: the functionality of the nats package has been merged in the base package that ships with GHC, and it looks like that is still the case.

Aug 8 2017, 10:39 AM
pgj accepted D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

I think it is fine now.

Aug 8 2017, 8:31 AM
pgj added a reviewer for D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases: pgj.
Aug 8 2017, 8:26 AM

Aug 7 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

@tcberner : You seem to forgot to remove the SUBDIR entry for hs-directory in devel/Makefile, so I fixed it. In addition to that, the new version of my diff now contains:

Aug 7 2017, 6:53 PM
pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

I think it did not, but since I have spotted other problems, I kept working on the diff, which has been updated by now. To the latest version, it features the following changes:

Aug 7 2017, 9:45 AM

Aug 3 2017

pgj committed rP447275: Backport fix for issue #3212.
Backport fix for issue #3212
Aug 3 2017, 6:50 PM

Aug 2 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

When I was discussing with tobik how to deal with devel/stack, he spotted that lang/ghc does not configure with setting the DOCS option to off. I investigated the issue, and it turned out the X_SUB_LIST_OFF variables do not properly escape the '#' characters so sed(1) fails. They have to be prefixed with a backslash in order to work.

Aug 2 2017, 7:30 PM

Aug 1 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

I found some additional build problems on i386 that I have now fixed. I updated the previously referenced diff with those changes.

Aug 1 2017, 12:38 PM

Jul 31 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

All right, I have worked myself through all the mentioned issues as part of my more exhaustive review that eventually resulted in an updated version of the published diff. Basically now all the ports build fine, except devel/stack where I could not yet figure out what causes the build to fail.

Jul 31 2017, 9:02 PM
pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

Unfortunately, the documentation for lang/ghc cannot yet be built with the current version of textproc/py-sphinx in the tree. This has been reported and fixed upstream but it is not there in the ports. I submitted a bug report for that.

Jul 31 2017, 10:08 AM

Jul 30 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

I think the following ports could be safely dropped as they got deprecated and unmaintained in upstream:

Jul 30 2017, 10:18 AM

Jul 27 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

Do you really want to upgrade hoauth2 to its latest version? gitit uses versions 0.4.x (x >= 2) or 0.5.x, and the Network.Gitit.Authentication.Github module would need to be heavily patched in order to be able to build with version 1.3.0 (due changes in the API).

Jul 27 2017, 8:29 AM

Jul 25 2017

pgj added inline comments to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.
Jul 25 2017, 3:13 PM

Jul 24 2017

pgj added inline comments to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.
Jul 24 2017, 7:52 PM

Jul 21 2017

pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

I have added some comments to the patch inline. In addition to them, a general remark: I believe all ports where there was no version change, the PORTREVISION must be bumped because a major dependency has still changed, the compiler. That is, they will have to rebuilt anyway. I do not know if this is still required these days, though.

Jul 21 2017, 5:47 AM
pgj added a comment to D11558: Update lang/ghc to 8.0.2 and update hs-* to the newest releases.

I think there is nothing wrong with the DYNAMIC and PROFILE options. The issue that Ashish was experiencing is due to the fact that GHC cannot build either a dynamically-linked or profiling version of a library/executable if any of the dependencies does not have those versions built and installed. The reason why PROFILE is not enabled by default is also that it is mostly a developer option. The _p version of the libraries contain some extra bits for doing performance profiling and I do not think it would make sense to build and package them unless the user wants to have them specifically. (They can increase the size of the package by about one third, I guess.) On that other hand, as far as I remember, DYNAMIC has been a default option for a while now.

Jul 21 2017, 4:41 AM

May 21 2017

pgj added a comment to D10798: lang/ghc: Update for ino64.

Yes, along our discussion here, I got motivated to experiment with building a dynamically-linked version of the bootstrap that does not use any statically linked libraries. I am not sure if the GHC build system can handle this, though. But once the ino64 changes are there, I will give it a try. Until then, I am fine with your workaround.

May 21 2017, 12:47 PM
pgj added a comment to D10798: lang/ghc: Update for ino64.

Okay, but I still do not understand something: is there a problem, and if yes, what is the problem with the way rebuilding the bootstrap compiler as I drafted above?

May 21 2017, 12:12 PM
pgj added a comment to D10798: lang/ghc: Update for ino64.

All right, I see it more clearly now.

May 21 2017, 10:12 AM

May 20 2017

pgj added a comment to D10798: lang/ghc: Update for ino64.

I think building a new bootstrap becomes easy with this change. My plan for that would be as follows: move to a FreeBSD version that has the ino64 commit, build the lang/ghc port with the trick featured here, and use it to build GHC from sources. The rest has been documented in our development wiki at GitHub.

May 20 2017, 8:59 PM
pgj accepted D10798: lang/ghc: Update for ino64.

I think this solution is fine for now, thank you for your work! Note that I have not tested this change myself, but I understand what it does (and the reasons why it does that) and I support it. I believe if all the dependencies build with this version of the compiler, it works just all right.

May 20 2017, 6:49 AM