| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done for consistency. We usually call the package file the same name the
folder has. The move into `utils` is done so that we can move the library into
`libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
`iserv.cabal` apart. This will make building the cross compiler with TH
simpler, because we can build the library and proxy as separate packages.
Test Plan: ./validate
Reviewers: bgamari, goldfire, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4436
|
| |
|
|
|
|
| |
See Phab:D4377 for the rationale. We will try this again.
This reverts commit 7c173b9043f7a9a5da46c5b0cc5fc3b38d1a7019.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done for consistency. We usually call the package file the same name the
folder has. The move into `utils` is done so that we can move the library into
`libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
`iserv.cabal` apart. This will make building the cross compiler with TH
simpler, because we can build the library and proxy as separate packages.
Reviewers: bgamari, simonmar, goldfire, erikd
Reviewed By: simonmar
Subscribers: tdammers, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4377
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we load non absolute pathed .so's this usually implies that we expect the
system to have them in place already, and hence we should not need to ship them.
Without the absolute path to the library, we are also unable to open and send
said library. Thus we'll do library shipping only for libraries with absolute
paths.
Reviewers: austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: simonmar, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3469
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, austin
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3462
|
|
|
With the introduction of -fexternal-interpreter we are
now able to compile template haskell via an extern iserv process.
This however is restricted to the same host, and can therefore
not be used with crosscompilers where the iserv slave process
needs to run on a different machine than the cross compiling
haskell compiler.
This diff breaks up iserv into a library and the iserv-bin binary.
It also introduces the iserv-proxy, a proxy instance that the
haskell compiler can talk to, and which forwards the calls
to the iserv slave on a different machine, as well as providing
some extra functionarily (sending files that are not available
on the machine the slave runs on), as well as forwarding from
the slave to the haskell compiler, when the slave needs to
interrogate the haskell compiler.
The iserv library now also exports the startSlave function to be
called by the application that implements the slave on the target.
The simplest such app would probably look something like:
```
extern void startServ(bool, const char *);
int main(int argc, char * argv[]) {
hs_init(NULL, NULL);
startServ(false,"/tmp");
while(1);
}
```
Special thanks to Shea Levy for the first draft of the iserv-remote,
from which I took some inspiration.
The `Buildable` flags are due to ghc-cabal not being able to build
more than a single target. Please note that only the stock iserv-bin
is supposed to be built *with* ghc. The library and proxy are supposed
to be built outside of ghc. Yet I believe that this code should live
together with iserv.
Reviewers: simonmar, ezyang, goldfire, austin, rwbarton, bgamari
Reviewed By: simonmar
Subscribers: luite, ryantrinkle, shlevy, thomie
Differential Revision: https://phabricator.haskell.org/D3233
|
