I have a program, say src/sample.hs, and I want it to compile (using ghc --make) to build/sample.exe.
I've figured out how to map the .hi and .o files over to the build folder, but I can't seem to find anything on how to compile the executable to a different directory. Does anyone know how to do this?
Thanks!
How about explicitly setting the output filename including the directory? Works over here, I haven't tested on Windows so I'm not sure if you need the .exe extension or not.
ghc --make -o build/sample.exe src/sample.hs
Also worth noting: --make is enabled by default as of GHC 7.0.
Related
I have a Haskell project where a number of executables are produced from mostly the same modules. I'm using a Makefile to enable parallel builds, and it very nearly works the way I want. Here's a stripped down version of my current Makefile, with ideas taken from http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#using-make:
HFLAGS=-O3 -Wall -v0 -fno-ignore-asserts
HASKELLS=bin1 bin2 bin3 bin4 bin5 bin6 bin7 bin8 bin9
all: $(HASKELLS)
%.hi: %.o
#:
%.hi %.o: %.hs
ghc -c $(HFLAGS) $<
$(HASKELLS): %: %.o
ghc --make $(HFLAGS) $#
.hsdepend: *.hs
ghc -M -dep-makefile .hsdepend *.hs
rm -f .hsdepend.bak
include .hsdepend
As you can see, I still use ghc --make for linking (only); this way the individual modules can be compiled in parallel, and ghc --make only invokes the linker.
Unfortunately this is not foolproof: A relink is triggered only for, say, bin1 only if bin1.o is newer than the executable, but not if only one of the other object files has been updated. This can happen when a change is made in a module such that it results in the .o file being updated, but the interface of the module does not change, i.e. the .hi file is not touched.
One alterative solution would be to trigger a null ghc --make for every binary every time make is invoked; unfortunately, this is slow and clutters the output (I'd like to see when something was linked and when not).
ghc -M only generates a dependency line for each .o file, but none for the linked executables. The information about which .o files to link into which executable (given the name of the main module binN.hs) obviously is there, but it's not entirely clear to me if it's possible to get to it using any Makefile magic.
I can only think of a way to do what this by writing a post-processor for .hsdepend, but that seems excessive.
Can anyone suggest a better solution?
My advice would be, don't bother trying to make this work. It should work, and it would be nice if it worked, but ghc's -M support is currently broken (as in, it doesn't generate proper dependency rules, and omits rules for some non-Haskell files). Actually getting this to work reliably will take a great deal of effort, and in the end will trigger more rebuilds than strictly necessary.
Furthermore, support for parallel builds has been merged into GHC, so when ghc-7.8 is released you'll be able to use plain ghc --make to get parallel builds. Or you could use ghc's HEAD now.
I've got a Haskell file, Saturn.hs, and a C++ file hssaturn.cpp and hssaturn.h, in the directory src/Galakhsy/. hssaturn.cpp needs libsaturn.cpp and/or libsaturn.hpp, which are in lib/saturn/src/lib/.
I have no idea how to compile it properly, any pointers?
Compile all the C++ files to object files using g++ -c filename.cpp. This produces, in your case, hssaturn.o and libsaturn.o. Then compile your Haskell program with ghc --make -o whatever Saturn.hs hssaturn.o libsaturn.o. Also specify any shared libraries needed by the C++ stuff with -lblabla. You probably at least need the C++ standard library, i.e. -lstdc++, making the GHC command something like
ghc --make -o whatever Saturn.hs hssaturn.o libsaturn.o -lstdc++
(well, modulo the correct paths for the two object files).
Also remember to prevent name mangling by using extern "C" for the C++ functions you call from Haskell.
Addendum: The name libsaturn makes me think it is perhaps a library. You might want to consider compiling it as that and simply linking dynamically (with the -l switch to GHC as above).
I want to use CUDPP library in my project. I've downloaded sources from project page. Unfortunatly, when I ran "make", there was only static library build. I've looked into Makefile files and haven't found any dynamic lib configuration. I don't want to keep static library with the project - it's totally non-portable way.
My question is: how can I build .so dynamic library of CUDPP, without writing my own Makefile/compiling it manually? Maybe someone already did it?
EDIT: I've replaced "g++" with "g++ -fPIC", "gcc" with "gcc -fPIC" and "nvcc" with "nvcc -Xcompiler -fpic". When I unpack obj files from archive, and link them to shared lib, I've got no error. However, my application crashes at start, when linked with this library.
when you compile pass the flag -Xcompiler -fpic to nvcc. If you link against any cuda libraries make sure you've linked to the shared libs, otherwise you can't link it. Hopefully that's all you need.
Are you also using -shared to create the library? You shouldn't need to extract anything from an archive if it is working correctly.
If you run ldd on your executable it will show you what dynamic linking is required by the app and you can check that the -fPIC etc. worked correctly. Also make sure that the .so library is on your LD_LIBRARY_PATH (sorry if that's obvious, no harm in checking).
I compiled my helloworld.hs and got a helloworld.o file, I tried ./helloworld, but it didn't work, so what is the right way to execute the helloworld?
I am using cygwin, I just write down $ ghc --make helloworld.hs and I get helloworld.hi, helloworld.exe.manifest, helloworld.o files, I don't know what do I need to do next...
Depending on whether you used a Cygwin ghc or a Windows native ghc, you got either a.out (a historical traditional name) or helloworld.exe. If you have a.out you'll need to rename it to something.exe to execute it on Windows.
You can easily tell ghc how to call the executable: ghc -o helloworld.exe --make helloworld.hs.
By the way ghc --help would have told you:
To compile and link a complete Haskell program, run the compiler like so:
ghc-6.8.2 --make Main
where the module Main is in a file named Main.hs (or Main.lhs) in the current directory. The other modules in the program will be located and compiled automatically, and the linked program will be placed in the file a.out' (orMain.exe' on Windows).
As you haven't specified anything about how you compiled, such as for instance what compiler you're using, we can only guess.
The common way to get a .o (object) file out of ghc is using the -c switch; as the manual says, that means "do not link". The mnemonic is "compile only". Without linking, you have only a portion of a program, and it cannot be executed. Precisely what it needs to be linked against will depend on the particular object file, and some of that is filled in by default if you simply let the compiler run the linker. Linking separately is more complicated.
When compiling a haskell source file via ghc --make foo.hs GHC always leaves behind a variety of intermediate files other than foo.exe. These are foo.hi and foo.o.
I often end up having to delete the .hi and .o files to avoid cluttering up the folders.
Is there a command line option for GHC not to leave behind its intermediate files? (When asked on #haskell, the best answer I got was ghc --make foo.hs && rm foo.hi foo.o.
I've gone through the GHC docs a bit, and there doesn't seem to be a built-in way to remove the temporary files automatically -- after all, GHC needs those intermediate files to build the final executable, and their presence speeds up overall compilation when GHC knows it doesn't have to recompile a module.
However, you might find that setting the -outputdir option will help you out; that will place all of your object files (.o), interface files (.hi), and FFI stub files in the specified directory. It's still "clutter," but at least it's not in your working directory anymore.
GHC now has the options no-keep-hi-files and no-keep-o-files. See here for more information.
My usual workflow is to use cabal rather than ghc directly. This sets the outputdir option into an appropriate build folder and can do things like build haddock documentation for you. All you need is to define the .cabal file for your project and then say cabal install or cabal build instead of run ghc directly. Since you need to follow this process in the end if you ever want to share your work on hackage, it is a good practice to get into and it helps manage package dependencies as well.
You can set the -hidir to /dev/null, I think, sending them there. Also, the -fno-code option in general turns off a lot of output. You might just want to use Cabal.
Turns out that using -hidir/-odir/-outputdir is no good; /dev/null is a file, and not a directory. See http://www.haskell.org/pipermail/xmonad/2010-May/010182.html
2 cents to improve the workflow a bit:
We can put the following alias into the .bashrc (or similar) config
file:
alias hsc='_hsc(){ ghc -no-keep-hi-files -no-keep-o-files "$#";}; _hsc'
And then just call
$ hsc compose.hs
[1 of 1] Compiling Main ( compose.hs, compose.o )
Linking compose ...
$ ls
compose compose.hs