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.
Related
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.
I'm attempting to understand how to build a multiple-application Erlang OTP release using Rebar.
My applications include Webmachine, Riak, and a few applications of my own devising. So far, I have been running Rebar successfully in the application root directory. But the Rebar bootstrap program suggests that there may be a better way. E.g.:
"You now have a self-contained script called "rebar" in
your current working directory. Place this script anywhere in your path
and you can use rebar to build OTP-compliant apps."
I can think of several ways to do this. But I'm wondering:
Is there is a preferred convention: e.g., placing Rebar in an .erlang file, /usr/local/bin, etc., etc.?
Many thanks,
LRP
I keep a copy in /usr/local/bin, which I use when creating new apps. For example:
$ rebar create-app appid=myapp
All of my projects are built with rebar by placing the binary in the root directory of my project and referencing it locally in my Makefile as seen here. As of this writing, this seems to be the convention the community has adopted. For example, nitrogen, mochiweb, ibrowse, and erlydtl are all built this way.
Personally, I'm not a big fan of including the rebar binary with every project but I don't see a good alternative. It makes life easier for people that either don't have rebar in their path, or don't have an updated version in their path.
I suspect this is a temporary situation. Eventually the rebar project will start to have fewer commits, and we'll all agree to keep a copy in our path. At that point we can all stop including it. Of course, if your projects are only going to be used by you, this is a non-issue.
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]
Hope everyone is doing well
I am having a problem with make files in erlang on windows. I can't seem to get the following code to work.
.SUFFIXES: .erl .beam
.erl.beam:
erlc -W $<
ERL = erl -boot start_clean
MODS = main send get loops
all: compile
${ERL} -pa 'G:\Documents and Settings\Administrador' -s main start
compile: ${MODS:%=%.beam}
clean:
rm -rf *.beam erl_crash.dump
The files I am trying to compile are main.erl send.erl get.erl loops.erl
I save the make file as an .exe
And the type
make [main]
into the windows shell
All it gives me is a wierd popup error. Is the make [main] command correct?
And is my actual code right?
Thanks for the help,
-B
Several errors here:
The indented "ERL=" line won't work right. Leading tabs are special to make. You do not have complete formatting freedom, as with some other languages.
The make file should be saved as Makefile, no extensions. Case may or may not matter to your particular "make" program. All versions of make accept Makefile, however.
The brackets on your command line will never work. I assume you're cut-and-pasting them from somewhere, but they were probably using "[main]" as an example text you're supposed to replace, including the brackets.
"make main" will also fail because you don't have a "main" target in this Makefile. "make all", "make clean" and "make compile" will work, as will several implicit targets, like "make loops.beam".
You really should get a book on make, if you're going to continue to use it. I like O'Reilly's Managing Projects with GNU Make, 3/e by Mecklenburg, available for free online or in dead tree form. The GNU make manual is also available online and as dead trees.
You probably shouldn't be using traditional "make" here, however. For purely Erlang projects, Emakefiles are shorter, clearer, and just overall better. They're not so great for building other things along side your Erlang project, but you can always do both: the Makefile uses "erl -make" to kick off the Erlang build, and does everything else itself.
Your actual code looks more or less correct. You should remove the indentation for the line starting with ERL, and make sure that all the indented lines have TAB (not SPACE) in the beginning. (Unless you have a localised version of Windows, you should check the spelling of Administrator as well.)
The name of your Makefile should be Makefile (with no file type ending at all), and you should run it with make. Just writing make in the command line will run the topmost make-command (which in your case is 'all'). If you want to run any of the other commands (or all explicitly), then just add that to your make command, like "make clean", "make foo.beam".
Also consider putting your source files in src/ and your compiled files in ebin/ since that is the Erlang standard.
I recommend this page for further information about make (if you are using GNU Make): http://www.gnu.org/software/make/manual/make.html
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").