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
Related
By "install packages" I mean to evaluate Nix build expressions (using nix-env, nix-shell -p, etc.) to build from source instead of using a substitute.
Also cross-posted to Unix& Linux because, as Charles Duffy pointed out, it is more on topic if it is about command-line tools or configuration. Still leaving this here because I assume forcing a package to always compile from source is possible by only using the Nix language, I just don't yet know how. (Or if it is in fact not possible, someone will point it out, and then this question does belong here.)
Either set the substitute option to false in nix.conf (the default is true) or use --option substitute false when invoking a Nix command.
nix-env --options substitute false -i hello
nix-shell --options substitute false -p hello
Might not be the droids you are looking for
As Robert Hensing (comment, chat), Henri Menke (comment), and Vladimír Čunát (comment) pointed out, this may not be the thing that you are really after.
To elaborate: I have been using the most basic Nix features confidently, but got to a point where I need to maintain and deploy a custom fork of a large application written in C, which is quite intimidating at the outset.
Tried to attack the problem the simplest way to just fetch my fork and re-build it with the new source, so I boiled it down to this question. Although, I suspect that the right direction for me is something along the lines of Nixpkgs/Create and debug packages in the NixOS Wiki.
Only re-build the package itself
Vladimír Čunát commented that "disabling substitutes makes you rebuild everything that's missing locally, even though I suspect that people asking such a question often only want to rebuild the specified package itself."
(This is probably achieved with nix-build or "just" overriding the original package but could be wrong. The latter is mention (maybe demonstrated even?) in the NixOS wiki article Development environment with nix-shell but haven't been able to read it thoroughly yet.)
Test for reproducibility
One might arrive to formulating this same question if they want to make sure that subsequent builds are deterministic. As Henri Menke comments, one should use nix-build --check for that.
The --check option is easy to miss; it's not documented in man nix-build or at nix-build in the Nix manual, but at nix-store --realize because (as man nix-build explains it):
nix-build is essentially a wrapper around nix-instantiate (to
translate a high-level Nix expression to a low-level store derivation)
and nix-store --realise (to build the store derivation) [and so] all
options not listed here are passed to nix-store --realise, except
for --arg and --attr / -A which are passed to nix-instantiate.
See detailed examples in the Nix manual at 18.1. Spot-Checking Build Determinism and the next section right after it.
The relevant parts for the substitute configuration option under the nix.conf section from the Nix manual:
Name
nix.conf — Nix configuration file
Description
Nix reads settings from two configuration files:
The system-wide configuration file sysconfdir/nix/nix.conf (i.e. /etc/nix/nix.conf on most systems), or $NIX_CONF_DIR/nix.conf if NIX_CONF_DIR is set.
The user configuration file $XDG_CONFIG_HOME/nix/nix.conf, or ~/.config/nix/nix.conf if XDG_CONFIG_HOME is not set.
You can override settings on the command line using the --option flag,
e.g. --option keep-outputs false.
The following settings are currently available:
[..]
substitute
If set to true (default), Nix will use binary substitutes if available. This option can be disabled to force building from source.
(Formerly known as use-binary-caches.)
Notes
Setting substitute to false (either with --options or in nix.conf) won't recompile the package if the command issue multiple times. That is, hello above would be compiled from source the first time, and then it will access the already present store path if the command issued again.
This is where it gets fuzzy: it is clear that no recompilation takes place because unless the package's Nix build expression doesn't change, the store output hash won't change either, making the next compilation output equivalent to the previous one, hence the action would be superfluous.
So if one would do some light hacking on a package, and just wanted to try it out locally (e.g., with nix-shell) then one would have to use -I nixpkgs=a/local/nixpkgs/dir to pick up those changes - and eventually do a recompilation? Or should one use nix-build?
See also question How to nix-build again a built store path?
Is it possible to use Erlang with ZMQ on Windows? I have tried to use erlzmq2, but rebar fails to compile it with cryptic linker errors. Of course i can invest some time and investigate makefiles, but maybe other way exists?
Update
Whose who are interested in compilation errors can download latest erlang for windows and try to build erlzmq2 (Visual Studio 2012 compiler, msys sh and make). Error looks like:
cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL,-IMPLIB:.libs
\zmq.dll.lib'
Makefile:541: recipe for target 'libzmq.la' failed
make[3]: *** [libzmq.la] Error 2
Please note that other erlang libs are compiling with this setup without any problems.
Your problem lies in compiling ZeroMQ for Windows. You haven't actually gotten to any Erlang yet. Here are some of the clues that tell you this:
Makefile:541: recipe for target 'libzmq.la' failed
This line says there's a problem on line 541 of the Makefile. But in erlzmq2, you can see that neither the main Makefile nor the c_src Makefile (which is what would build libzmq.la) has anything close to that many lines.
make3: * [libzmq.la] Error 2
The [3] means that you're 3 invocations deep into Make. Specifically, you started at the top-level Makefile, which called Rebar, which ran make -C c_src, which downloads ZeroMQ version 3.2.2 and tries to do a ./configure && make
To fix this Unix-style, go into the deps directory of erlzmq2 and figure out how to correctly compile ZeroMQ. Hopefully, you will just need to pass some arguments to configure. Then you can edit c_src/Makefile and set ZMQ_FLAGS to whatever you had to do for configure, clean, and make.
To fix it more Windows-style, follow the Windows build instructions for ZeroMQ. Put the compiled libzmq under deps and just edit the c_src Makefile to a no-op.
Finally, if you don't actually need to run this code on Windows, but are just using Windows as your development environment, I think you'll have the easiest time by running the build inside a Linux VM (not a hard thing at all with tools like Vagrant). Sorry, but Unix is the real system for this stuff; Windows support is an afterthought.
As the title says, how to use luadoc in ubuntu/linux? I generated documentation in windows using batch file but no success in ubuntu. Any ideas?
luadoc
Usage: /usr/bin/luadoc [options|files]
Generate documentation from files. Available options are:
-d path output directory path
-t path template directory path
-h, --help print this help and exit
--noindexpage do not generate global index page
--nofiles do not generate documentation for files
--nomodules do not generate documentation for modules
--doclet doclet_module doclet module to generate output
--taglet taglet_module taglet module to parse input code
-q, --quiet suppress all normal output
-v, --version print version information
First off, I have little experience with Luadoc, but a lot of experience with Ubuntu and Lua, so I'm basing all my points off of that knowledge and a quick install that I've just done of luadoc. Luadoc, as far as I can see, is a Lua library (so can also be used in Lua scripts as well as bash). To make documentation (in bash), you just run
luadoc file.lua
(where file is the name of your file that you want to create documentation for)
The options -d and -t are there to choose where you want to put the file and what template you want to use (which I have no clue about, I'm afraid :P). For example (for -d):
luadoc file.lua -d ~/Docs
As far as I can see, there is little else to explain about the actual options (as your code snippet explains what they do well enough).
Now, looking at the errors you obtained when running (lua5.1: ... could not open "index.html" for writing), I'd suggest a few things. One, if you compiled the source code, then you may have made a mistake somewhere, such as not installing dependencies (which I'd be surprised about, because otherwise you wouldn't have been able to make it at all). If you did, you could try getting it from the repos with
sudo apt-get install luadoc
which will install the dependencies too. This is probably the problem, as my working copy of luadoc runs fine from /usr/bin with the command
./luadoc
which means that your luadoc is odd, or you're doing something funny (which I cannot work out from what you've said). I presume that you have lua5.1 installed (considering the errors), so it's not to do with that.
My advice to you is to try running
luadoc file.lua
in the directory of file.lua with any old lua file (although preferably one with at least a little data in) and see if it generates an index.html in the same folder (don't change the directory with -d, for testing purposes). If that DOESN'T work, then reinstall it from the repos with apt-get. If doing that and trying luadoc file.lua doesn't work, then reply with the errors, as something bigger is going wrong (probably).
I wanted to integrate Elixir into our project, and the good old codes don't use rebar, so I think writing the rules for building .ex files into Emakefile may be a good idea, yet the man page here didn't mention anything relevant.
Edit:
Our team works mainly in Windows environment, but the deployment will be done on Linux servers, so I need a cross-platform solution. Since Erlang itself is cross-platform, I wanted to do it with erl -make command.
Of course I can write a Makefile, but then I'll need a build.bat or something alike to build the code in our developing environments, since we don't have make command on our dev' machines.
Anyone have a better idea?
Update:
In case anyone wants to know, I'm doing it this way:
Copy the lib/elixir directory in the Elixir source tree to our source dir, say some_project/src/tools/elixir.
Add some_project/src/tools/elixir/src/elixir_transform.erl and some_project/src/tools/elixir/src/* to the Emakefile, in that order. Set the output dir to some_project/ebin (All the other .beam files are located there).
Copy src/elixir.app.src in the Elixir source tree to some_project/ebin/elixir.app, and edit it to fix the version code.
Build the Erlang code by running erl -pa ebin -make, in some_project dir.
Build the Elixir compiler by running erl -pa ebin -s elixir_compiler core -s erlang halt
Now we have a working Elixir environment in our code, and I use the following escript to build our custom .ex files:
%%! -pa ./ebin
main(_) ->
ExList = [
<<"source_1.ex">>,
<<"source_2.ex">>,
<<"source_3.ex">>],
application:start(elixir),
gen_server:call(elixir_code_server, {compiler_options, [{docs, true}, {debug_info, true}]}),
[elixir_compiler:file_to_path(F, <<"./ebin">>) || F <- ExList],
erlang:halt(0).
If you want to explicitly compile Elixir, I would go with the Makefile approach since it will always be supported by Elixir. However, I would recommend the precompiled binaries or even assume Elixir is installed in each developer machine. You can even add a task to your Emakefile to guarantee everyone is using the proper Elixir version.
Finally, about compiling your own Elixir code, I would recommend simply using mix. mix is a binary that ships with Elixir and you can simply do ./src/tools/elixir/bin/mix compile from your Emakefile.
In case using mix is not possible, you should use the parallel compiler, since it will compile files using all cores available in your machine and it will automatically detect and solve dependency in between files. Here is an example of calling the parallel compiler from erlang:
https://github.com/basho/rebar/pull/347/files#L1R62
The API is very simple. It expects a list of file names to compile as binary and the directory to output files to as another binary.
Does Lisp Flavored Erlang (LFE) work on Windows? I am using LFE 0.6/Erlang 5.8.2/Windows 7 32-bit. I copied the lfe shell script as a batch file (replacing $# with %1 %2 %3 %4) and it gives me this:
D:\projects\checkout\lfe>lfe
{"init terminating in do_boot",{undef,[{lfe_boot,start,[]},{init,start_it,1},{init,start_em,1}]}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
The problem here is that Erlang can't find the LFE ebin directory. Two ways to solve this problem are:
Use an explicit -pa <lfe ebin dir> argument when starting LFE, either in the lfe.bat script or when you call it. Simple but hard wired.
Use the ERL_LIBS environment variable. This is described in the code module documentation, http://erlang.org/doc/man/code.html. If you create an extra Erlang library directory, say c:\projects\erlang, drop Erlang apps which follow the Erlang application directory structure as LFE does, and point ERL_LIBS at it then the code server will automatically add ebin directories it finds there to its code path.
This is also described in How do I install LFE on Ubuntu Karmic? but in a UNIX context.
The ERL_LIBS feature should definitely be better advertised.
EDIT: Replying to #Shantanu Kumar's comment.
I don't have access to a Windows machine so I can't test it properly. The problem seems to be that using lfe_boot tries to start the port program ttysl which doesn't seem to work on Windows, at least not when running erl.exe. Some solutions to try:
Use werl.exe instead. This may work, but I would do it anyway.
Try starting Erlang in the normal way with werl.exe -pa ebin (to get the right load path) and manually starting the LFE shell with lfe_shell:server().
Try starting Erlang with werl.exe -pa ebin -noshell -s lfe_shell start. This will run lfe_shell as the shell but the ^G won't be available.
Also while it is nice to use it you don't need to use the LFE shell to run LFE, you can use the normal Erlang shell and just call the LFE functions in the "normal" way. You might become a little schizophrenic with two io formats, but there are no problems. :-)
Hope this helps.
My apologies; I know this post is basically dead, but I don't find other posts on the topic, thus replying here seems appropriate.
I believe I've found a methodology that works. Very simple really: just use MSYS2 and Mingw-w64 to build LFE, then run it from the build directory via ./bin/lfe.
There's one tweak needed it seems: the last line of bin/lfe seems to require a tweak to call "werl" instead of "erl". Honestly I don't know why this is; I'm too green behind the ears with Erlang to say why.
I've also documented this with slightly more detail on my personal blog: http://www.vultaire.net/blog/2016/05/02/installing-lisp-flavored-erlang-on-windows/
Hope this helps someone out!