From 24c2e3e41eebbcf8f0601cf3cd2f3af765312b17 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Thu, 22 Oct 2015 17:51:34 +0200 Subject: Update user guide --- guide/ch08.html | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- guide/index.html | 2 +- 2 files changed, 58 insertions(+), 2 deletions(-) diff --git a/guide/ch08.html b/guide/ch08.html index d8cf4cd..23f8429 100644 --- a/guide/ch08.html +++ b/guide/ch08.html @@ -31,7 +31,63 @@ div.navfooter{margin-bottom:1em}
-
Prev   Next

Chapter 8. NIFs and port drivers

Placeholder chapter.

Prev Up Next
 Home 
+
Prev   Next

Chapter 8. NIFs and port drivers

Erlang.mk can not only build Erlang projects, but also the C code +that some projects come with, like NIFs and port drivers.

There are two ways to build the C code: using a custom Makefile, +or making Erlang.mk do it directly. The C code will be built +as needed when you run make.

8.1. C source code location and Erlang environment

The C source code should be located in the $(C_SRC_DIR) directory. +It defaults to c_src/. Should you need to modify it, all you +need to do is to set the variable in your Makefile before including +Erlang.mk:

C_SRC_DIR = $(CURDIR)/my_nif_source

When this directory exists, Erlang.mk will automatically create a +file named $(C_SRC_ENV). This file defaults to $(C_SRC_DIR)/env.mk. +This can also be changed:

C_SRC_ENV = $(C_SRC_DIR)/erlang_env.mk

It contains a few variable definitions for the environment used for the build:

+ERTS_INCLUDE_DIR +
+ Path to the ERTS include files (erl_driver.h, erl_nif.h and more). +
+ERL_INTERFACE_INCLUDE_DIR +
+ Path to the Erl_Interface include files (ei.h and related). +
+ERL_INTERFACE_LIB_DIR +
+ Path to the Erl_Interface static libraries. +

8.2. Using a custom Makefile

Erlang.mk will automatically run make if it detects a Makefile +in $(C_SRC_DIR)/Makefile.

The Makefile should have at least two targets: a default target +(which can be anything, for example all) which is invoked when +building the C code, and a clean target invoked when cleaning +it.

You can include the env.mk file to benefit from the Erlang +environment detection:

include env.mk

8.3. Using Erlang.mk directly

You don’t need to write a Makefile to build C source code, however. +Erlang.mk comes with rules to build both shared libraries and +executables, using the source files it finds in $(C_SRC_DIR).

By default, Erlang.mk will create a shared library. To change +this and create an executable instead, put this in your Makefile +before including Erlang.mk:

C_SRC_TYPE = executable

The generated file will be saved to $(C_SRC_OUTPUT). It +defaults to $(CURDIR)/priv/$(PROJECT).so, the filename +adequately fitting a Unix shared library.

Erlang.mk sets appropriate compile and linker flags by default. +These flags vary depending on the platform, and can of course +be overriden.

+CC +
+ The compiler to be used. +
+CFLAGS +
+ C compiler flags. +
+CXXFLAGS +
+ C++ compiler flags. +
+LDFLAGS +
+ Linker flags. +
+LDLIBS +
+ Libraries to link against. +

The source files are automatically gathered from the contents +of $(C_SRC_DIR). Erlang.mk looks for .c, .C, .cc and .cpp +source files. You can define the variable SOURCES to manually +list the files to compile.

Prev Up Next
 Home 
diff --git a/guide/index.html b/guide/index.html index 4c10979..2c5b0ed 100644 --- a/guide/index.html +++ b/guide/index.html @@ -31,7 +31,7 @@ div.navfooter{margin-bottom:1em}
-
   Next

Erlang.mk User Guide

Loïc Hoguin

Table of Contents

1. Installation
1.1. On Unix
1.2. On Windows
2. Getting started
2.1. Creating a folder for your project
2.2. Downloading Erlang.mk
2.3. Getting started with OTP applications
2.4. Getting started with OTP libraries
2.5. Getting started with OTP releases
2.6. Using templates
2.7. Getting help
3. Overview
3.1. Building your project
3.2. Exploring the package index
3.3. Generating documentation
3.4. Running tests
3.5. Need more?
4. Updating Erlang.mk
4.1. Initial bootstrap
4.2. Updating
4.3. Customizing the build
5. Limitations
5.1. Erlang must be available
5.2. Spaces in path
5.3. Dependency tracking and modification times
I. Code
6. Building
6.1. How to build
6.2. What to build
6.3. Application resource file
6.4. Automatic application resource file values
6.5. File formats
6.6. Compilation options
6.7. Cold and hot builds
6.8. Dependency tracking
6.9. Generating Erlang source
6.10. Cleaning
7. Packages and dependencies
7.1. Searching packages
7.2. Adding dependencies to your project
7.3. How deps are fetched and built
7.4. Ignoring unwanted dependencies
7.5. Dependencies directory
7.6. Dependencies local to the repository
7.7. Repositories with no application at the root level
7.8. Autopatch
7.9. Skipping deps
8. NIFs and port drivers
9. Releases
10. Escripts
11. Compatibility with other build tools
11.1. Rebar projects as Erlang.mk dependencies
11.2. Erlang.mk projects as Rebar dependencies
II. Documentation
12. Asciidoc documentation
13. EDoc comments
III. Tests
14. Erlang shell
15. EUnit
16. Common Test
17. Property based testing
18. Code coverage
19. Continuous integration
20. Dialyzer
21. Xref
IV. Third-party plugins
22. External plugins
22.1. Loading all plugins from a dependency
22.2. Loading one plugin from a dependency
22.3. Writing external plugins
V. About Erlang.mk
23. Why Erlang.mk
23.1. Erlang.mk is fast
23.2. Erlang.mk gives you the full power of Unix
23.3. Erlang.mk is a text file
23.4. Erlang.mk can manage Erlang itself
23.5. Erlang.mk can do more than Erlang
23.6. Erlang.mk integrates nicely in Make and Automake projects
24. Short history
25. Architecture
26. Contributing
   Next
+
   Next

Erlang.mk User Guide

Loïc Hoguin

Table of Contents

1. Installation
1.1. On Unix
1.2. On Windows
2. Getting started
2.1. Creating a folder for your project
2.2. Downloading Erlang.mk
2.3. Getting started with OTP applications
2.4. Getting started with OTP libraries
2.5. Getting started with OTP releases
2.6. Using templates
2.7. Getting help
3. Overview
3.1. Building your project
3.2. Exploring the package index
3.3. Generating documentation
3.4. Running tests
3.5. Need more?
4. Updating Erlang.mk
4.1. Initial bootstrap
4.2. Updating
4.3. Customizing the build
5. Limitations
5.1. Erlang must be available
5.2. Spaces in path
5.3. Dependency tracking and modification times
I. Code
6. Building
6.1. How to build
6.2. What to build
6.3. Application resource file
6.4. Automatic application resource file values
6.5. File formats
6.6. Compilation options
6.7. Cold and hot builds
6.8. Dependency tracking
6.9. Generating Erlang source
6.10. Cleaning
7. Packages and dependencies
7.1. Searching packages
7.2. Adding dependencies to your project
7.3. How deps are fetched and built
7.4. Ignoring unwanted dependencies
7.5. Dependencies directory
7.6. Dependencies local to the repository
7.7. Repositories with no application at the root level
7.8. Autopatch
7.9. Skipping deps
8. NIFs and port drivers
8.1. C source code location and Erlang environment
8.2. Using a custom Makefile
8.3. Using Erlang.mk directly
9. Releases
10. Escripts
11. Compatibility with other build tools
11.1. Rebar projects as Erlang.mk dependencies
11.2. Erlang.mk projects as Rebar dependencies
II. Documentation
12. Asciidoc documentation
13. EDoc comments
III. Tests
14. Erlang shell
15. EUnit
16. Common Test
17. Property based testing
18. Code coverage
19. Continuous integration
20. Dialyzer
21. Xref
IV. Third-party plugins
22. External plugins
22.1. Loading all plugins from a dependency
22.2. Loading one plugin from a dependency
22.3. Writing external plugins
V. About Erlang.mk
23. Why Erlang.mk
23.1. Erlang.mk is fast
23.2. Erlang.mk gives you the full power of Unix
23.3. Erlang.mk is a text file
23.4. Erlang.mk can manage Erlang itself
23.5. Erlang.mk can do more than Erlang
23.6. Erlang.mk integrates nicely in Make and Automake projects
24. Short history
25. Architecture
26. Contributing
   Next
-- cgit v1.2.3