Compiling my Agda code results in a src/MAlonzo directory being created. (Where src/MyProject is where my Agda code lives.) It contains a bunch of .hs (Haskell) and .o (object) files.
Is there anything in this directory that I should commit, or do people typically add /src/MAlonzo to their .gitignore?
I'm asking because I'm surprised that build artifacts are being put in the src directory instead of the _build directory. I wonder if there's a reason for that.
Yes. MAlonzo is the GHC backend used for compiling and running Agda programs. Everything there is automatically generated from your Agda source files.
Related
In Haskell: Given an existing directory tree (with sub-directors) of source files.
Is there a way to get a .cabal or .stack file, created automatically, with all the necessary dependents (references to the import files that are embedded inside the source file) embedded in the command file,with no need to manualy editing the command file.
In other words, get a command file that I will be able to run "straight out of the box" without the regular methods of stack new/stack build etc,commands?
cabal init will create a file that lists all the modules in your sourcedir for you. But you will still need to provide the package dependencies yourself. This is because a module Foo.Bar.Baz may come from multiple packages -- hence the package you intend to import must be explicitly specified.
When using:
$ rebar3 as test eunit
it compiles the code into ebin, but the other directories are symlinked in the _build/test/lib folder. I've tried using profile test by modifying:
{relx, [{dev_mode, false}]}
This works only for _build/test/rel directory but not the lib directory. So during tests they are referencing the lib symlink directories. Is there a way to have these directories not symlinked to the original, but actual copies provided like the release?
After a quick look at the rebar3 code there doesn't seem to be a way to force copying of these directories. It looks like the priv directory is always symlinked here. Even though the function used is called symlink_or_copy, it only ends up copying when there is an error while creating the symlink.
dev_mode is a relx option, that's why it doesn't affect rebar3 features.
If you want this feature added you can create a feature request explaining your use case, why you think it would be useful and it might get implemented.
In the .qmake.cache file in the root directory of my project, I do:
QMAKE_CXXFLAGS += -isysroot /Developer/SDKs/MacOSX10.7.sdk
(Basically I followed the suggestions here.)
The project consists of several orders of subdirs. When I manually go into some subdir and do make, it uses those CXXFLAGS. However, if I do make in the root directory, it does not add them.
Why? How can I fix that?
My current workaround:
Never do qmake in a subdirectory. That seems to create other makefiles which seem to confuse qmake when run from the root.
When you ended up with some bad makefiles or other bad state, remove all makefiles from all dirs and all QMake immediate files, and run qmake again in the root.
I'm not really happy with that. There is no real indication whether I am in a good state or not, because it also compiles without that QMAKE_CXXFLAGS specification, only that the resulting binary might not load on older MacOSX versions, or even only parts of it at runtime, which I cannot even test so easily.
I am (very) new to qmake, but i would like
to use qmake to build whole project automatically,
so recursively check all subdirs and build every file.
I have a pch file too.
Is there a way to do it?
Thanks ahead!
The simplest way is to let qmake generate the qmake file for you.
After making a backup copy of any exist *.pro files you may need to reference, go to the top level of your directory structure and issue the command qmake -project. This tells qmake to recurse the tree and locate everything it needs to build and create a qmake project file from it.
Next, edit the generated qmake file. You will at least need to change the TEMPLATE line to be "lib" instead of "app". You will also want to specify the name of the TARGET. There may also be some other things you wish to change.
Now that you have a qmake file, you need to generate a make file. Run qmake again, but this time just say qmake without any arguments.
Finally, you should be able to just run make and have things build. [For future readers running Windows with the MingW tools, make should be replaced with mingw32-make]
I have an erlang application I have been writing which uses the erldis library for communicating with redis.
Being a bit of a newbie with actually deploying erlang applications to production, I wanted to know if there was anyway to 'bundle' these external libraries with the application rather than installing into my system wide /usr/lib/erlang/lib/ folder.
Currently my directory structure looks like...
\
--\conf
--\ebin
--\src
I have a basic Makefile that I stole from a friend's project, but I am unsure how to write them properly.
I suspect this answer could involve telling me how to write my Makefile properly rather than just which directory to plonk some external library code into.
You should really try to avoid project nesting whenever possible. It can lead to all sorts of problems because of how module/application version is structured within Erlang.
In my development environment, I do a few things to simplify dependancies and multiple developed projects. Specifically, I keep most of my projects sourced in a dev directory and create symlinks into an elibs dir that is set in the ERL_LIBS environmental variables.
~/dev/ngerakines-etap
~/dev/jacobvorreuter-log_roller
~/dev/elib/etap -> ~/dev/ngerakines-etap
~/dev/elib/log_roller -> ~/dev/jacobvorreuter-log_roller
For projects that are deployed, I've either had package-rpm or package-apt make targets that create individual packages per project. Applications get boot scripts and init.d scripts for easy start/stop controls but libraries and dependancy projects just get listed as package dependencies.
I use mochiweb-inspired style. To see example of this get your copy of mochiweb:
svn checkout http://mochiweb.googlecode.com/svn/trunk/ mochiweb
and use
path/to/mochiweb/scripts/new_mochiweb.erl new_project_name
to create sample project of the structure (feel free to delete everything inside src afterwards and use it for your project).
It looks like this:
/
/ebin/
/deps/
/src/
/include/
/support/
/support/include.mk
Makefile
start.sh
ebin contains *.beam files
src contains ***.erl files and local *.hrl files
include contains global *.hrl files
deps contains symlinks to root directories of dependencies
Makefile and include.mk takes care of including appropriate paths when project is built.
start.sh takes care of including appropriate paths when project is run.
So using symlinks in deps directory you are able to fine tune the versions of libraries you use for every project. It is advised to use relative paths, so afterwards it is enough to rsync this structure to the production server and run it.
On more global scale I use the following structure:
~/code/erlang/libs/*/
~/code/category/project/*/
~/code/category/project/*/deps/*/
Where every symlink in deps points to the library in ~/code/erlang/libs/ or to another project in the same category.
The simplest way to do this would be to just create a folder named erldir and put the beams you need into it and then in your start script just use the -pa flag to the erlang runtime to point out where it should fetch the beams.
The correct way (at least if you buy into the OTP distribution model) would be to create a release using reltool (http://www.erlang.org/doc/man/reltool.html) or systools (http://www.erlang.org/doc/man/systools.html) which includes both your application and erldis.
Add the external libraries that you need, anywhere you want them, and add them to your ERL_LIBS environment variable. Separate the paths with colon in unix or semicolon in dos.
Erlang will add the "ebin"-named subdirs to its code loading path.
Have your *.app file point out the other applications it depends on.
This is a good halfway-there approach for setting up larger applications.
Another way is put your lib path in ~/.erlang.
code:add_pathz("/Users/brucexin/sources/mochiweb/ebin").
code:add_pathz("/Users/brucexin/sources/webnesia/ebin").
code:add_pathz("./ebin").
code:add_pathz("/Users/brucexin/sources/erlang-history/ebin/2.15.2").