From simonpj at microsoft.com  Thu Oct  9 07:45:25 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 9 Oct 2014 07:45:25 +0000
Subject: FW: Building ghc on Windows with msys2
In-Reply-To: <CAHnG2CybRRpY7Wp7CjVPdK7s6Cudg-Nf0WydTan8dy6Mq-etyg@mail.gmail.com>
References: <CAFC_MejJSJY-r+UFwtVYTWFUuU0pPSvnQLOCwe0jVh1DHFf2uw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF2223DA32@DB3PRD3001MB020.064d.mgd.msft.net>
 <m10oci$dfp$1@ger.gmane.org>
 <CAHnG2CyUBzEBRkRh8edGU0FEnjy6TOyh5-68JQppraEyR4ef4Q@mail.gmail.com>
 <CAHnG2CybRRpY7Wp7CjVPdK7s6Cudg-Nf0WydTan8dy6Mq-etyg@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F325D55@DB3PRD3001MB020.064d.mgd.msft.net>

Cabal folk: it looks as if updating Cabal has made GHC on Windows break.  Might you investigate?

See below

Thanks

Simon

-----Original Message-----
From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of P?li G?bor J?nos
Sent: 09 October 2014 06:15
To: ghc-devs at haskell.org
Subject: Re: Building ghc on Windows with msys2

2014-10-07 17:02 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
> 2014-10-07 15:04 GMT+02:00 cg <chengang31 at gmail.com>:
>> I guess the current two build server are all Cygwin based, they are 
>> failing at the same permission issue at early building stage, it 
>> prevents checking out the real problem. It seems msys2 (or msys)  
>> seldom has such issue.
>
> For what it is worth, I have been witnessing those permission issues 
> with msys2 on my Windows builders.  They worked (more or the less) 
> fine until September 24, but suddenly, something has changed (not on 
> my side) and all I got those errors since.

Looks like the commit with the Cabal submodule update causes this [1].
The revision before that commit still builds fine on my system, while everything else after that commit dies early at build [2].  Is this only me, has anybody else experienced the problem?  Perhaps I am doing something wrong?  I do not remember to see any related "heads-up"
message on the list, like I should update any of the build-time dependencies.

[1] http://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae
[2] http://haskell.inf.elte.hu/builders/windows-x86-head/56/10.html
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

From juhpetersen at gmail.com  Fri Oct 24 06:51:04 2014
From: juhpetersen at gmail.com (Jens Petersen)
Date: Fri, 24 Oct 2014 15:51:04 +0900
Subject: passing CFLAGS and LDFLAGS to ghc via Cabal?
Message-ID: <CAEDGBqJL3YnqnA8iML41K=Az+-vv_pVSiXZ+2OqehKjsR2LRDg@mail.gmail.com>

Hi,

This may seem like a strange question since most ghc compilation uses the
NCG or llvm backends, but I want to ask about how/if one can pass
CFLAGS/LDFLAGS to gcc from Cabal?

So far I tried using --gcc-options="$RPM_OPT_FLAGS" (and also just
exporting CFLAGS), but as far as I can tell (from --ghc-option=-v) the
options are not passed by ghc to gcc. Is the problem that ghc first
compiles C code to assembler before compiling the asm to an object file?

(This is in the context of adding of trying to add debuginfo for C files to
Fedora's Haskell packages, though I am not even sure if it is useful. Maybe
it is a futile experiment?)

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141024/7897a14f/attachment.html>

From slyich at gmail.com  Fri Oct 24 20:10:39 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Fri, 24 Oct 2014 21:10:39 +0100
Subject: passing CFLAGS and LDFLAGS to ghc via Cabal?
In-Reply-To: <CAEDGBqJL3YnqnA8iML41K=Az+-vv_pVSiXZ+2OqehKjsR2LRDg@mail.gmail.com>
References: <CAEDGBqJL3YnqnA8iML41K=Az+-vv_pVSiXZ+2OqehKjsR2LRDg@mail.gmail.com>
Message-ID: <20141024211039.61fd1981@sf>

On Fri, 24 Oct 2014 15:51:04 +0900
Jens Petersen <juhpetersen at gmail.com> wrote:

> Hi,
> 
> This may seem like a strange question since most ghc compilation uses the
> NCG or llvm backends, but I want to ask about how/if one can pass
> CFLAGS/LDFLAGS to gcc from Cabal?
> 
> So far I tried using --gcc-options="$RPM_OPT_FLAGS" (and also just
> exporting CFLAGS), but as far as I can tell (from --ghc-option=-v) the
> options are not passed by ghc to gcc. Is the problem that ghc first
> compiles C code to assembler before compiling the asm to an object file?
> 
> (This is in the context of adding of trying to add debuginfo for C files to
> Fedora's Haskell packages, though I am not even sure if it is useful. Maybe
> it is a futile experiment?)

I believe the proper way to pass them is via
    --ghc-option="-optc$EACH_CFLAG -optl$EACH_LDFLAG -opta$EACH_ASFLAG"
as Cabal uses ghc to compile .c/.cpp files.

At least it's how we do it in gentoo
    https://github.com/gentoo-haskell/gentoo-haskell/blob/master/eclass/haskell-cabal.eclass#L366
to preserve debug syms and play with
things like -Wl,--as-needed -Wl,--hash-style=gnu.

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141024/522b8643/attachment.sig>

From juhpetersen at gmail.com  Mon Oct 27 08:50:41 2014
From: juhpetersen at gmail.com (Jens Petersen)
Date: Mon, 27 Oct 2014 17:50:41 +0900
Subject: passing CFLAGS and LDFLAGS to ghc via Cabal?
In-Reply-To: <20141024211039.61fd1981@sf>
References: <CAEDGBqJL3YnqnA8iML41K=Az+-vv_pVSiXZ+2OqehKjsR2LRDg@mail.gmail.com>
 <20141024211039.61fd1981@sf>
Message-ID: <CAEDGBq+KT95rQHCaF6F6s-2phsV8ksJHQPZnOa2xCxeTAwWfxw@mail.gmail.com>

On 25 October 2014 05:10, Sergei Trofimovich <slyich at gmail.com> wrote:
>
> I believe the proper way to pass them is via
>     --ghc-option="-optc$EACH_CFLAG -optl$EACH_LDFLAG -opta$EACH_ASFLAG"
> as Cabal uses ghc to compile .c/.cpp files.
>

Thanks Sergei that helped a lot. :)

I can now get proper debuginfo generated for libraries,
but somehow not for executables: but that looks
like some ghc behaviour problem perhaps.

http://pkgs.fedoraproject.org/cgit/ghc-rpm-macros.git/tree/macros.ghc?id=e5c8c16492266bfe8ef02ec58cac0f745533e165#n26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141027/344e0cf6/attachment.html>

From slyich at gmail.com  Mon Oct 27 08:59:13 2014
From: slyich at gmail.com (Sergei Trofimovich)
Date: Mon, 27 Oct 2014 08:59:13 +0000
Subject: passing CFLAGS and LDFLAGS to ghc via Cabal?
In-Reply-To: <CAEDGBq+KT95rQHCaF6F6s-2phsV8ksJHQPZnOa2xCxeTAwWfxw@mail.gmail.com>
References: <CAEDGBqJL3YnqnA8iML41K=Az+-vv_pVSiXZ+2OqehKjsR2LRDg@mail.gmail.com>
 <20141024211039.61fd1981@sf>
 <CAEDGBq+KT95rQHCaF6F6s-2phsV8ksJHQPZnOa2xCxeTAwWfxw@mail.gmail.com>
Message-ID: <20141027085913.1f480f57@sf>

On Mon, 27 Oct 2014 17:50:41 +0900
Jens Petersen <juhpetersen at gmail.com> wrote:

> I can now get proper debuginfo generated for libraries,
> but somehow not for executables: but that looks
> like some ghc behaviour problem perhaps.

More likely cabal's feature. To avoid stripping we use
    --disable-executable-stripping (cabal-1.4+)
option for 'Setup configure' phase (and then we strip
binaries by package manager if user didn't request
debugging support).

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141027/a60d05f9/attachment.sig>

From stegeman at gmail.com  Tue Oct 28 20:00:50 2014
From: stegeman at gmail.com (Luite Stegeman)
Date: Tue, 28 Oct 2014 21:00:50 +0100
Subject: New fields/flags and semantics for GHCJS
Message-ID: <CALqQuojA5_d_0ep4wEonA=q7eCvNUS-eX=HsMBv91mFcEzj5Ag@mail.gmail.com>

Hi all,

I've been maintaining a Cabal fork for GHCJS. The GHCJS-specific bits have
been relatively stable for a while now, and are feature complete, apart
from a few small features that I'll complete later this week.

So I think it's time to discuss merging the branch. This discussion is for
the user visible changes only, the implementation details can be discussed
later when the code has been cleaned up for the merge (1-2 weeks). I hope
that the proposed changes cover most JavaScript packaging/build
requirements, but feature requests or questions about support for specific
scenarios are welcome!

First some background:

GHCJS is a cross-compiler, installed as a package. It has its own version
number (0.1.0 currently), independent of the GHC version it was built with.
After GHCJS and its standard libraries have been installed, it does not
require GHC anymore. Cabal's custom setup type is supported by compiling
Setup.hs to JavaScript and running it with node.js.

In the Cabal branch, GHCJS is treated as a very close relative of GHC. In
various places there is support for GHCJS building native code. While this
(--native-too mode) is currently disabled in a default installation, it can
be enabled again for generating JavaScript and native code from the same
Core, for example to allow closure serialization and continuing
computations between client and server (not yet implemented!).

All Cabal features are supported, including sandboxes. "cabal test"
compiles the testsuite of a package and runs it with node.js. "cabal repl"
is implemented on the Cabal side, but there is no repl for GHCJS yet, this
is planned for the not too far future (with a terminal and browser based
front end).

The changes:

# a new implementation flag: impl(ghcjs)

A new implementation flag has been added for GHCJS, using the GHCJS version
number. Since GHCJS is a close descendant of GHC, the impl(ghc) flag is
also set when something is being built with GHCJS. For example

if impl(ghc >= 7.2) -- GHC.Generics support (compiler could be GHCJS)
if impl(ghcjs >= 0.1) -- package is being built with GHCJS

# ghcjs-options, ghcjs-shared-options, ghcjs-prof-options

These new fields behave similar to those for GHC (ghcjs-shared-options only
has effect for native-too mode). If not set, the corresponding value from
ghc-options, ghc-shared-options, ghc-prof-options is used.

(An alternative is to let ghcjs-*-options field append the options to the
corresponding ghc-*-options field, instead of replacing them)

# new js-sources field

A js-sources field is treated like the c-sources field. JS sources of all
dependencies of a an executable are collected into a big JavaScript file.
GHCJS also outputs some data about the collected files for custom
deployment scripts.

JS sources are not compiled, but are run through the C preprocessor. Since
running the same file through the preprocessor twice is problematic, and
it's very useful to be able to set some preprocessor options at link time
(for example -DGHCJS_BROWSER, which removes node.js-specific code), the
strategy is as follows:

- When a library is being installed, the js-sources are copied to the
library installation directory, but not run through the preprocessor. the
cpp options are saved in the installation dir
- When building an executable, the JS-sources are collected. Each JS source
is processed with its own saved cpp-options with the cpp-options for
building the executable appended.

# new JavaScriptFFI extension

The extension has been in GHC since 7.8, but it can't be used on
non-JavaScript code generators. This change just adds it to the list of
known extensions.

luite
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141028/9c0e9df2/attachment.html>

From the.dead.shall.rise at gmail.com  Wed Oct 29 01:10:01 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Wed, 29 Oct 2014 02:10:01 +0100
Subject: New fields/flags and semantics for GHCJS
In-Reply-To: <CALqQuojA5_d_0ep4wEonA=q7eCvNUS-eX=HsMBv91mFcEzj5Ag@mail.gmail.com>
References: <CALqQuojA5_d_0ep4wEonA=q7eCvNUS-eX=HsMBv91mFcEzj5Ag@mail.gmail.com>
Message-ID: <CA+tcxkDo68D4P0im_O-owk4yffCakBBJ6AYXdxXzUzwmfRYLHw@mail.gmail.com>

Hi,

On 28 October 2014 21:00, Luite Stegeman <stegeman at gmail.com> wrote:
> Hi all,
>
> I've been maintaining a Cabal fork for GHCJS. The GHCJS-specific bits have
> been relatively stable for a while now, and are feature complete, apart from
> a few small features that I'll complete later this week.
>
> So I think it's time to discuss merging the branch. This discussion is for
> the user visible changes only, the implementation details can be discussed
> later when the code has been cleaned up for the merge (1-2 weeks).

The user-visible changes look reasonable in my opinion. Looking
forward to merging your patches!

From lsp at informatik.uni-kiel.de  Thu Oct 30 15:22:40 2014
From: lsp at informatik.uni-kiel.de (lennart spitzner)
Date: Thu, 30 Oct 2014 16:22:40 +0100
Subject: improving commandline documentation/help
Message-ID: <545257C0.9050605@informatik.uni-kiel.de>

hello cabal devs,

i am willing to put a bit of time into improving the help texts of
cabal-install. some questions:

1) nobody else is working on this, right? is there risk that it
interferes with other's work? (i'd basically touch
Distribution.Simple.Command and the different fooCommand's in both
Setup.hs's)

2) is there a specific reason that the help texts currently are so
short, other than lack of time/focus on functionality? pending large
changes or smth?

3) is there a policy to keep commits touching Cabal and cabal-install
subdirectories separate (for git-subtree purposes, for example)?


Lennart


From the.dead.shall.rise at gmail.com  Thu Oct 30 15:38:54 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 30 Oct 2014 16:38:54 +0100
Subject: improving commandline documentation/help
In-Reply-To: <545257C0.9050605@informatik.uni-kiel.de>
References: <545257C0.9050605@informatik.uni-kiel.de>
Message-ID: <CA+tcxkCVsMYGxN1vexgAhZLRth8MOtAAG-+j-NbewpsogMo0Rg@mail.gmail.com>

Hi,

On 30 October 2014 16:22, lennart spitzner <lsp at informatik.uni-kiel.de> wrote:
> hello cabal devs,
>
> i am willing to put a bit of time into improving the help texts of
> cabal-install. some questions:
>
> 1) nobody else is working on this, right? is there risk that it
> interferes with other's work? (i'd basically touch
> Distribution.Simple.Command and the different fooCommand's in both
> Setup.hs's)

Not to my knowledge.

> 2) is there a specific reason that the help texts currently are so
> short, other than lack of time/focus on functionality? pending large
> changes or smth?

Not really, feel free to go ahead and improve things.

> 3) is there a policy to keep commits touching Cabal and cabal-install
> subdirectories separate (for git-subtree purposes, for example)?

No, and I think it's better to change both in lockstep so that there
are no broken revisions in history.

From stegeman at gmail.com  Thu Oct 30 17:50:17 2014
From: stegeman at gmail.com (Luite Stegeman)
Date: Thu, 30 Oct 2014 18:50:17 +0100
Subject: New fields/flags and semantics for GHCJS
In-Reply-To: <CA+tcxkDo68D4P0im_O-owk4yffCakBBJ6AYXdxXzUzwmfRYLHw@mail.gmail.com>
References: <CALqQuojA5_d_0ep4wEonA=q7eCvNUS-eX=HsMBv91mFcEzj5Ag@mail.gmail.com>
 <CA+tcxkDo68D4P0im_O-owk4yffCakBBJ6AYXdxXzUzwmfRYLHw@mail.gmail.com>
Message-ID: <CALqQuoj7VwkitSoenG9UNyu7A=b367v--M1wyUeiyfhh+eoVLA@mail.gmail.com>

On Wed, Oct 29, 2014 at 2:10 AM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

>
> The user-visible changes look reasonable in my opinion. Looking
> forward to merging your patches!
>

When merging the latest master I found that ghcjs-options are actually
mappended to ghc-options in the current implementation, instead of
replacing them.

The current version is here by the way:

https://github.com/ghcjs/cabal/tree/ghcjs

I still need to clean it up and check that all changes are still needed
though, and implement the missing features. I'm also working on making
GHCJS compatible with GHC 7.10 at the moment (and GHC 7.10 with GHCJS, a
few patches going in that direction), so this will take a few days.

luite
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141030/6853b511/attachment.html>

From stegeman at gmail.com  Thu Oct 30 22:04:56 2014
From: stegeman at gmail.com (Luite Stegeman)
Date: Thu, 30 Oct 2014 23:04:56 +0100
Subject: New fields/flags and semantics for GHCJS
In-Reply-To: <CALqQuojA5_d_0ep4wEonA=q7eCvNUS-eX=HsMBv91mFcEzj5Ag@mail.gmail.com>
References: <CALqQuojA5_d_0ep4wEonA=q7eCvNUS-eX=HsMBv91mFcEzj5Ag@mail.gmail.com>
Message-ID: <CALqQuoiiDY=EmzyE5TZs_7j4jwHXvL6CXKLHkke=erVED2s0kw@mail.gmail.com>

>
>
> # new js-sources field
>
> A js-sources field is treated like the c-sources field. JS sources of all
> dependencies of a an executable are collected into a big JavaScript file.
> GHCJS also outputs some data about the collected files for custom
> deployment scripts.
>
> JS sources are not compiled, but are run through the C preprocessor. Since
> running the same file through the preprocessor twice is problematic, and
> it's very useful to be able to set some preprocessor options at link time
> (for example -DGHCJS_BROWSER, which removes node.js-specific code), the
> strategy is as follows:
>
> - When a library is being installed, the js-sources are copied to the
> library installation directory, but not run through the preprocessor. the
> cpp options are saved in the installation dir
> - When building an executable, the JS-sources are collected. Each JS
> source is processed with its own saved cpp-options with the cpp-options for
> building the executable appended.
>
>
A downside of this approach is that it'd affect how `#include` works. We
could add the location where the `data-files` are installed to the include
path, so the to be included scripts can just be listed under `data-files`.
It doesn't feel quite ideal to use `data-files` for this, so suggestions
are welcome!

Another thing I forgot to mention is that non-js files can also be listed
under this field. For example if we have a Google Closure Compiler externs
file for a script, we'd use:

js-sources: script.js script.js.externs

Would cause both files to be installed with the library, and passed to the
compiler when linking, when building JavaScript. It's up to the compiler to
determine what to do based on the extension. Compilers should ignore
*.js.extension arguments for unrecognized extensions to allow reasonable
backwards compatibility.

luite
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141030/a4e7b135/attachment.html>