How to Create a Configure Script

How do I create a configure script?

To create the standard "configure" script you need GNU autoconf.
You may need GNU automake and libtool too.

There are tons of documentation and howtos.
Google for something like "autoconf automake howto".
The good documentation is in the official manual pages:

Autoconf: http://www.gnu.org/software/autoconf/
Automake: http://www.gnu.org/software/automake/automake.html
Libtool: http://www.gnu.org/software/libtool/libtool.html

Autoconf will create your configure script starting from the "configure.ac" file.
The "Makefile.am" file will instruct automake on how to create your makefile by the configure string. Libtool is needed to simplify libraries handling around your code.

You can start creating a configure.ac file by hand or you may use the "autoscan" helper that may help you to create something semi-automatic for you.

Then, when you are ready, this one will do the magic:

autoreconf -i

how to generate configure script -- linux

Just run the provided autogen.sh script.

generate configure.ac and configure script

I wrote a tutorial on this very subject - it's geared towards GTK programming but the first parts are not GTK-specific, so they will probably get you started.

How to produce a configure script for windows with autotools

can the same command be used on windows ?

Autoconf produces configure as a portable (POSIX) shell script. Windows does not come standard with a POSIX shell, nor with any of the standard tools on which Autotools configuration scripts and makefiles rely. Windows also does not come standard with a make implementation suitable for use with Autotools-built makefiles, and to the best of my knowledge, Visual Studio does not provide one either.

You could pretty easily build and run your project inside a WSL container on Windows, but that does not get you a native Windows executable.

If you want to use an Autotools build system on Windows to produce Windows executables then your best bet is probably to rely on msys2 and mingw-w64. These, together, can provide a standard-ish POSIX environment running natively in Windows, able to build Windows libraries and executables via the usual commands. But note well that this approach means that anyone who wants to build your project on Windows has to install these or comparable components first.

If not,
how can i achieve a similar process with autotools ? Or is autotools
incapable of producing a build script for windows ?

The Autotools produce build systems targeting Unix-like operating systems, including (but not limited to) Linux and MacOS. Such build systems are not appropriate for Windows machines except with the addition of a fairly large suite of third-party components, such as msys2 and mingw-x64 can provide.

If so, which build
tool could be used for windows ?

CMake is a more typical choice if you're after build compatibility with both Windows and Unix. That would ordinarily be instead of the Autotools, not in addition to them, because who wants to maintain multiple independent build systems for the same project?

How to tell a configure script to use my own toolchain

Pass the CC, LD etc. variables on the configure command line usually does it:

./configure CC=x86_64-xtensa-linux-gnu-gcc LD=...

Or whatever tool you want to use. See:

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Compilers-and-Options.html

How do I run the ./configure script on git package?

Gnash :

apt-get install g++ autoconf libtool libgconf2-dev libjemalloc-dev libgif-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libspeex-dev  libspeexdsp-dev libagg-dev xulrunner-dev libming-dev libming-util mtasc haxe swfmill libcsound64-dev dejagnu

git clone git://git.sv.gnu.org/gnash.git

cd gnash/
./autogen.sh
./configure
make

How can I do in order to generate the makefile with ./configure?

don't run autoheader - the project is not setup to use it
the automake warning is a warning, not an error.

usually, the simplest way to bootstrap an autotools-project is by running autoreconf -fiv.
that will create a configure script which you need to run in order to create the Makefile.

autoreconf -fiv
./configure
make

EDIT: EZtraze

the original answer (above) was a generic answer to a generic question ("How can I generate the makefile with ./configure?").

With a specific project, like EZtrace, it usually helps to read the README.
You already quoted the README, but for whatever reasons, it seems that you left out the crucial bit:

Getting EZTrace
=============================================
* You can get the latest stable release on EZTrace website:
  http://eztrace.gforge.inria.fr/

* Current development version is available via GIT
  git clone git://scm.gforge.inria.fr/eztrace/eztrace.git

After getting the latest development version (from GIT), you need to run
'./bootstrap' and only then build the tool.

(both the git version and the release tarballs available on the page you have linked to contain this section).

It clearly tells you that you must run ./bootstrap first.

So the answer to your question is: please read the documentation.

(also note that the build process for a specific software package is off-topic here in general; use the support forum for that software package)

Writing `configure` file for an r package

Here a minimal setup:

Remove src/Makevars and create src/Makevars.in with content

PKG_CPPFLAGS= @SBML_INCLUDE@
PKG_LIBS= $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) @SBML_LIBS@

I am not setting CXX since you cannot change that in src/Makevars, c.f. Package build ignores Makevars flags.

Create a minimal configure.ac file:

AC_INIT([Rcppsbml], 0.1.0)

AC_LANG(C++)
AC_REQUIRE_CPP
AC_PROG_CXX

# default values
AC_SUBST([SMBL_INCLUDE], "-I/usr/local/include")
AC_SUBST([SMBL_LIBS], "/usr/local/lib/libsbml-static.a")

# allow for override
AC_ARG_WITH([smbl],
            AC_HELP_STRING([--with-smbl=PREFIX],
                           [path to where smbl is installed]),
            [
             SMBL_INCLUDE="-I${with_smbl}/include"
             SMBL_LIBS="${with_smbl}/lib/libsbml-static.a"
            ],
            [])

# create and report output
AC_CONFIG_FILES([src/Makevars])
AC_OUTPUT
echo
echo "Final src/Makevars"
cat src/Makevars

Call autoconf to create a configure file from your configure.ac template. You might want to check the script with ./configure and ./configure --with-smbl=/some/path.

Call

R CMD build ...
R CMD check [--install-args=--configure-args=--with-smbl=/some/path] ...
R CMD INSTALL [--configure-args=--with-smbl=/some/path]...

to build, check and install the package.

Possible extensions:

Allow for switching between static and dynamic linking.
Check that SMBL can be found in a usable state at the specified location.

I see three issues here:

The generation of configure from configure.ac is not automatic. You have to call autoconf.
Similarly, Makevars.in is not generated by the system. You have to provide it as template from which Makevars is generated by configure.
The GSL ships with gsl-config, other libraries make use of the general pkg-config. If your library does not support this, you can use the more traditional way to use default locations or those provided with --with-... arguments. For example in RcppArrayFire I use:
```
AC_SUBST([AF_INCLUDE], "")
AC_SUBST([AF_LIBS], "-laf")

AS_IF([test -e "${with_arrayfire}"],
        [
         AF_INCLUDE="-I${with_arrayfire}/include ${AF_INCLUDE}"
         AF_LIBS="-L${with_arrayfire}/lib ${AF_LIBS} -Wl,-rpath,${with_arrayfire}/lib"
        ])
```
If a directory is supplied as --with-arrayfire=/relevant/path, then appropriate sub directories are searched for headers and dynamic libraries.

Confused about configure script and Makefile.in

In order to really understand the autotools utilities you have to remember where they come from: they come from an open source world where there are (a) developers who are working from a source code repository (CVS, Git, etc.) and creating a tar file or similar containing source code and putting that tar file up on a download site, and (b) end-users who are getting the source code tar file, compiling that source code on their system and using the resulting binary. Obviously the folks in group (a) also compile the code and use the resulting binary, but the folks in group (b) don't have or need, often, all the tools for development that the folks in group (a) need.

So the use of the tools is geared towards this split, where the people in group (b) don't have access to autoconf, automake, etc.

When using autoconf, people generally check in the configure.ac file (input to autoconf) into source control but do not check in the output of autoconf, the configure script (some projects do check in the configure script of course: it's up to you).

When using automake, people generally check in the Makefile.am file (input to automake) but do not check in the output of automake: Makefile.in.

The configure script basically looks at your system for various optional elements that the package may or may not need, where they can be found, etc. Once it finds this information, it can use it to convert various XXX.in files (typically, but not solely, Makefile.in) into XXX files (for example, Makefile).

So the steps generally go like this: write configure.ac and Makefile.am and check them in. To build the project from source code control checkout, run autoconf to generate configure from configure.ac. Run automake to generate Makefile.in from Makefile.am. Run configure to generate Makefile from Makefile.in. Run make to build the product.

When you want to release the source code (if you're developing an open source product that makes source code releases) you run autoconf and automake, then bundle up the source code with the configure and Makefile.in files, so that people building your source code release just need make and a compiler and don't need any autotools.

Because the order of running autoconf and automake (and libtool if you use it) can be tricky there are scripts like autogen.sh and autoreconf, etc. which are checked into source control to be used by developers building from source control, but these are not needed/used by people building from the source code release tar file etc.

Autoconf and automake are often used together but you can use autoconf without automake, if you want to write your own Makefile.in.